TL;DR: Expo apps should add biometric sign-in for returning users, keep password fallback available, and clear stored credentials when Face ID or fingerprint enrollment changes invalidate local access, according to Clerk’s Part 2 guide. The control boundary is persistence and recovery, not convenience: biometric login is only safe when ownership checks, fallback sign-in, and explicit credential cleanup are handled separately.
At a glance
What this is: This guide explains how to implement biometric login in an Expo plus Clerk app while preserving password fallback, handling enrollment changes, and separating sign-in logic from authenticated credential management.
Why it matters: It matters because biometric convenience features can fail or persist in the wrong state unless teams treat credential ownership, recovery paths, and device-specific behaviour as identity controls rather than UI details.
Context
Biometric login is often treated as a front-end feature, but the security problem is credential lifecycle control. The real issue is deciding when locally stored credentials should be visible, reusable, or invalidated, and that decision changes between an unauthenticated sign-in screen and an authenticated settings screen.
This article sits in the space between human IAM and mobile app security: the sign-in flow must handle device biometrics, stored passwords, and account ownership without assuming that local state remains stable. That makes recovery logic, fallback design, and user verification part of the access model, not just the user interface.
Key questions
A: Treat enrollment changes as a credential invalidation event, not a cosmetic error. Catch the authentication failure, clear the stored local credential state, and require password sign-in before re-enabling biometric access. That preserves a clean recovery path and prevents the app from repeatedly advertising a biometric option that can no longer succeed.
Q: Why should biometric login always have a password fallback?
A: Biometric login depends on device hardware, enrollment, and local storage state, all of which can fail or change. A password fallback gives users a recovery path after fingerprint resets, Face ID changes, permission denial, or device replacement. Without it, the authentication flow can strand legitimate users when the biometric layer stops matching the stored secret.
Q: What is the difference between passkeys and biometric sign-in for account security?
A: Biometric sign-in usually proves the user locally, but the underlying password or secret can still remain in the system. Passkeys go further by replacing the password itself with cryptographic credentials tied to the device and protected by biometrics or hardware security. That distinction matters because passkeys can reduce dependence on memorised secrets rather than simply simplifying entry.
Q: How do I manage stored biometric credentials on a shared device?
A: Use an authenticated settings screen to verify whether the current account owns the stored credential before allowing any management action. If the stored credential belongs to another user, require explicit removal and re-enrolment. On shared devices, the existence of a local credential does not prove that the current user is entitled to manage it.
Technical breakdown
Sign-in gating: when biometric buttons should appear
A biometric sign-in button should be shown only when the app has stored credentials and the device exposes a biometric type. In this pattern, `hasCredentials` tells the app whether any local credential exists, while `biometricType` confirms that the device can present a usable biometric modality. The important distinction is that sign-in screens cannot use ownership checks that depend on a current session, because no user is signed in yet. That is why the button logic must be based on credential presence and device capability, not on authenticated-user ownership state. See the Workforce Identity Security Guide.
Practical implication: Gate biometric sign-in on credential existence and device support, not on ownership checks that require an authenticated session.
Enrollment changes: why authenticate() must fail closed
When biometric enrollment changes, stored secret material can become inaccessible even though the app still knows a credential record exists. That is why `authenticate()` must throw and be handled with `try/catch`, rather than returning a null-like status that a caller might ignore. The error reflects a real state change in the device-bound protection layer, not a transient UI issue. If the app does not clear both stored keys, it will keep advertising biometric login even though the protected password can no longer be recovered. This is a credential state mismatch, not a rendering bug. Read Guide to NHI Rotation Challenges.
Practical implication: Treat biometric enrollment changes as credential invalidation events and clear local state before re-presenting the password flow.
Settings-time ownership: separating hasCredentials from userOwnsCredentials
The authenticated settings screen is where `userOwnsCredentials` becomes meaningful, because the current user is known and the app can verify whether the stored credential belongs to that account. That distinction matters on shared devices, where a credential record may exist but belong to a different signed-in user. The guide’s logic separates visibility from management: `hasCredentials` answers whether something is stored, while `userOwnsCredentials` answers whether the current account should be allowed to manage it. This prevents one user from silently operating on another user’s local credential state.
Practical implication: Use ownership checks only in authenticated contexts, and require explicit removal when a stored biometric credential belongs to another account.
NHI Mgmt Group analysis
Biometric login is a credential-state problem, not a UI toggle. The article shows that the real control boundary is whether locally stored credentials remain valid, visible, and owned by the current account. Once teams treat biometric login as a stateful identity control, they stop designing around the button and start designing around lifecycle transitions, recovery, and ownership. The practitioner takeaway is to govern stored credentials as part of the sign-in state machine, not as a cosmetic option.
Shared-device ambiguity is the governance risk this pattern exposes. A device can legitimately contain credential material that belongs to a different account, and that state is not safely resolved by the presence of `hasCredentials` alone. This is exactly where human IAM assumptions about a single user per device break down in mobile contexts. The implication is that management actions must be account-aware, because local storage alone cannot establish rightful control.
Passkeys and biometric login should be treated as different assurance models. The article’s architecture separates a convenience layer that protects a stored password from a passwordless model based on asymmetric cryptography. That distinction matters because it changes what gets stored, what can be reused, and how recovery behaves after device or enrollment changes. Practitioners should stop grouping them under one vague passwordless label and govern each sign-in pattern on its own merits.
Recovery logic is part of the authentication control, not an afterthought. The guide makes clear that invalidated biometrics must trigger cleanup, fallback, and re-enablement steps. That means the authentication surface includes failure handling, not just successful sign-in. For identity programmes, the lesson is that a control is incomplete if it does not define what happens when the protected credential can no longer be used.
Read next: Passwordless and Passkeys Guide
What this signals
Credential ownership has to be checked at the right lifecycle stage. On an unauthenticated sign-in screen, the app can only ask whether a credential exists and whether the device can present a biometric factor. On an authenticated settings screen, it can finally ask whether the current account actually owns that credential. That separation is the programme lesson: identity controls must change with session state, or they will misclassify local storage as authority.
Biometric enrollment drift is a recurring identity-state failure mode. When Face ID or fingerprint enrollment changes, the protected password may become unusable while the local record still exists. Teams should expect that kind of drift and build explicit cleanup and re-enrolment flows around it. The same design pressure appears anywhere local credential state outlives the conditions that made it valid.
For practitioners
- Separate sign-in gating from credential ownership Use `hasCredentials && biometricType` to decide whether to show biometric sign-in on unauthenticated screens, and reserve `userOwnsCredentials` for authenticated settings views. See the Workforce Identity Security Guide.
- Handle biometric invalidation with explicit cleanup Wrap biometric authentication in `try/catch`, call `clearCredentials()` when enrollment changes invalidate the stored password, and re-present the password form.
- Keep password fallback permanently available Render the password form even when biometric sign-in is enabled so users can recover from hardware loss, enrollment reset, or platform permission issues.
- Treat passkeys as a separate sign-in model Implement passkeys as an asymmetric-cryptography flow rather than a stored-password wrapper, and make sure the app’s recovery logic reflects that difference.
- Design for shared-device credential drift When a stored biometric credential belongs to another account, require explicit removal and re-enrolment instead of allowing the settings screen to toggle it in place.
Key takeaways
- Biometric login in mobile apps should be governed as a credential lifecycle control, not just an extra sign-in button.
- Enrollment changes can leave stored local credentials present but unusable, so cleanup and fallback handling are mandatory.
- Passkeys and biometric login solve different authentication problems, and teams should design recovery and ownership checks accordingly.
Related NHI Mgmt Group resources: Workforce Identity Security Guide · Passwordless and Passkeys Guide · Guide to NHI Rotation Challenges
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, OWASP ASVS and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63B — Authentication | Biometric login, fallback sign-in, and passkeys all sit in the authentication layer. |
| Recommendation — Apply SP 800-63B to separate authentication strength from recovery and fallback handling. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centres on storing, invalidating, and re-enrolling local credentials. |
| Recommendation — Use IA-5 to govern credential storage, invalidation, and re-enrollment for local sign-in secrets. | ||
| OWASP ASVS | V6 — Authentication | The implementation patterns affect sign-in assurance and recovery behaviour. |
| Recommendation — Review V6 requirements when adding biometric or passkey-based sign-in flows. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article addresses mobile identity handling and credential ownership in application access. |
| Recommendation — Align IAM controls to account ownership, credential persistence, and sign-in recovery paths. | ||
Key terms
- Biometric Authentication: Biometric authentication verifies a person using physical traits such as a fingerprint, face, iris, or voice pattern. It can reduce password use, but it is not a revocable secret in the same way a password is. Security teams must therefore pair biometrics with fallback controls, attestation, and recovery safeguards.
- Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
- Credential Ownership Check: A credential ownership check verifies that the authenticated caller is allowed to act on a specific credential before the system reads or modifies it. This control is essential in multi-user platforms because identifier knowledge alone should never be enough to authorize sensitive actions such as revoke, authorize, or rebind.
- Enrollment Drift: Enrollment drift occurs when a device loses the identity, connectivity, or management state needed to stay under policy control. In patching programmes, drift can silently remove endpoints from update oversight while leaving them active in production.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org