Liveness Settings
Liveness Configuration
Please note we are planning the following two changes in Q4 2025:
The default Liveness Setting will switch from High to Highest.
Any customer who has not actively configured the Liveness level will therefore be moved from High (the previous default) to Highest when they upgrade to the relevant SDK containing the change (tbc'd). Please pay close attention to the Changelog and discuss with your customer Success Manager or the Technical contact if you have any further questions.
We will rename the Liveness configurations to Level 1, 2 and 3.
Again please contact us for details or if you have any concerns.
Keyless SDK provides three officially-supported configurations for the liveness detection (antispoofing component), listed below from the lowest to the highest level of security:
PASSIVE_STANDALONE_MEDIUM
- for testing purposes onlyPASSIVE_STANDALONE_HIGH
- for most production use (current SDK default)PASSIVE_STANDALONE_HIGHEST
- for higher security production use (RECOMMENDED)
Increasing the security level increases the ability of the system to reject spoof attempts (true positive rate, or TPR). A higher security level also increases the genuine reject rate (false positive rate, or FPR) and the time required by the anti-spoofing module to make a decision.
For most production scenarios, Keyless recommends the use of PASSIVE_STANDALONE_HIGH
. This setting offers a good tradeoff between TPR, FPR, and time-to-decision. For scenarios that require a higher security level, we recommend increasing this setting to PASSIVE_STANDALONE_HIGHEST
.
Configuring livenessEnvironmentAware
The livenessEnvironmentAware
feature enforces stricter environmental checks during the liveness process and is an important layer of protection against biometric attacks. This is set to true
by default for the purpose of enhancing security.
Note that we have observed that, on a very limited set of devices, this may prevent some users from authenticating with Keyless altogether and in this case the SDK will return an 20021
error. To provide flexibility, we included the option to disable this check (by setting it to false
) in the event where it cannot fully function as designed due to limitations with these specific devices. When set to false
these devices will then be able to authenticate though without this layer being active.
For security purposes, we have not detailed exactly the data this liveness feature leverages, and have remained deliberately vague on the precise implications of the true/false configuration in order to avoid providing insight to attackers. We're of course happy to provide more detailed advice on request in a less public environment.
Relax liveness checks for testing purposes
Below follows a liveness configuration example for testing pruposes only should facilitate testing the happy path of "passing the liveness checks".
// ONLY FOR TEST
// Authentication Configuration
val authConfig = BiomAuthConfig(
livenessConfiguration = LivenessSettings.LivenessConfiguration.PASSIVE_STANDALONE_MEDIUM,
livenessEnvironmentAware = false
)
// Enrollment Configuration
val enrollConfig = BiomEnrollConfig(
livenessConfiguration = LivenessSettings.LivenessConfiguration.PASSIVE_STANDALONE_MEDIUM,
livenessEnvironmentAware = false
)
// De-Enrollment Configuration
val deEnrollConfig = BiomDeEnrollConfig(
livenessConfiguration = LivenessSettings.LivenessConfiguration.PASSIVE_STANDALONE_MEDIUM,
livenessEnvironmentAware = false
)
Last updated
Was this helpful?