Biometric Authentication: A Practitioner's Guide to Fingerprint, Face, and Beyond

Key takeaways

• Modern biometric authentication is device-local: the biometric template never leaves the user's secure enclave. The relying party sees a signed assertion, not a fingerprint.
• The dominant 2026 modalities are fingerprint (Touch ID, Android sensors) and face (Face ID, Windows Hello face). Iris, voice, and behavioral biometrics are niche.
• Liveness detection is the line between secure deployment and photo-attack vulnerability. Depth-sensing (Face ID, Class 3 Android) defeats 2D photo attacks.
• Biometric authentication is one factor — 'something you are'. Most useful combined with another factor (passkey + biometric) rather than as a standalone replacement.
• Server-side biometric verification (uploading the fingerprint or face image) is the legacy pattern. It lives in KYC workflows; wrong default for ongoing authentication.

What biometric authentication actually is

The classical phrasing is that biometrics provide the "something you are" factor in multi-factor authentication, alongside "something you know" (password) and "something you have" (security key, phone). In modern implementations the line is fuzzier — a passkey on a device with biometric unlock is functionally a single multi-factor cryptographic authenticator, not biometric-plus-something-else.

The architecture that matters: biometric verification happens locally on the device, the secure enclave holds the biometric template, and the assertion sent to the relying party is a cryptographic signature, not the biometric data itself.

The modalities

The 2026 production landscape:

• Fingerprint: Touch ID (Apple), Android fingerprint sensors (Pixel, Samsung, OnePlus), Windows Hello fingerprint readers, hardware security keys with fingerprint (YubiKey Bio). Capacitive and ultrasonic sensors are the standard; older optical sensors are weaker. False acceptance rate (FAR) for Touch ID is published at 1 in 50,000.
• Face: Face ID (Apple), Pixel face unlock, Windows Hello face. The strong implementations use depth-sensing (Face ID's TrueDepth, Pixel's IR+dot-projector) to distinguish real faces from photos; weaker implementations use 2D cameras only and are not high-assurance. FAR for Face ID is published at 1 in 1,000,000.
• Iris: rare in 2026. Some Samsung devices and enterprise contexts (high-security buildings, government). Replaced by face for most consumer use cases.
• Voice: limited to call-center authentication and a few consumer products (Amazon Voice ID). Vulnerable to deepfake voice synthesis, which has become commodity-level in 2025-26 and significantly weakens voice as a standalone factor.
• Behavioral: typing cadence, mouse movement, swipe patterns. Used for continuous authentication and fraud detection, not primary login. Increasingly part of adaptive authentication scoring.

