The current Openpath Jira and Confluence instances will be migrated to the MSI On-Premise solution from August 9th-11th, the current platform will be set to read-only and all future usage will be in the Avigilon Instance. Please ensure access to MSI Jira & MSI Confluence, both are accessible through OKTA. For additional information and details please refer to the Atlassian migration page

Deployment considerations for credentials with Avigilon Alta

Avigilon Alta access control offers the ability to leverage your mobile phone as your credential to unlock an entrance via our reader. We do this using our patented, Triple Unlock technology that leverages Bluetooth®, Wi-Fi, and LTE simultaneously to send three signals from the phone to the reader. The three signals are pitted against each other and the first one to arrive unlocks the door; the other two are discarded.

 

When a credentialed user approaches the reader and enters the overlapping Bluetooth range of both the phone and the reader, the reader makes a handshake with the mobile phone (in listening mode), sustaining the connection. The reader waits for a trigger event to activate the unlock process. The trigger event could be a hand wave in front of the reader, touching the reader, or pressing the unlock button on the phone app.

In addition to mobile, Avigilon Alta also supports other credential formats for unlocking entrances via the reader: physical cards/badges, physical key fobs, as well as the option to enter a keycode (on the keypad reader only.)

Given all of the different access capabilities and the underlying technologies they rely on, there are optimal reader and mobile app settings and installation and environmental considerations to ensure a reliable unlock experience.

The purpose of this document is to review the various factors that may affect the unlock experience and provide guidance on what you as a customer or installer should consider when architecting your Avigilon Alta access control deployment.

Mobile Device Considerations

A variety of factors can affect a device’s compatibility as well as performance when used as a mobile credential. These include, among other things, the type of phone, settings, configurations, and current state. The below section will cover requirements and considerations that should be taken into account when exploring mobile credentials.

Basic compatibility requirements

Mobile credentials can be used with Android or iOS devices, and the smartphone must be running a version of the OS that is supported by the approved app, available in the Apple App Store, and the Google Play Store (please refer to the guidance in the App store to see the current supported OS versions). The device must also have LTE, Wi-Fi, and Bluetooth capabilities.

Configuration and current state

In order to use one’s phone as a credential, it must be powered on. If it has zero battery or is powered off, one should not have the expectation that the phone can be used to unlock an entry via the Avigilon Alta Access control system. Secondly, the Alta access application must be installed on the phone for unlock to work. In addition to having the app installed, the user must be issued a credential by the administrator, and the credential must be provisioned on the App installed on the phone. Third, the phone must have Bluetooth, Wi-Fi, and/or LTE capabilities turned on, and the app must be given explicit permission to use Bluetooth, Wi-Fi, and/or LTE capabilities when installing the app. Without these radios enabled and permissions granted, the phone will not be able to be used as a mobile credential. For example, if a user has their phone in airplane mode with Bluetooth, Wi-Fi, and LTE disabled, their phone will not be able to send out a signal to the reader.

Note that there is a function called Guest Pass which can be issued one-off to allow guests access to a reader through their mobile device. The user is sent a web link to click on their device via the browser running on the smartphone (this assumes access to the internet) that allows them to use a reader to unlock an entrance by sending a command over the internet.

  • Near Field Communication (NFC)

In some circumstances, the Android version of the Avigilon Alta mobile app can use NFC on Android devices as an additional authentication method. However, you need to confirm that the version of the mobile app you are running is one that does support NFC and that the phone supports NFC to be able to take advantage of this authentication method. At this time, NFC is not yet supported on Apple devices.

  • Restrictions and permissions on the phone

If your organization uses a mobile device management system that restricts capabilities on the phone, such as enabling or disabling Wi-Fi or Bluetooth, or limiting the installation of apps and credentials, it may limit the ability to use tools needed to make the mobile credentials work.

Performance Variables

One of the reasons that we developed our Triple Unlock technology was to compensate for the variations in performance of any single factor. This reduces the reliance on one technology, such as just Bluetooth or just Wi-Fi, and eliminates the risk of having a single point of failure. While it is well known, it is worth stating that LTE coverage in certain regions, cities, or even buildings or areas of a building, can vary greatly and impact the ability to send and receive communications on the LTE network. Similarly, Bluetooth capabilities vary across Apple and Android, and different versions of phones. Thus, there is a variable range in how Bluetooth may function on different devices, and as a result, may be unreliable at times. Finally, Wi-Fi performance depends on the strength of the Wi-Fi signal, the phone’s ability to connect to the Wi-Fi network, and the strength of the overall network connection. Sometimes Wi-Fi networks are well-connected and highly performant, and sometimes they are not.

  • Bluetooth Performance

Performance data from our end users show that Android smartphones (across a wide variety of manufacturers) prior to 2023 have demonstrated less effective Bluetooth performance than comparable year iOS phones when looking at a 5-year period.

