What This Template Is For
Biometric authentication (Face ID, Touch ID, fingerprint sensors, Windows Hello) lets users prove their identity using physical characteristics instead of passwords. For products that require frequent re-authentication or handle sensitive data, biometrics reduce friction while maintaining strong security. This template helps you plan biometric auth from the product perspective: which biometric methods to support, how to handle devices without biometric hardware, what fallback paths to offer, and how to address privacy concerns.
Biometric auth is not a standalone solution. It is an accelerator layered on top of an existing auth system. Users still need a primary credential (password, SSO, passkey) to set up biometric access and as a fallback when biometrics fail. The mistake most teams make is treating biometric support as a simple feature toggle. In reality, it requires careful thought about device compatibility, enrollment flows, failure modes, and regulatory compliance.
This template pairs well with the auth flow template for designing the full authentication journey and the access control template for post-authentication permissions. If you are building a mobile-first product, the Technical PM Handbook covers native platform considerations in depth. For understanding the broader security requirements, see the technical spec template.
How to Use This Template
- Complete the Biometric Strategy section to define which methods you support and why.
- Fill in the Device Support Matrix to understand your coverage gaps.
- Design the Enrollment Flow (how users enable biometrics) and the Authentication Flow (how they use biometrics day-to-day).
- Map every failure scenario in the Fallback and Recovery section.
- Complete the Privacy and Compliance checklist before handing off to engineering.
The Template
Part 1: Biometric Strategy
| Field | Details |
|---|---|
| Product Name | [Your product] |
| Platform | [iOS, Android, Web, Desktop, Cross-platform] |
| Primary Use Case | [App unlock, Transaction confirmation, Step-up auth, Device enrollment] |
| Biometric Methods | [Face ID, Touch ID, Android Fingerprint, Windows Hello] |
| Security Classification | [Convenience (app unlock) / Security (transaction signing)] |
| Regulatory Requirements | [PSD2, HIPAA, PCI DSS, None] |
| Target Enrollment Rate | [% of eligible users who enable biometrics] |
Part 2: Device Support Matrix
| Platform | Biometric Method | API / SDK | Min OS Version | Market Share (Your Users) | Supported? |
|---|---|---|---|---|---|
| iOS | Face ID | LocalAuthentication / LAContext | iOS 14+ | [%] | Yes / No |
| iOS | Touch ID | LocalAuthentication / LAContext | iOS 14+ | [%] | Yes / No |
| Android | Fingerprint | BiometricPrompt API | Android 9+ | [%] | Yes / No |
| Android | Face Unlock | BiometricPrompt API (Class 3) | Android 10+ | [%] | Yes / No |
| Web | WebAuthn / FIDO2 | navigator.credentials | Chrome 67+, Safari 14+ | [%] | Yes / No |
| Windows | Windows Hello | WebAuthn or WinRT | Windows 10 1903+ | [%] | Yes / No |
| macOS | Touch ID (M-series) | WebAuthn | macOS 12+ | [%] | Yes / No |
Coverage Summary.
| Metric | Value |
|---|---|
| Users on devices with biometric hardware | [%] |
| Users on supported OS versions | [%] |
| Expected enrollment-eligible users | [%] |
Part 3: Enrollment Flow
Define how users enable biometric authentication for the first time.
| Step | Screen / Action | User Input | System Action | Success Path | Failure Path |
|---|---|---|---|---|---|
| 1 | [Prompt after login / Settings page] | [Tap "Enable Face ID" / "Enable Fingerprint"] | [Check device biometric capability] | Step 2 | [Show "Device not supported" message] |
| 2 | [Confirm identity] | [Enter password or existing MFA] | [Verify current credentials] | Step 3 | [Show credential error] |
| 3 | [OS biometric prompt] | [Scan face / fingerprint] | [OS validates biometric, app stores credential reference] | Step 4 | [Show retry or fallback] |
| 4 | [Success confirmation] | [Dismiss] | [Update user settings, log enrollment event] | [Return to app] | - |
Enrollment Triggers. When should the app prompt users to enable biometrics?
- ☐ After first successful login on a new device
- ☐ After third login on the same device (user has shown intent to return)
- ☐ Never auto-prompt; only available in settings
- ☐ During onboarding flow (for security-critical apps)
Part 4: Authentication Flow
Define how biometric auth works during normal use.
| Step | Screen / Action | User Input | System Action | Success Path | Failure Path |
|---|---|---|---|---|---|
| 1 | [App launch / Session expired] | [Automatic biometric prompt] | [Request OS biometric via API] | Step 2 | [Show fallback options] |
| 2 | [OS biometric dialog] | [Scan face / fingerprint] | [OS validates, returns success to app] | Step 3 | [Retry up to N times, then fallback] |
| 3 | [App unlocked] | - | [Restore session, log auth event] | [Main screen] | - |
Step-up Authentication. For high-risk actions (transferring money, changing security settings, exporting data), require biometric re-verification even within an active session.
| Action | Step-up Required? | Biometric Allowed? | Alternative |
|---|---|---|---|
| [View dashboard] | No | - | - |
| [Change password] | Yes | Yes | Password |
| [Transfer funds] | Yes | Yes | Password + MFA |
| [Export data] | Yes | Yes | Password |
| [Delete account] | Yes | No (password required) | - |
| [Invite team members] | No | - | - |
Part 5: Fallback and Recovery
Every biometric method can fail. Design recovery paths for every failure scenario.
| Failure Scenario | Cause | User Experience | Recovery Path |
|---|---|---|---|
| Biometric not recognized | Wet fingers, changed appearance, mask | OS retry prompt (up to 3 attempts) | Show "Use password instead" after max retries |
| Biometric hardware unavailable | Device in pocket mode, sensor damaged | No biometric prompt appears | Auto-show password login |
| OS biometric locked out | Too many OS-level failures | OS blocks biometric for 30s-5min | Show password login with explanation |
| Biometric enrollment deleted | User removed Face ID from device settings | App detects no enrollment on next launch | Prompt to re-enroll or use password |
| New device | User switched phones | No biometric enrolled for this device | Standard login, then offer enrollment |
| Shared device | Multiple users on one tablet | Wrong user biometric matches | Use password login; biometrics not appropriate for shared devices |
Part 6: Privacy and Compliance
| Requirement | Status | Notes |
|---|---|---|
| Biometric data stays on device | Yes / No | Apple and Android biometric APIs never expose raw biometric data to apps. Verify your implementation uses OS-level APIs, not custom biometric capture |
| No biometric data transmitted to server | Yes / No | The app should receive a success/failure signal from the OS, not biometric data |
| Privacy policy updated | Yes / No | Disclose that biometric authentication is used and that biometric data is processed locally on-device |
| Consent obtained before enrollment | Yes / No | User must explicitly opt in. Do not auto-enroll |
| BIPA compliance (if US users) | Yes / No / N/A | Illinois Biometric Information Privacy Act requires written consent and data retention policies |
| GDPR compliance (if EU users) | Yes / No / N/A | Biometric data is "special category" under GDPR Article 9. Explicit consent required |
| Audit logging | Yes / No | Log enrollment, authentication, and unenrollment events without logging biometric data |
| Unenrollment path | Yes / No | Users can disable biometric auth in settings without losing account access |
Part 7: Accessibility Considerations
| Consideration | Approach |
|---|---|
| Users who cannot use fingerprint (injury, disability) | Face recognition as alternative, password fallback always available |
| Users who cannot use face recognition | Fingerprint or password fallback |
| Screen reader compatibility | All biometric prompts must be accessible. OS-level biometric dialogs are accessible by default |
| Visual feedback for biometric state | Haptic feedback on success/failure, not just visual indicators |
| Cognitive accessibility | Clear language: "Sign in with your face" not "Authenticate via LAContext" |
Filled Example: Mobile Banking App
Biometric Strategy
| Field | Details |
|---|---|
| Product Name | SecureBank Mobile |
| Platform | iOS and Android |
| Primary Use Case | App unlock (convenience) and transaction confirmation (security) |
| Biometric Methods | Face ID, Touch ID, Android Fingerprint, Android Face Unlock (Class 3 only) |
| Security Classification | Security (PSD2-compliant Strong Customer Authentication) |
| Regulatory Requirements | PSD2 (EU), FFIEC (US), SOC 2 |
| Target Enrollment Rate | 75% of active mobile users within 6 months |
Device Support Matrix (Filled)
| Platform | Biometric Method | Min OS | User Base Share | Supported |
|---|---|---|---|---|
| iOS | Face ID | iOS 15+ | 38% | Yes |
| iOS | Touch ID | iOS 15+ | 14% | Yes |
| Android | Fingerprint (Class 3) | Android 10+ | 32% | Yes |
| Android | Face Unlock (Class 3) | Android 11+ | 8% | Yes (Class 3 only) |
| Android | Face Unlock (Class 2) | Android 10+ | 5% | No (insufficient security for PSD2) |
| Other | No biometric | - | 3% | N/A (password + MFA) |
Coverage. 92% of users have supported biometric hardware. 3% have biometric hardware that does not meet PSD2 security requirements (Android Class 2 face unlock). 5% have no biometric hardware.
Enrollment Flow (Filled)
| Step | Screen | Action | Details |
|---|---|---|---|
| 1 | Post-login prompt (shown after 3rd login on device) | "Enable Face ID for faster sign-in?" with "Enable" and "Not Now" buttons | Only shown on devices with supported biometric. "Not Now" suppresses prompt for 30 days |
| 2 | PIN verification | Enter 6-digit banking PIN | Confirms user identity before enrollment |
| 3 | OS Face ID prompt | Scan face via iOS LocalAuthentication | App stores a reference to the Keychain-protected credential. No biometric data leaves the device |
| 4 | Success screen | "Face ID enabled. You can disable this anytime in Settings > Security" | Confirmation email sent. Audit log entry created |
Transaction Confirmation (Step-Up)
| Transaction Type | Amount Threshold | Auth Required | Biometric Allowed |
|---|---|---|---|
| Balance check | - | App session only | - |
| Internal transfer | Under $500 | Biometric | Yes |
| Internal transfer | $500 and above | Biometric + PIN | Yes (replaces one factor) |
| External transfer | Any amount | Biometric + PIN | Yes (replaces one factor) |
| Payee management | - | PIN only | No |
| Security settings | - | PIN + SMS OTP | No |
Common Mistakes to Avoid
- Relying on biometrics as the sole auth method. Biometrics should always be layered on top of a primary credential. If the user resets their phone, they need a way to recover their account without biometric access. The primary credential (password, PIN) is the fallback.
- Using Android Class 2 face unlock for security-critical actions. Android Class 2 face unlock can be spoofed with a photo. Only Android Class 3 biometrics (which require hardware-backed anti-spoofing) should be used for transaction confirmation or security-sensitive flows. Check
BiometricManager.canAuthenticate(BIOMETRIC_STRONG)on Android. - Auto-enrolling users without consent. Even though biometric data stays on-device, regulatory frameworks (BIPA, GDPR) require explicit user consent before using biometric authentication. Always present an opt-in prompt, not an opt-out toggle.
- Forgetting the shared device scenario. On tablets shared by family members or kiosk devices, biometric auth can authenticate the wrong person. Detect shared device scenarios and default to password login.
- Not logging biometric events for audit. Log enrollment, successful auth, failed auth, and unenrollment events. Do not log biometric data itself. These audit logs are required for SOC 2 and PSD2 compliance.
Key Takeaways
- Biometric auth is an accelerator layered on an existing auth system, not a replacement
- Use the Device Support Matrix to understand what percentage of your users can use biometrics
- Design fallback paths for every failure scenario before building the happy path
- Only use Class 3 (hardware-backed) biometrics for security-critical actions
- Biometric data never leaves the device when using OS-level APIs. Document this in your privacy policy
- Track enrollment rate, auth success rate, and fallback rate to measure adoption
About This Template
Created by: Tim Adair
Last Updated: 3/5/2026
Version: 1.0.0
License: Free for personal and commercial use