Picking a modality for a consumer app: default to platform biometrics (whatever the user's device offers) via WebAuthn, since these are the highest-quality implementations and zero work for the relying party. Building custom biometric collection is rarely justified; the platform handles it better and the privacy and security properties are stronger.

Device-local templates: the privacy and security architecture

The single most important architectural property of modern biometric authentication: the biometric template never leaves the device.

How this works:

1. Enrollment: the user enrolls their fingerprint or face on the device. The OS generates a template (a mathematical representation, not an image) and stores it in the secure enclave (Apple Secure Enclave, Android StrongBox, Windows TPM, Linux TPM). The template cannot be read by any application, including apps with biometric API access.
2. Credential generation: a relying party (a website using WebAuthn, for instance) asks the device to create a new credential. The device generates a key pair, locks the private key with the biometric requirement, and returns the public key to the relying party.
3. Authentication: the relying party challenges the device. The device prompts the user for biometric verification; the secure enclave verifies the biometric against the local template; on success, the secure enclave signs the challenge with the device-held private key. The signature is what the relying party receives.

The properties this produces:

• Relying-party compromise cannot leak biometrics. The relying party never had them.
• Cross-site reuse impossible. Each relying party gets a different credential; the biometric unlocks all of them on the user's device but they are cryptographically independent.
• Phishing-resistant. The credential is bound to the relying party domain at registration; a phishing site at a different domain cannot trigger the credential.
• No central biometric database. This is the architectural answer to the privacy concern that originally limited biometric adoption.

The architecture is built into WebAuthn (the W3C standard) and FIDO2 (the broader FIDO Alliance framework). Any biometric authentication implementation that diverges from this — sending the fingerprint or face image to the server — is the legacy pattern and is the wrong default in 2026 for ongoing authentication. The legitimate exception is identity verification (KYC): proving who a new user is at enrollment may require sending a face image and a government ID to a verification service. That's a one-time enrollment event, not an ongoing authentication mechanism.

Liveness detection: photos, screens, masks, deepfakes

The classical attack against face recognition: hold a photo of the target in front of the camera. Liveness detection is what defeats this.

The implementations:

• Depth-sensing hardware: Apple Face ID's TrueDepth projector and IR camera, Pixel face unlock's IR + dot projector, Windows Hello face's depth-aware cameras. Hardware-level liveness; impossible to fool with a 2D photo or screen.
• Structured light / 3D modeling: variants used in some enterprise face systems and airport ID verification.
• Active liveness: prompt the user to blink, smile, turn head. Used by some KYC vendors when only a standard camera is available. Vulnerable to recorded video unless combined with other signals.
• Passive liveness: ML-based detection of texture, micro-expressions, screen reflections. Used by KYC vendors at scale; effectiveness depends on the model and adversarial robustness.

The 2026 threat surface: deepfakes have become commodity-grade. The implication is that liveness detection without depth sensing is increasingly insufficient for high-assurance flows. Apple, Google, and Microsoft platform face systems remain effective; lower-end Android face unlock and 2D-only KYC liveness are increasingly the weak points.

For ongoing biometric authentication, the hardware-level liveness in modern platform authenticators is the right answer. For identity verification (KYC), pick a vendor with documented liveness-attack benchmarking (iBeta Level 1 or 2 certification is the industry baseline) and a roadmap for deepfake-resistant detection.

Class 3 biometric and the assurance landscape

Android divides biometric implementations into three classes (Class 1, 2, 3 — formerly Strong, Weak, Convenience). Only Class 3 (Strong) implementations may be used to authenticate keys in the StrongBox keystore or to satisfy WebAuthn user verification. The classification depends on hardware and software properties — false acceptance rates, spoof resistance, secure enclave integration.

The practical implication: a passkey or FIDO2 authenticator on Class 3 Android hardware is high-assurance; on Class 1 or 2 hardware, it is not. iOS and macOS biometrics (Touch ID, Face ID) are uniformly high-assurance.

For relying parties enforcing AAL2 or AAL3 (per NIST SP 800-63B-4), the WebAuthn assertion includes information about whether the authenticator performed strong user verification, and the relying party can require it.

Implementation guidance

1. Use platform biometrics via WebAuthn, not custom biometric collection. The platform implementations are higher-quality and privacy-preserving.
2. Enable passkeys as the primary authentication mechanism. Biometric verification is the unlock; the cryptographic assertion is the credential.
3. Require user verification (userVerification: 'required') for primary authentication. This forces biometric or PIN before the credential is used.
4. Combine with adaptive auth — biometric assertion plus device context plus behavioral signals produces stronger overall security than any single factor.
5. For KYC / identity proofing flows: pick vendors with iBeta-certified liveness detection and explicit deepfake-resistance benchmarks. Treat this as a separate engineering decision from authentication.
6. Plan recovery: when a user changes devices or loses access, the biometric registration goes with the device. Passkey sync via platform clouds handles this for consumer; enterprise needs to register multiple authenticators per user from the start.
7. Audit log every biometric authentication event with the user verification level. SIEM correlation matters more than the verification itself.
8. Don't store biometric data centrally unless the use case is identity proofing. For authentication, the platform handles the template; you handle the cryptographic verification.