Readers

Just like with mobile phones, there are a variety of factors that affect reader performance, the type of credentials that a reader can use, and the ability of the reader to communicate with a mobile device. These factors include settings, proximity to other readers, connectivity, and type of reader.

 

  • Settings

Readers that are installed in close proximity to each other may reduce the performance of mobile credentials. This is because multiple readers may be trying to connect to the same mobile phones at one time, creating a lag in response time for the entrance unlocks, as well as confusion as to which intended entry that device is meant to unlock.

 

To mitigate these issues, we do not recommend using Wave to Unlock in environments where many readers are placed together, such as when there are multiple turnstiles at an entrance. In this deployment scenario, we recommend configuring the readers in Turnstile mode, which reduces the read range on the reader to a shorter distance. In this mode, the phone must be presented within inches of the reader to trigger the unlock.

Note that Wave to Unlock prioritizes convenience over more stringent security, as anyone can trigger an unlock by waving their hand in front of a reader if there is a credentialed phone within range, regardless of whether or not the credentialed user was trying to enter. Therefore, Wave to Unlock is not recommended in very high-security environments, unless used with a secondary authentication method.

 

  • Proximity of users

Users with mobile credentials on their person that are stationed next to readers, such as a receptionist or a security guard, may inadvertently activate the reader such that someone else could trigger the Wave to Unlock using the other person’s credentials to authenticate. In these situations, one should not place a credentialed user within Bluetooth range of an installed reader to ensure security and reduce risk. Alternatively, the Bluetooth range on the reader can be reduced so that it doesn’t overlap with the credentialed stationary user.

  • Connectivity

The ability of the reader to connect to and communicate with the credentialed device impacts the performance of mobile credentials. This can be negatively impacted by poor LTE signal, weak or unreliable Wi-Fi, or Bluetooth interference. Physical obstructions can also impact connectivity, such as a wall or pillar blocking line-of-sight to the phone. 

There are some things that can be done to mitigate these issues. For example, if your location has a poor LTE signal, you could consider an LTE booster to improve the signal. Wi-Fi connectivity may be improved by installing a Wireless Access Point closer to the readers. Additionally, set the read range to the longest distance, ensure a clear line of sight between the phone and the reader, and ensure there are no other readers in close proximity.

  • Type of reader

The type of credentials that can be used depends on the type of reader you install. As a rule, all Avigilon Alta readers support mobile credentials, as well as physical credentials such as a fob or keycard. Keypad readers support using a keycode as a credential.

 

If multi-factor authentication is required, this can be achieved using a keypad reader (keycode plus physical or mobile credentials). Or, a secondary reader can be connected to an Avigilon Alta reader. For example, connecting a biometric reader would enable you to require a fingerprint and a physical or mobile credential to access.

  • Environmental Conditions

As touched upon above, the location of your reader has a lot to do with the performance of mobile credentials. Certain locations may have poor Wi-Fi or connectivity, which reduces your ability to use multiple options for unlocking. For example, a parking garage may have no Wi-Fi or LTE single, so it must rely on Bluetooth. In these deployment scenarios, you may want to consider whether it makes sense to support physical credentials for access.

General Recommendations

In most situations, we recommend users wave their phone close to the reader instead of relying on their hand to trigger an unlock. This allows organizations to achieve a balance between security and convenience while creating a more consistent unlock experience. Using a phone to activate the reader allows you to set the BLE range to low, reducing issues that may be caused by another mobile credentialed user in close proximity. Longer range BLE settings (those that would support waving a hand in front of the reader instead of a phone) are best reserved for entrances that require a lower security posture, like general lobby entrances or parking gates. 

Additionally, training users to wave their phone in front of a reader creates a consistent approach that maximizes the use of all connection types – Wi-Fi, LTE, Bluetooth, and NFC (currently only available on Android). This reduces the reliance on one technology and ensures the most reliable unlock experience.

A note on personal choice

In some circumstances, individuals may be unwilling or unable to install the mobile app on their smartphone. If you think this may be a concern in your deployment, we recommend conducting a survey or an audit amongst end-users to determine the likely adoption of mobile credentials. It may also make sense to evaluate your organization’s use of mobile phones in your environment, and what options may be available for offering the mobile app. Many organizations end up offering end users the choice to install the Alta Access mobile app or be issued a physical credential. 

Furthermore, as mentioned earlier, in the process of installing the app, the end user must choose to allow the app permissions on their phone for it to function properly. And, the end user must choose to turn on various settings on their phone: LTE, Bluetooth, and Wi-Fi, and they must choose to leave their phone on in order for it to work. 

The fallback for all situations is a physical credential. Avigilon Alta supports a variety of encrypted and unencrypted keycards and fobs, which are always viable options in cases where mobile credentials are not a good fit for users or the environment.