Security considerations
Assumptions
The Nevis Mobile Authentication SDK relies heavily on the security components provided by the manufacturer of the device. The SDK assumes that these components are secure and therefore delegates the responsibility to the manufacturer.
The specific security components relied upon are as follows:
| Platform | Security Element |
|---|---|
| all | Device Screen Lock |
| all | Secure Storage of the biometric data |
| all | Verification of biometric data is executed in the Trusted Execution Environment (TEE) |
| all | Biometric Sensors |
| Android | Android Keystore System |
| iOS | Keychain |
| iOS | Secure Enclave |
Despite the reliance on the security components of the device and OS manufacturers, the SDK is hardened to further mitigate security risks and lower attack scenarios originating from the mobile application or the SDK. For more information, see the SDK hardening and flavors section.
The following security considerations are important to understand the impact they have on private key protection. For more information on private key protection, see the Key Protection chapter.
Communication
TLS/HTTPS
To ensure secure end-to-end transit of data between the Nevis Mobile Authentication SDK and the Nevis Mobile Authentication backend, both must be configured to use TLS. The SDK is configured to use only TLS connections and any calls to the backend without TLS fails.
Depending on the flavor of the SDK you use, the requirements are different.
release flavor
iOS
Apple has strict requirements regarding trusted TLS certificates that are imposed since iOS 13. You need to ensure that the public-facing certificates match these requirements or the connection between the iOS app using the SDK and the backend fails.
It is possible to use self-signed certificates by trusting them in the OS settings.
Android
In the case of Android, the SDK relies on the root Certificate Authorities (CAs) of the operating system. These CAs are updated using over-the-air (OTA) updates by the device vendor.
In Android you can add trusted Certificate Authorities in the network security configuration of your application. This may be needed if your server uses a certificate signed by a recent CA that is not contained in the operating system of old Android devices that are no longer updated.
Note that in Flutter the Android network security configuration is referenced through the io.flutter.network-policy attribute as described here.
debug flavor
The Nevis Mobile Authentication SDK supports the use of self-signed certificates and non-trusted CAs for TLS connections in the debug flavor of the SDK to simplify internal development and testing.
iOS
To enable self-signed certificates in iOS apps, the enclosing app must be configured to allow arbitrary loads in the App Transport Security Settings within its Info.plist.
Android
No action is needed in the debug flavor of Android to trust all certificates.
Ensure that your backend is using valid root CA signed certificates when moving to production (where the release flavor must be used).
Ciphers
iOS
The iOS SDK uses URLSession for all HTTPS connections.
Taken from the official documentation:
App Transport Security provides default connection requirements so that apps adhere to best practices for secure connections when using NSURLConnection, CFURL, or NSURLSession APIs. By default, App Transport Security limits cipher selection to include only suites that provide forward secrecy, specifically:
ECDHE_ECDSA_AESandECDHE_RSA_AESin Galois/Counter Mode (GCM), Cipher Block Chaining (CBC) mode.
Android
The Android SDK uses a third party library for HTTPS connections. The SDK limits the supported ciphers to the following list considered to be secure and best practice:
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
Authorization handling
Authorization headers such as Cookies or JWT tokens returned by the SDK after a successful authentication are not cached by the SDK in any way. The SDK directly parses and returns the HTTP authorization headers. In addition the iOS SDK returns the authorization cookies from ephemeral url session in case no cookie was returned in HTTP headers.
Out-of-band encryption
Out-of-band communication channels are one way the Nevis Mobile Authentication backend uses to communicate with the mobile application. To ensure confidentiality, authentication content is sent end-to-end encrypted to the mobile applications. The Javascript Object Signing and Encryption (JOSE) framework is used for this purpose. The SDK generates the necessary asymmetric key material, and securely stores it on the device. To establish the encrypted communication channel, the public key can be sent to the backend when registering the registration token.
Encrypting out-of-band content eliminates the following main security concern: If an attacker reads an unencrypted message, they could potentially extract the tokens required to retrieve the plaintext of the transaction text in out-of-band transaction confirmation operations. But they will not be able to confirm the transaction, since explicit user verification is required.
Further information regarding push notification encryption can be found in the Out-of-band message transmission chapter of the nevisFIDO documentation.
Algorithms
Out-of-band messages are encrypted by the nevisFIDO backend using JWE and keys with a P-256 curve (secp256r1, also called prime256v1).
Device / Dispatch target services
The Nevis mobile SDK uses JWS (JSON Web Signature) for performing operations which require accessing protected HTTP endpoints but don't require explicit user interaction (such as providing authentication credentials) such as Changing device information or Fetching pending out-of-band operations. Only the app / device having the JWS private key is able to modify information associated with it (e.g. Device A is not able to change or obtain information of Deviec B, even if they are associated with the same user account in the backend).
Specifically, the following nevisFIDO HTTP endpoints are protected with JWS:
The JWS requests are signed using keys with a P-256 curve (secp256r1, also called prime256v1).
SDK hardening
The Nevis Mobile Authentication SDK uses a professional hardening and attack prevention product to harden the Android and iOS SDKs.
In a typical attack scenario, an attacker roots/jailbreaks the mobile device to bypass the built-in security of the device. On such devices, the attacker is able to access and modify almost anything stored in the operating system of the device. For this reason, the SDK performs various checks to inspect the integrity of the system. Furthermore, the SDK is extensively obfuscated and protected against tampering and reverse engineering. It detects any attempt at modifying normal execution of the operations.
When any kind of threat is detected, the SDK prevents normal application execution following one of these patterns:
- Crashing the app.
- Stopping responses to any operations.
- Throwing an exception.
These measures ensure that all of the authenticators protecting the private key are robust against the most wide-spread attacks originating from the mobile application or the SDK itself.
Application obfuscation and hardening
It is generally recommended to perform a minimal obfuscation on any kind of application, no matter what the intended use case or target security level is.
The SDK provides some indirect enhanced security for the integrating app. However, the SDK does not take care of sensitive information generated by the application, which goes beyond the scope of the SDK use cases. For such high security applications, it is recommended that they also use application level hardening to manage sensitive data.
Pay attention to the following recommendations in case application level obfuscation or hardening are intended:
- Ensure that no obfuscation or hardening takes place for any SDK internals or exposed interfaces (clear separation between application code and SDK).
- Specifically for hardening, use products from the same vendor as the Nevis Mobile Authentication Client SDK, inquire us for more information.
The use of other hardening frameworks is only supported on a best-effort basis. We strongly recommend using products from the same vendor. Nevis cannot guarantee successful hardening of the application layer with other frameworks in any scenario.
SDK flavors
To satisfy customers with the highest security requirements, the Nevis Mobile Authentication SDK is hardened with state-of-the-art protection mechanisms. Due to the restrictive protection mechanisms, the SDK is available in two build flavors:
debugis used during the development phase of the mobile application where only a subset of the protection mechanisms are available. Usingdebug, the application can run in a simulator or emulator environment and supports self-signed certificates for TLS.debugis intended for testing use, and is not to be used in a production environment.releaseis used in production, where all protection mechanisms are activated. Thereleaseflavor requires your application to be finalized.
It is prohibited to use the debug flavor in production environments (e.g. app builds shipped to end users via app stores)!
Ensure your backend is using valid, root CA signed certificates with the correct hostname when moving to production!
debug flavorThe following specific guards are not present in the debug flavor:
Android:
- Emulator detection
- Debugger detection
- Root detection
- Checksum
- Hook detection
- Dynamic instrumentation detection
iOS:
- Debugger detection
- Simulator detection (Dynamic instrumentation detection)
Tamper Detection
SDK hardening includes extensive measures to detect tampering by malicious parties. Tampering is unauthorized modification of software code. Typically, people tamper with software for the following reasons:
- To gain unauthorized access to a program
- To modify code or inject malware
- To reverse engineer a program and lift code or other intellectual property
Attackers typically tamper with a compiled application and have no access to the original source code. They must find ways to understand the compiled program, locate its vulnerabilities, and modify the binary.
Runtime tamper actions are triggered by various manipulation attempts such as:
- Jailbreaking/rooting devices
- Attaching debuggers
- Bypassing of security-relevant code
- Manipulating code
In these scenarios, the SDK will cause the app to crash by triggering a non-recoverable exception.
The hardening framework defends against tampering by applying a set of protection techniques to source code. The units of code that implement these techniques are called Guards.
The exception itself is obfuscated and prevents drawing conclusions regarding the root cause of the app crash. The application using the SDK is unable to react or prevent the app crash in any way. This is intentional, crashing the application fast mitigates the risk of exposing any sensitive information to a possible attacker.
Apart from runtime tamper actions, the SDK is protected against reverse engineering using obfuscation and breaching the binary integrity of the archive.
Tamper guards
The following guards are used to protect the Nevis Mobile Authentication SDK. Be aware that this is not a complete list, it focuses on the most important guards in use.
Many of the guards listed in the table are used more than once and in several areas of the code. Additionally, they are protected themselves by a guard network.
Root detection
Root detection guards detect whether the mobile device, on which the application is running is modified to allow users or applications privileged access to the operating system. This guard is only available on the Android platform.
Jailbreak detection
A Jailbreak Detection guard detects that an application is running on a jailbroken device. An application running on a jail-broken device is more vulnerable to attacks. This guard is only available on the iOS platform.
Debugger detection
A debugger detection guard executes an algorithm to detect whether a debugger is attached to the application.
Hook detection
Hooking attacks can change the behavior of the app by redirecting a method call to an attacker’s method, or by replacing or modifying an app resource. Hook detection guards can detect such attacks by checking for the following:
- On the device, the presence of hook software–software that is capable of hooking methods.
- Hooked methods in the protected app.
- Replaced app resources.
- The presence of apps that require the hook software to be present
Emulator detection
Detects whether the application is running in an emulator.
Dynamic instrumentation detection
The Dynamic Instrumentation Detection guard detects the presence of the following frameworks:
- Frida - A dynamic instrumentation toolkit that allows its users to deconstruct and reverse engineer Android Apps. This guard can detect even when Frida is using non-default settings, or when Frida is not actively instrumenting the protected application
- GameGuardian - An app that allows its users to hack and cheat in Android games.
Checksum
A Checksum guard detects whether any code within DEX files is modified by computing a checksum of the code when protection is applied and then computing the checksum again at runtime.
Renaming
The renaming guard replaces the names of packages, classes, methods, and fields with unintelligible symbols. An attacker attempting to reverse engineer a protected program, will see meaningless names. If the attacker succeeds in decompiling the bytecode (.class files), the attacker will also see meaningless names in the decompiled source code (.java files).
String encryption
A string encryption guard encrypts all literal strings in the target input files. String encryption protects against static and dynamic analysis and reverse engineering. String decryption is performed at runtime, when the strings are used.
Debug Info
Removes contextual debugging information from Java class files.
Control flow
The control flow obfuscation guard scrambles Java bytecode, making it difficult for an attacker who succeeds in decompiling or disassembling the protected program to understand its control flow. Because obfuscation does not affect the semantics of the program, the protected program has the same functionality as the original.
SDK updates
It is the responsibility of Nevis Mobile Authentication SDK consumers to decide how and when to update the Nevis Mobile Authentication SDK. To include the latest security fixes, we strongly recommend that you upgrade to the latest versions of the Mobile Authentication SDK on a regular basis.
A common approach to update mobile applications, and therefore the libraries used by them too, is to create an update service hosted on a backend. The application contacts the service to determine whether the app itself needs to be updated, regardless of the SDK version. The decision to update the SDK, or any other dependency, is made by developers during implementation.
The nevisFIDO backend provides a service endpoint of this type that can be used to implement this functionality in a custom mobile application.
Device loss
Mobile authentication provides two-factor authentication based on possession of the device, and an authentication mechanism such as a PIN or biometrics. This means that losing the device compromises one of the factors, that is, possession of the device. Therefore, users should be requested to report device loss, so that the device and its associated credentials can be disabled for authentication. We recommend implementing one of the following methods to disable the lost device for authentication:
- Provide a self-service restricted to removing registered devices and credentials after authenticating with an alternate authentication method or through an identity verification service.
- Provide a support hotline where users can report the loss of their device. After manual authentication of the user, the device and associated credentials can be removed by the support desk agent.
Device lock removal
The authenticator private key is a highly sensitive protective asset that is securely stored in hardware. Hardware storage is only possible if the device is protected with a device lock screen.
If the device lock screen is removed, even temporarily, the keys stored in the hardware-backed Keystore or Secure Enclave are wiped by the operating system of the device.
The Android SDK does not enforce device lock presence in the debug flavor, this is to ease automated testing. The release flavor enforces the presence and throws a specific error if the device lock is not present.
There might also be other situations in which the operating system of the device decides to wipe the content of the hardware-backed Keystore or Secure Enclave. On newer devices and newer device OSes, adding an additional fingerprint might also wipe the keys. In any case, the Nevis Mobile Authentication SDK returns an error. The mobile application must handle this case correctly, and ask the user to go through a new registration process.
Compromise of OS
The private key stored in the Android Keystore System or Secure Enclave is well protected from extraction, since it is stored in hardware. However, a residual risk remains: The OS controls who is allowed to use the key and how. This implies that in the case of a compromised (that is, rooted or jailbroken) device, it is not possible to prevent an attacker from using the private keys for their own purposes. To reduce the risks of attacks originating from inside the Nevis Mobile Authentication SDK, several hardening measures are in place. They prevent use of the SDK if the device is compromised.
It is the responsibility of the manufacturer to ensure the security of these security elements. For more details about the responsibility of the manufacturer, see Security assumptions.
Nevis is not responsible for any consequences if the user installs the app on a rooted device.
Missing TEE for secure storage of key material
The SDK enforces the presence of a TEE module for securely storing the key material. If no such TEE is present, the SDK cannot execute any operation.
FIDO
The following chapters are directly related to the FIDO UAF protocol and specification.
FIDO UAF specification-related security considerations
This section lists and explains the Nevis Mobile Authentication answers and solutions to the chapter FIDO UAF Security Considerations in the official FIDO specification. The chapters and solutions referred to here require no direct action when using the component. They simply state the solutions of Nevis Mobile Authentication (if applicable) for the security considerations posed by the protocol specification.
4.3.1 Authenticator Security
Scope: Client
The SDK implementation follows access control for commands outlined by the FIDO UAF 1.1 specification. Explicit user verification is required for the registration and authentication operations.
4.3.2 Cryptographic Algorithms
Scope: Client and Server
The Android UAF authenticators support RSA-based authentication algorithms, however we consider them deprecated and the SDK will use the faster and more secure ECDSA (Elliptic Curve Digital Signature Algorithm) on nevisFIDO instances supporting it (nevisFIDO 7.2411.** or later with up-to-date metadata).
| Authenticator | AAID | Authentication Algorithm | Public Key Representation Format |
|---|---|---|---|
| Android PIN Authenticator | F1D0#0001 | ALG_SIGN_SECP256R1_ECDSA_SHA256_DERALG_SIGN_RSA_EMSA_PKCS1_SHA256_DER | ALG_KEY_ECC_X962_DERALG_KEY_RSA_2048_DER |
| Android Fingerprint Authenticator | F1D0#0002 | ALG_SIGN_SECP256R1_ECDSA_SHA256_DERALG_SIGN_RSA_EMSA_PKCS1_SHA256_DER | ALG_KEY_ECC_X962_DERALG_KEY_RSA_2048_DER |
| Android Biometric Authenticator | F1D0#0003 | ALG_SIGN_SECP256R1_ECDSA_SHA256_DERALG_SIGN_RSA_EMSA_PKCS1_SHA256_DER | ALG_KEY_ECC_X962_DERALG_KEY_RSA_2048_DER |
| Android Device Passcode Authenticator | F1D0#0004 | ALG_SIGN_SECP256R1_ECDSA_SHA256_DERALG_SIGN_RSA_EMSA_PKCS1_SHA256_DER | ALG_KEY_ECC_X962_DERALG_KEY_RSA_2048_DER |
| Android Password Authenticator | F1D0#0005 | ALG_SIGN_SECP256R1_ECDSA_SHA256_DERALG_SIGN_RSA_EMSA_PKCS1_SHA256_DER | ALG_KEY_ECC_X962_DERALG_KEY_RSA_2048_DER |
| iOS PIN Authenticator | F1D0#1001 | ALG_SIGN_SECP256R1_ECDSA_SHA256_DER | ALG_KEY_ECC_X962_DER |
| iOS Touch ID Authenticator | F1D0#1002 | ALG_SIGN_SECP256R1_ECDSA_SHA256_DER | ALG_KEY_ECC_X962_DER |
| iOS Face ID Authenticator | F1D0#1003 | ALG_SIGN_SECP256R1_ECDSA_SHA256_DER | ALG_KEY_ECC_X962_DER |
| iOS Device Passcode Authenticator | F1D0#1004 | ALG_SIGN_SECP256R1_ECDSA_SHA256_DER | ALG_KEY_ECC_X962_DER |
| iOS Password Authenticator | F1D0#1005 | ALG_SIGN_SECP256R1_ECDSA_SHA256_DER | ALG_KEY_ECC_X962_DER |
4.3.3 FIDO Client Trust Model
Scope: Client
The SDK implementation follows the trust model outlined by the FIDO UAF 1.1 specification.
To prevent access to protected data, several measures are in place such as:
- Usage and enforcement of TEE
- Tamper detection through SDK hardening
4.3.4 TLS Binding
Scope: Client
Not applicable - must be solved on the FIDO client-side. The client is responsible for server certificate validation.
4.3.5 Session Management
Scope: Client and Server
Client-side sessions are managed with cookies as outlined in the HTTP API authentication chapter.
4.3.6 Persona
Scope: Client and Server
The Nevis Mobile Authentication SDK does not support the concept of personas.
4.3.7 ServerData and KeyHandle
Scope: Server
Not applicable - must be solved on the FIDO server-side.
4.3.8 UAF Application API
Scope: Server
Not applicable - must be solved on the FIDO server-side.
4.3.9 Policy Verification
Scope: Server
Not applicable - must be solved on the FIDO server-side.
4.3.10 Replay Attack Protection
Scope: Server
Not applicable - must be solved on the FIDO server-side.
4.3.11 Cloned Authenticators
Scope: Server and Client
The SDK is resilient against cloning authenticators by storing the relevant key material in TEE that cannot be extracted. For more information, see the Secure Storage chapter.
4.3.12 Anti-Fraud-Signals
Scope: Server and Client
The anti-fraud signals outlined by the FIDO UAF specification are not supported by the SDK.
Specifically, the Sign counter and Reg counter are not implemented and as a result always provide the 0 value, as outlined by the specification.
Authenticator attestation
In the FIDO UAF 1.1 context, authenticator attestation ensures that only trusted authenticators can be used to authenticate with a relying party.
To achieve reliable authenticator attestation, an attestation private key can be embedded into a FIDO UAF authenticator during the manufacturing process. This key is the same for all authenticators of a certain type. This means that the attestation private key is bound to a specific authenticator class and not to a specific authenticator itself. Through verification of a signature provided by the authenticator, the server-side can validate whether it is really communicating with the type of authenticator that the client is claiming to use.
Since the FIDO UAF authenticators that are shipped with the Nevis Mobile Authentication SDK are software-based, they do not provide sufficient protection for attestation private keys (non-attested authenticators). This means that the attestation method used by the provided FIDO UAF authenticators is called Surrogate Basic Attestation.
Authenticator Security Properties
Up to three different authentication methods can be integrated into the mobile application. You can choose between:
- Application PIN authentication (Android and iOS)
- Application password authentication (Android and iOS)
- Device Passcode authentication (Android and iOS)
- Fingerprint authentication (Android)
- Face authentication (Android)
- Touch ID authentication (iOS)
- Face ID authentication (iOS)
All apart from application PIN, password and device passcode are referred to as biometric authentication methods.
The authenticator private key is a highly sensitive asset to protect. To enable as much protection as possible, the asymmetric key pairs are stored in a hardware-backed keystore. For iOS, the key is stored in the Secure Enclave. For Android, the private key is stored in the Android Keystore system.
Where the authentication methods differ, is how they access the key:
- The biometric authentication methods require users to provide biometric information. If there is a match, then the private key is unlocked to carry out the cryptographic operations.
- The device passcode authentication methods require users to provide PIN, password or gesture (depending how the device lock is configured in the operating system settings). If there is a match, then the private key is unlocked to carry out the cryptographic operations.
- The Application PIN and password authentication require users to provide a PIN (or password). If there is a PIN (or password) match, then the private key is unlocked to carry out the cryptographic operations.
The important difference relating to security is where the matching occurs:
- Application PIN and password authentication matching take place in the Nevis Mobile Authentication SDK itself.
- Biometric and device passcode authentication matching is carried out by the operating system itself.
As an additional security layer in Android, the FIDO UAF credentials for biometric, device passcode and fingerprint authenticators are protected by the OS requiring user authentication.
When running in a work profile and using a Xiaomi phone, the FIDO UAF credentials are not protected through user authentication. This is required because Xiaomi phones do not separate credentials across profiles, and user authentication does not work when running on the work profile.
Biometric Authenticator Invalidation on New OS Biometrics
Setting true in the Registration.invalidateOnNewOsBiometrics java, swift, objc, flutter, react native method will invalidate the biometric and fingerprint authenticators when the user adds new biometric credentials in the OS settings. This will increase the security, because an attacker with access to the device passcode can add biometric credentials and authenticate with your application otherwise.
Invalidating authenticators introduces a loss of convenience for end users: adding a new OS biometric credential does not imply necessarily that there is a security risk, but if the end-user adds it, a new registration will be required, because an invalidated authenticator cannot be recovered.
If you do not want to allow using the device passcode as fallback for the biometric authenticator (see Registration.allowDevicePasscodeAsFallbackjava, swift, objc, flutter, react native), we recommend invalidating the authenticator if new biometric credentials are added in the OS settings.
We have observed that 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.
PIN and password authentication
The Application PIN and password authenticators are less secure than biometric and device passcode authentication. This is based on the following factors:
The access mechanism of the PIN authenticator private key does not require biometric unlocking. As opposed to biometric and device passcode authentication methods, PIN and password verification is not carried out in the TEE. If the user uses a weak PIN or password, the app cannot detect that the PIN or password is compromised.
In the case of the password authenticators, the developer must define a PasswordPolicy during registration or password change. This policy validates that the password is not weak. In this policy the developer can impose the use of capital letters, special characters, or disallow using words in a dictionary.
In the case of the PIN authenticator, the SDK will perform some simple checks (like some length constraints), and the developer can add additional checks by defining a PinPolicy.
On user enrollment, the PIN (or password) is first validated and then stored in a secure manner. The PIN (or password) value itself is not stored on the system. To prevent attempts to crack the PIN (or password), its encrypted hashed value is stored.
On user verification, the same hashing process is applied to the PIN (or password) provided by the user, and then compared to the current value in the secure store. The PIN (or password) is considered valid if both values are the same.
To change the PIN (or password), the user is required to provide their current PIN in addition to the new one, so it can be verified before replacing the value in secure storage.
It is the responsibility of the app to handle the PIN (or password) entry. Given the sensitivity of this input value, special precautions should be taken to protect this value as well as possible.
Brute force attack prevention
The PIN and password authentication method is protected against non-sophisticated brute-force attacks.
In the case of a failed PIN (or password) verification attempt, the user must wait for a predefined amount of time before being able to attempt PIN (or password) verification again. After the second failed attempt, a cool-down time is added as a penalty. The following table shows the added penalty for each failed attempt:
| Number of failed attempts | Cool-Down in Seconds |
|---|---|
| 1 | 0 |
| 2 | 0 |
| 3 | 60 |
| 4 | 180 |
Once the number of failed attempts is determined, the cool-down is calculated. If cool-down is required, the current timestamp is saved and if a new PIN (or password) verification is started before the end of the cool-down period, verification fails automatically.
When user interaction is initiated, the timeout for user interaction is extended with the cool-down time, to circumvent an unwanted timeout of the current operation.
As a last defensive mechanism, the PIN (or password) Authentication registration is permanently locked after five failed attempts.
The SDK does not automatically remove locked authenticators - neither locally nor in the backend. When trying to access a locked PIN or password authenticator, the SDK will return an OperationError with error code FidoErrorCode.USER_LOCKOUT.
Authentication Key Revocation Scenarios
There are several scenarios that lead to FIDO authentication keys being revoked on the mobile client side:
- Executing a deregistration or a remove local data operation.
- Too many failed attempts entering the PIN or password of the PIN and Password authentication method.
- In iOS, removing the device lock screen (refer to Device lock screen).
- In Android, removing the device lock screen (refer to Device lock screen) when using the device passcode authenticator.
- Adding a new biometric credentials in the OS settings, if the biometric authenticator must be invalidated when doing so.