Biometric Passkey: FAQ
The basics
What is Biometric Passkey?
Biometric Passkey combines device-bound FIDO2 credentials with identity-bound biometric assurance. The same credential supports two runtime-selectable verification modes — the local device unlock for routine sign-in, and a live biometric match against the enrollment reference for higher-risk actions — while your application keeps the session, risk policy, transaction context, and final authorization decision. It is delivered as a mobile SDK, a self-hosted backend, and a management dashboard. See Biometric Passkey: Introduction for the platform overview.
Are Biometric Passkey credentials synced across devices or device-bound?
Device-bound. Each passkey private key is generated and used inside the device's hardware-backed key store — the Secure Enclave on iOS and the Android Keystore on Android (StrongBox when the device exposes it, TEE otherwise) — and is non-exportable. Keys are not synced to the cloud and cannot be copied to another device. A user who wants a passkey on a second device runs the enrollment flow on that device.
Which platforms are supported?
The public SDK targets native Android (API 28 / Android 9 and later) and native iOS (17.0 and later). Some optional features have stricter floors — for example, the Android Credential Provider integration requires Android 14 (API 34) or later. Cross-platform step-up uses your enrolled mobile device to complete biometric verification for browser-initiated sessions on web or desktop, so the platform does not include a desktop or browser SDK. Other mobile platforms such as HarmonyOS are not in the current public scope. See Biometric Passkey: SDK integration for the full per-feature requirements matrix.
Which Biometric Passkey versions are supported?
See Biometric Passkey: Version policy for the supported release-line policy. Before combining backend, database schema, Android SDK, and iOS SDK versions, check the compatibility matrix on that page.
How should you plan upgrades?
Start from the release notes and Biometric Passkey: Version policy. Upgrade backend releases with the matching migration image, validate flows in a non-production environment, and roll SDK upgrades through your normal mobile release process.
Why is the credential bound to the mobile app rather than web or desktop?
Biometric Passkey is designed around a mobile device that can hold a hardware-backed, non-exportable private key and run the biometric capture needed for higher-assurance checks. The passkey private key stays inside the Secure Enclave on iOS or the Android Keystore on Android, while the SDK uses the mobile camera and identity verification workflow for enrollment, step-up, and recovery. Web and desktop sessions can still start high-assurance actions through cross-platform step-up, but the live biometric capture and assertion signing happen on the user's enrolled mobile device. Your backend chooses how to hand off the session to mobile.
Are the Biometric Passkey SDK and API the same as the Entrust IDV SDK and API?
No. The Biometric Passkey SDK and API are exclusively for the management of biometric passkey credentials and are distinct and separate from the Entrust IDV SDKs and API.
Enrollment and identity binding
How is the biometric reference linked to the passkey credential?
During enrollment, the SDK runs an identity verification capture on the device (document scan and live face) and, in parallel, produces a hardware-backed passkey on the device. When the workflow completes, the identity verification provider delivers the encrypted biometric token (EBT) to the Biometric Passkey backend through a webhook — the SDK does not carry the EBT. The backend then binds the new device-bound passkey to the user. The EBT is stored once per user and is reused across all of that user's device-bound passkeys for later step-up and recovery. See Biometric Passkey: Integration overview for the component map.
Authentication
How does passkey authentication work?
Biometric Passkey supports two verification modes that share one device-bound FIDO2 credential:
Routine authentication is a standard WebAuthn ceremony run directly by your IDP against the device-bound credential. The user unlocks the credential with the platform authenticator — Face ID, Touch ID, or the device passcode — and the device signs the assertion using its hardware-backed key. Your IDP verifies the assertion. Biometric Passkey and the identity verification provider are not involved in this path.
Step-up authentication adds a live biometric capture for higher-assurance actions. The identity verification provider matches the capture against the encrypted biometric token (EBT) captured at enrollment. The SDK only surfaces the WebAuthn assertion to your application on a successful match, and your IDP then verifies the assertion as usual.
How does browser sign-in work with a Biometric Passkey credential?
Biometric Passkey does not implement routine browser sign-in. For day-to-day, low-risk browser sign-in, your IDP runs the standard WebAuthn ceremony directly against the user's platform passkey and Biometric Passkey is not involved. For a high-assurance action that starts in a browser or desktop session, use cross-platform step-up: your backend opens a cross-platform session and receives a single-use handoff token. Your backend decides how to deliver that token to the user's enrolled mobile device, such as by push notification, QR code, or deep link. The SDK on mobile resumes the session, runs a live biometric capture against the user's EBT, and returns a WebAuthn assertion that your IDP verifies, while the browser learns the outcome by polling your backend. The desktop or browser session does not need a camera. See Biometric Passkey: Core API integration for the full endpoint contract.
Account recovery and additional devices
How does adding a passkey on an additional device work?
The path depends on whether the user still has access to a previously enrolled device:
- The user still has an enrolled device and your backend already holds their EBT: run the registration flow on the new device and supply the existing EBT. The identity verification workflow matches a fresh biometric capture against that reference instead of re-capturing identity documents, and the SDK creates a new hardware-backed credential on the new device.
- The user has lost the previously enrolled device: use the account recovery flow instead. Biometric Passkey matches a fresh biometric capture against the user's stored EBT and a replacement credential is registered on the new device. The user-scoped EBT is reused unchanged.
See Biometric Passkey: Core API integration for the full endpoint contract.
Can a synced passkey replace adding a new device-bound credential?
No. Biometric Passkey private keys are non-exportable and are not synced to the cloud, so there is no synced credential that could substitute for a per-device enrollment. A user who wants a passkey on a second device runs the enrollment flow on that device; because the user already has a stored EBT from their first enrollment, the workflow can be a verify-only biometric match against that reference rather than a fresh document capture. The result is one user-scoped EBT plus one device-bound credential per enrolled device.
