Known Limitations
This section lists known limitations regarding the Nevis Access App. These limitations are independent from any specific Nevis Access App release and are not related to a configuration issue.
For issues caused by potentially solvable misconfigurations, refer to the chapter Known Issues.
Android
The Android Biometric Authenticator only supports Class 2 and Class 3 biometric sensors.
For security reasons, we recommend allowing only Class 3 sensors. Only some (Google Pixel 4, Google Pixel 4 XL, Google Pixel 8, Google Pixel 8 Pro, Google Pixel 8a, Google Pixel 9, Google Pixel 9 Pro and Google Pixel 9 Pro Fold) Android devices with Android 10+ support Class 3 for Face Authentication, therefore the Android Biometric Authenticator can only be used with fingerprint sensors for all other devices with Android 10+.
If Class 2 sensors are allowed, face and iris recognition will be supported for other devices, such as the Samsung Galaxy 21. However, allowing Class 2 sensors is not recommended for security reasons.
Be aware, that most devices offer face recognition without a dedicated sensor, and are not compatible. Devices identified to be working are listed here
Operating System | Manufacturer/ Device | Issue | Description | Solutions |
---|---|---|---|---|
Android 10 | Nokia | The Access App does not receive push messages (infrequently/random). | On Nokia Android 10 phones, push notifications sometimes do not arrive. This is completely non-deterministic. This known issue is due to the fact that Nokia seems to kill apps faster than other Android device manufacturers to extend battery life. This issue seems to be related to the Mediatek DuraSpeed (com.mediatek.duraspeed) application. We highly recommend not using this app. | Use QR codes as fallback. Disable "Battery Optimizer" apps. |
Android 9 and older | Huawei / potentially more | The Access App does not receive push messages (infrequently/random). | Push notifications sometimes do not arrive, or they arrive only when the application is in the foreground. This is completely non-deterministic. This known issue is due to the fact that some vendors seems to kill apps faster than other Android device manufacturers to extend battery life. | Use QR codes as fallback. Disable battery optimization in the operating system settings. |
all | The Access App is not working, or closing right after start. | Some (usually cheaper) Android devices lack the required hardware capabilities (cryptographic hardware) to use the Access App securely. The Access App detects the lack of this hardware and deliberately does not work. | There is no solution other than to buy a new Android device with the required hardware capabilities. | |
all | all | Removing the device lock makes the Access App useless for authentication. | If you remove the device lock, you can no longer use the Access App for authentication. | The user must register again. |
all | all | Deep links are not working on some mobile browsers. | Some mobile browsers do not support deep linking as currently made available by the Access App. Usually non-standard browsers might not correctly recognize and handle deep links.This specifically impacts browsers such as the QQ, UC, and 360 browsers.Correctly handling a deep link involves opening the Access App and triggering the operation. | As an alternative to deep links, we recommend using custom URIs. Custom URIs provide the same functionality but are not impacted by this issue.For more information, see Link channel. |
all | all | Deregistration does not work. | The Access App only supports cookie regeneration during authentication (in the IdentityCreationFilter). Regenerating cookies in authenticated sessions is not supported. | Update the nevisProxy SecurityRoleFilter configuration and set the parameter renewAuthentication to "none". |
all | all | Device name containing emojis does not show up correctly. | Emojis are not supported as part of the device name for the Identity Suite solution, only the Authentication Cloud supports using emojis as part of the Device name. | Remove emojis from the Device name. |
Android 9 and older | all | Face and Iris recognition is not supported. | The face and iris recognition require Android 10 or later versions, and that the device has a Class 3 (Strong) biometric sensor. | Upgrade to Android 10 or later. |
Android 10 | all | Fingerprint, face and iris recognition do not have a device credential fallback. | The user is not allowed to provide device credentials (PIN, gestures or password) as fallback when using the fingerprint, face, or iris recognition. | Upgrade to Android 11 or later. |
Android 10 and older | Pixel 4a, Pixel 5 | The authenticator is invalidated if the user removes biometric credentials in the OS settings and there are OS credentials remaining. | When using Pixel 4a and Pixel 5 devices, the authenticator is also invalidated if the user removes biometric credentials in the OS settings, and there are still biometric credentials defined. See this bug for details. | The user must register again. |
all / HarmonyOS | Huawei (known devices affected: Huawei Y5p Huawei P20 Pro) / potentially more | The Access App does not receive push messages (not once). | As an additional prerequisite for Android devices, the Google Play Services app has to be installed. The Google Play Services app is usually preinstalled on Android devices but may be missing on some models. | Use QR code as an alternative. Push notifications on Android rely on the Google Play Services which is not present on Huawei devices. |
all / HarmonyOS | Huawei / potentially more | Android app links do not behave as expected. | Links rendered in a browser which should trigger the Access app to either start a registration or authentication do now behave as expected. This may mean that nothing at all is happening or (dependent on the integration) the Google Play store page for the app is opened. | Use the Nevis recommended custom URI schemes. App links rely on the Android Chrome browser as well as the Google Play Services to work correctly. Both are not present on Huawei devices. |
all | all (Google Lens) | Scanning QR codes with custom URI schemes outside the Access App does not open the installed Access App and start the operation. | Google Lens, which is the default Android camera application, does not handle custom URI schemes. | Use app links instead of generating a QR code. |
all | all | Push messages cannot be sent after the user enables notifications in the operating system settings. | The Access App updates the backend configuration when it detects that notifications are disabled. This way the backend can inform the end-user why push messages cannot be sent. To be able to send push messages again, the user must enable notifications in the operating system settings and then open the Access App, so that the the Access App can update the configuration in the backend accordingly. | Open the Access App after enabling the push notifications in the operating system settings. |
all | all | The Biometric Authentication Passcode Fallback cannot be used with the Remove Biometric Authenticator on New OS Biometrics feature. |
iOS
Operating System | Model | Issue | Description | Solutions |
---|---|---|---|---|
all | all | Turning off the device passcode invalidates the existing Access App registration. | The Nevis Access App requires a device passcode to function. Removing the device passcode, by pressing the Turn passcode off button in the OS settings, leads to the invalidation of the existing Access App registrations.NOTE: you can safely add and remove fingerprints or change the device passcode in the OS settings - this does not have any effect on the existing Access App registration. (However, you need the OS fingerprint to use the fingerprint authentication method.) | (Re-)enable the device passcode and re-register yourself with the Access App.In the backend, previously registered credentials are still associated with the user. Clean them up manually. |
all | all | The application is hanging on the loading screen when processing multiple push notifications at once (rare). | In some cases, where poor network conditions cause push notifications not to be received by the device, the push message is re-sent by the user to restart the operation.When the network connection is restored, all push notifications arrive at the device and are started if the application is in the foreground. The application does not handle this situation properly. As a result, it is stuck on the loading screen. | Restart the application and trigger the operation again. |
all | all | Deregistration does not work. | The Access App only supports cookie regeneration during authentication (in the IdentityCreationFilter). Regenerating cookies in authenticated sessions is not supported. | Update the nevisProxy SecurityRoleFilter configuration and set the parameter renewAuthentication to "none". |
all | all | Device name containing emojis does not show up correctly. | Emojis are not supported as part of the device name for the Identity Suite solution, only the Authentication Cloud supports using emojis as part of the Device name. | Remove emojis from the Device name. |
all | all | Push notifications not arriving when using a screen mirroring app. | With a screen mirroring app, push notifications are not arriving at the device.One app which seems to cause this issue is called ApowerMirror. | Disable the app and screen mirroring or use QR code as an alternative. |
all | all | Handling incoming push notifications slightly differently comparing to Android. | Generally if the user is not viewing the Home screen and receiving an incoming push notification, then the user is asked to postpone or process the incoming message. In case a Biometric verification is in place for an operation, the incoming push messages are postponed automatically during the verification process. This is due to the reason that the App doesn't have the possibility to pause and resume the (OS) Biometric verification process. | As notifications are postponed, they are listed in the Notification Center, so the represented operations can be executed later by hand. |
15.0 >= iOS < 16.0 | all | The automatic clean-up is not working after re-installation. | We disabled the automatic clean-up feature for the respective iOS versions, as Apple introduced a bug in iOS 15.0 which made it impossible to detect whether the Access App has been installed at the first time (or re-installed). Without this the end-user would face with random Account and Registration loss at app-start. From iOS versions >= 16.0 we haven't been experiencing any issue in this regards, so we re-enabled automatic clean-up feature from this iOS version on. | As automatic clean-up is not working, the end-user can only manually initiate resetting the Access App by using the "Reset Nevis Access" button in the Settings. |