Teams often ask whether a fingerprint or face scan is "more secure" than a security key or phone, but the two are not substitutes: a biometric proves who is holding a device, while a possession factor proves which device is present. The real decisions are where the biometric is matched, which physical authenticator it unlocks, what happens when either one is spoofed, lost or shared, and which privacy duties follow from collecting biometric data at all. This guide compares biometric factors and possession factors on spoofing and injection, local versus server matching, privacy law, recovery and shared devices, and treats passkeys as the combined case where a biometric unlocks a key held in hardware. It is written for identity architects, IAM leads and privacy teams choosing authenticators for workforce or customer journeys.
Key takeaways
- Biometrics are not secrets. NIST SP 800-63B-4 says biometric characteristics do not constitute secrets, because they can be captured from photographs and touched objects, so a biometric can never stand alone as an authenticator.
- Possession is the anchor, biometrics are the activation. NIST allows biometrics only as part of multi-factor authentication with a physical authenticator; the strongest pattern is a biometric that unlocks a key which never leaves secure hardware.
- Where matching happens decides the risk. Local matching on the device keeps templates out of your systems and is preferred by NIST; server-side matching creates a template store, an injection attack surface and heavier privacy obligations.
- Recovery and fallback are the weak point of both. A biometric cannot be reissued after a leak and a token can be lost; whichever you choose, the help desk reset path must be as strong as the factor it replaces.
- Privacy law applies to biometrics, not to tokens. Biometric data used to uniquely identify a person is special category data under GDPR Article 9, the ICO requires a suitable alternative where consent is the condition, and Illinois BIPA adds written release and destruction rules.
The short answer
A possession factor such as a FIDO security key, a smart card or a device-bound passkey gives you a cryptographic, phishing-resistant proof that a specific authenticator is present,. A biometric adds a cheap, fast check that the right person is using that authenticator, but it is public by nature, probabilistic rather than exact, and permanent if compromised. The defensible design for most organisations is a possession factor as the authenticator, unlocked by either a local biometric or a PIN, with a non-biometric route always available. Server-side biometric matching is justified mainly for remote customer journeys where no trusted device exists, such as account recovery or high-value step-up, and it then needs presentation attack and injection attack detection.
Side-by-side comparison
| Dimension | Biometric factor (inherence) | Possession factor (something you have) |
|---|---|---|
| What it proves | A live person whose trait matches an enrolled template, within an error rate | Control of a specific device or key, by a cryptographic exchange |
| Secrecy | None: faces and fingerprints are exposed in daily life | Private key held in hardware; not observable by others |
| Result type | Probabilistic: tuned by threshold, with false matches and false non-matches | Deterministic: the signature verifies or it does not |
| Standalone use under SP 800-63B-4 | Not allowed; only with a physical authenticator | Single-factor at AAL1; with an activation factor, multi-factor at AAL2 or AAL3 |
| Phishing resistance | Depends entirely on the protocol behind it; a biometric unlocking an OTP app is still phishable | FIDO and PKI-based authenticators are phishing-resistant; OTP, push and SMS tokens are not |
| Main attacks | Presentation attacks (masks, prints, replayed video), injection of synthetic or deepfake streams, template theft | Theft, loss, cloning of exportable keys, SIM swap for SMS, help desk reset abuse |
| Compromise response | Cannot be reissued; revoke the template and the binding, re-enrol another modality | Revoke and reissue the credential or device |
| Privacy regime | Special category data (GDPR Art. 9), BIPA and similar state laws, DPIA expected | Ordinary personal data about device assignment |
| Shared devices | Several people enrol on one device, weakening assurance about who acted | A personal roaming key moves with the user |
Threat model for biometric factors
A biometric system is attacked at the sensor, on the path from the sensor to the matcher, and at the template store. The threat model changes sharply with where matching takes place.
- Presentation attacks: an artefact is shown to a genuine sensor: a printed photo, a screen replay, a silicone fingerprint or a 3D mask. NIST SP 800-63B-4 requires presentation attack detection (PAD) for facial recognition and recommends it for fingerprint and iris, with an impostor attack presentation accept rate below 0.07 in deployment testing. See the Biometric Liveness and Presentation Attack Detection Guide.
- Injection attacks: the sensor is bypassed and a synthetic or recorded stream is fed in through a virtual camera, emulator or hooked app. This is the dominant risk for remote face matching on devices you do not control. NIST expects the verifier to establish sensor and endpoint integrity, for example by sensor authentication or signed attestation metadata, and where comparison is central, to authenticate the sensor before capture and carry biometric data over an authenticated protected channel. See Biometric Injection Attacks.
- Zero-effort impostors: a stranger simply tries. This is what the false match rate measures; NIST requires one in 10,000 or better for all demographic groups at a fixed threshold, tested under ISO/IEC 19795-1, and recommends a false non-match rate below 5%.
- Template theft: a central store of templates or enrolment images is a high-value target that cannot be fixed by a reset. See Biometric Template Protection.
- Voice: NIST SP 800-63B-4 states that voice-based biometric comparison shall not be used, which rules out voiceprint authentication for NIST-aligned designs. See Caller Authentication in Contact Centres.
NIST also limits guessing: no more than five consecutive failed biometric attempts without PAD, or ten with PAD, then a delay of at least 30 seconds before each further attempt, and an overall limit of 50 consecutive failures without PAD or 100 with PAD.
Threat model for possession factors
Possession factors fail through loss, cloning, relay and the processes around them; the class of possession factor matters more than possession itself.
- Phishing and relay: OTP tokens and authenticator apps prove possession but the code can be typed into a fake site. CISA marks OTP as vulnerable to phishing, push without number matching as vulnerable to push bombing, and SMS or voice as vulnerable to phishing, SS7 and SIM swap, and calls FIDO/WebAuthn the only widely available phishing-resistant authentication. See the Phishing-Resistant MFA Guide and the MFA Fatigue and Bypass Guide.
- Theft and loss: a stolen key with no activation factor is a single factor in the thief's hand. NIST treats lost, stolen, damaged or possibly duplicated authenticators as compromised and requires prompt suspension, invalidation or destruction (SP 800-63B-4 section 4.3).
- Cloning and export: synced passkeys are copied through a provider's sync fabric, which is why SP 800-63B-4 allows syncable authenticators at AAL2 but not AAL3. The detail is in Passkeys vs Hardware Security Keys.
- Session theft after sign-in: no factor protects a stolen session cookie (ATT&CK T1539 Steal Web Session Cookie); session binding and short sessions are separate controls.
- Recovery abuse: the attacker never touches the token and instead convinces the help desk to register a new one, as in the Co-op cyber attack, where a social-engineered password reset gave the attackers their foothold.
Local versus server matching
The single most important architectural choice for a biometric is where the comparison happens. It decides the attack surface, the privacy burden and whether the biometric is really a separate factor at all.
| Property | Local matching (on device or token) | Server matching (central comparison) |
|---|---|---|
| What the relying party receives | A signed assertion that user verification succeeded; FIDO states biometric data stays on the device and is never sent to a remote server | A biometric sample or template to compare |
| Factor structure | Biometric is the activation factor of a multi-factor possession authenticator | Biometric must still be paired with a physical authenticator to meet SP 800-63B-4 |
| Who controls thresholds and PAD | The device or authenticator maker; you rely on certification and attestation | You or your provider; you can tune and test |
| Injection exposure | Low: the matcher sits behind the platform's secure hardware | High on unmanaged devices: needs sensor authentication and injection detection |
| Breach consequence | Per-device; no central store to steal | Central template store; leak cannot be undone |
| Privacy burden | Lighter, though counsel should still confirm whether any biometric data is processed by you | Full special category obligations, DPIA, retention and deletion |
NIST states local verification is preferred over central comparison. With local matching you cannot tune the matcher, so the evidence you rely on shifts to authenticator certification (FIDO publishes Biometric Component Certification for authenticator biometric performance and PAD) and to attestation at registration. See the D3-BAN Biometric Authentication page for the defensive technique view.
Passkeys: the combined case
A passkey is the clearest example of the two factors working together. The FIDO Alliance describes the user approving sign-in with the same biometric, PIN or on-device password that unlocks the device, while the server receives only assurance that the check succeeded. The possession factor is the private key; the biometric is local user verification. Three consequences follow for factor choice:
- The biometric is replaceable by a PIN without changing the protocol. This satisfies the NIST rule that a non-biometric alternative shall always be provided and the ICO expectation of a suitable alternative where consent is relied on.
- Assurance is set by the key, not the biometric. A device-bound passkey can reach AAL3 when the other requirements are met; a synced passkey stops at AAL2 regardless of how good the fingerprint reader is.
- The biometric adds local, not remote, protection. It stops a thief who has the unlocked phone or the key from using the credential, but it does not change what an attacker with a cloned synced key or a hijacked provider account can do.
The WebAuthn user verification flag tells the relying party that some verification happened, not which method. If policy needs biometric specifically, that can only be enforced through managed device configuration or authenticator attestation, not from the assertion alone. See the FIDO2 and WebAuthn Internals Guide and the Passwordless and Passkeys Guide.
Privacy law and consent
Possession factors raise ordinary data protection questions about device assignment. Biometrics bring a separate regime, and the obligations depend heavily on whether you ever process the biometric data.
| Regime | What it says about biometrics | Design consequence |
|---|---|---|
| EU GDPR Art. 4(14) and Art. 9 | Biometric data results from specific technical processing of physical, physiological or behavioural traits that allow or confirm unique identification; processing it to uniquely identify a person is prohibited unless an Art. 9(2) condition applies; Art. 9(4) lets Member States add further conditions | Identify an Art. 6 basis and an Art. 9 condition before any server-side matching; check national add-ons |
| GDPR Recital 91 and DPIA practice | Lists processing of biometric data among cases that call for a data protection impact assessment | Run a DPIA for central matching and for workforce schemes |
| UK ICO biometric recognition guidance | Special category biometric data needs a lawful basis and an Art. 9 condition; explicit consent is often the most suitable; where consent is relied on a suitable alternative must be offered regardless of any power imbalance; consent cannot be inferred from behaviour. The ICO notes the guidance is under review after the Data (Use and Access) Act 2025 | Always offer a PIN or token route; employers must test whether consent is genuinely free |
| Illinois BIPA, 740 ILCS 14/15 | Written notice of purpose and retention and a written release before collection; a public retention schedule; destruction when the purpose is fulfilled or within 3 years of the last interaction, whichever comes first; no selling or profiting; reasonable industry standard of care | Workforce and customer schemes touching Illinois residents need consent capture and a deletion process before launch |
Local matching changes the analysis because templates stay on the person's device, but whether a given design takes you out of scope is a legal question for counsel, not an engineering assumption. Map jurisdictions with the Biometric Privacy Laws Map, and for employee schemes see Biometric Data in the Workplace and the Illinois BIPA and Biometric Privacy Guide.
Recovery and lifecycle
A lost token is common and cheap to fix; a compromised biometric is rare and cannot be fixed. Recovery design must cover both.
- Bind more than one authenticator: SP 800-63B-4 section 4.1 requires verifiers to permit multiple authenticators per account and encourages subscribers to keep at least two.
- Use recognised recovery methods: section 4.2 lists saved recovery codes, issued recovery codes, recovery contacts and repeated identity proofing, and requires the subscriber to be notified of every recovery. See the MFA backup codes and recovery codes guide.
- Do not use the biometric as the recovery secret: using a selfie match as the only reset path turns a public trait into the key to the account. If face matching supports recovery, combine it with document verification, injection detection and a possession check, and treat it as identity proofing rather than authentication.
- Template compromise: revoke the binding, re-enrol the person on a different modality or on a PIN, and where the provider offers cancellable templates, regenerate them.
- Help desk: require verification at least as strong as the factor being replaced. See the Help Desk Identity Verification Policy Template.
Shared devices, frontline and accessibility
Shared workstations, ward computers, retail tills and warehouse handhelds break the usual assumption that one device means one person.
- Biometrics on a shared device: enrolling many people on one device's local matcher means the key it unlocks is shared, so the assertion no longer identifies an individual. Avoid this for any system needing individual accountability.
- Personal roaming possession factors: a security key or smart card that the person carries, optionally with a match-on-key fingerprint, keeps the binding personal on shared hardware.
- Server matching at kiosks: a mounted camera with central matching can identify staff quickly, but it is identification against a gallery, carries the full privacy burden and needs PAD, so confine it to physical access or low-risk time recording unless paired with a token.
- Accessibility: some people cannot enrol a fingerprint or face reliably; others cannot handle a small key. Offer at least two supported combinations.
See the Passwordless for Frontline and Shared Devices Guide and the Kiosk and Shared Device Security Guide.
When to choose each
| Situation | Recommended combination | Why |
|---|---|---|
| Knowledge workers on managed laptops and phones | Device-bound or synced passkey, local biometric or PIN | Phishing-resistant, no template held by you, low support cost |
| Administrators and AAL3 roles | Hardware security key or smart card with PIN or match-on-key biometric | Non-exportable key; possession is the anchor |
| Shared workstations and frontline staff | Personal roaming key or badge, PIN activation | Keeps the credential personal on shared hardware |
| Customers on their own phones | Synced passkey with local biometric | Familiar unlock, no central biometric store |
| Remote customer recovery with no device left | Server-side face match with document check, PAD and injection detection, then a new possession factor | Only case where central biometrics earn their privacy cost |
| Users who decline or cannot use biometrics | Same passkey or key with a PIN | Meets NIST and ICO alternative requirements without a weaker protocol |
Small versus large organisations: small organisations get most of the value from platform passkeys with local biometrics and two authenticators per user, and should avoid server-side biometrics. Large or regulated organisations run all three patterns and need attestation policies, a DPIA register and a staffed recovery process.
Worked scenario
A healthcare group with 9,000 staff wants to replace SMS codes. Office staff use managed laptops; ward staff share workstations and wear gloves; IT administrators manage the identity provider. The privacy team flags that some staff are Illinois residents.
- Office staff: device-bound platform passkeys with fingerprint or face unlock, PIN as the alternative; no biometric data reaches the organisation.
- Ward staff: personal NFC security keys with a PIN, because gloves defeat fingerprint sensors and shared workstations rule out per-device biometrics.
- Administrators: two hardware keys each, attestation enforced at registration, no synced passkeys allowed.
- Proposed palm scanner at the staff entrance: treated as a separate project with a DPIA, written BIPA notice and release, a published retention schedule and a badge alternative.
- Recovery: spare key or recovery code first; otherwise in-person re-enrolment with a manager and ID check, with notification to the user.
Detection and measurement
Log at the identity provider: authenticator type and AAGUID at registration, user verification flag, new authenticator bindings (notify through a separate channel, as section 4.1 requires), recovery events, failed biometric attempts and lockouts, and for server matching, PAD and injection detection decisions. Watch for ATT&CK T1621 Multi-Factor Authentication Request Generation and T1111 Multi-Factor Authentication Interception against any remaining non-phishing-resistant factors, and T1556 Modify Authentication Process for tampering with authenticator policy. See How to Detect MFA Method Registration Abuse.
- Phishing-resistant coverage: share of sign-ins using FIDO or PKI possession factors, by population. See MFA Coverage Measurement.
- Two-authenticator rate: share of users with at least two bound authenticators.
- Recovery rate and method: recoveries per 1,000 users per month and the share needing help desk intervention.
- Biometric fallback rate: share of verifications completed by PIN instead of biometric, by site; a spike points at hardware or environment problems.
- PAD and injection rejects: for server matching, rejected attempts per 10,000 and the false reject complaints they cause.
Common failure patterns
- Biometric on a phishable protocol: a fingerprint unlocks an OTP or push app, giving users a sense of strength while codes remain phishable.
- Face match as the only recovery path: injection and deepfake tools turn a public trait into an account takeover route.
- No non-biometric route: breaches NIST and ICO expectations and locks out staff who cannot enrol.
- One authenticator per user: every lost phone becomes a help desk reset, and the reset desk becomes the attack surface.
- Shared device enrolment: several staff enrol fingers on one tablet, so audit logs cannot say who acted.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01, PR.AA-03 | Credential management and authentication of users |
| NIST SP 800-53 Rev 5 | IA-2, IA-2(1), IA-5, IA-5(12), IA-12 | Multi-factor authentication, authenticator management, biometric authentication performance, identity proofing for recovery |
| NIST SP 800-63B-4 | Sections 3.2.3, 4.1, 4.2, 4.3, 4.5 | Use of biometrics, binding, recovery, loss and invalidation |
| MITRE D3FEND | D3-BAN, D3-MFA | Biometric Authentication, Multi-factor Authentication |
| MITRE ATT&CK | T1111, T1621, T1556, T1539 | MFA interception and request flooding, authentication process tampering, session theft |
| GDPR | Art. 4(14), Art. 9, Recital 91 | Biometric data definition, special category condition, DPIA |
Practitioner checklist
- Make a possession factor the authenticator in every design; use biometrics only as activation or as one factor alongside it.
- Prefer local matching; document every place your organisation receives biometric samples or templates.
- Offer a PIN or token route for every biometric option and record it in the DPIA.
- Require PAD for any face matching and injection detection for any remote capture; ban voiceprints for authentication.
- Bind at least two authenticators per user and use NIST-recognised recovery methods with notification.
- Give shared-device and frontline users personal roaming keys or badges, not shared biometric enrolment.
- Complete GDPR Art. 9, ICO and BIPA checks before collecting any biometric data, with retention and deletion evidence.
- Track phishing-resistant coverage, two-authenticator rate, recovery rate and biometric fallback rate monthly.
Standards and references
- NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
- FIDO Alliance: Passkeys
- FIDO Alliance: Biometric Component Certification
- CISA: Implementing Phishing-Resistant MFA
- EUR-Lex: Regulation (EU) 2016/679, General Data Protection Regulation
- ICO: Biometric data guidance, how do we process biometric data lawfully
- Illinois General Assembly: 740 ILCS 14/15 Biometric Information Privacy Act, retention, collection, disclosure and destruction
Related NHI Mgmt Group resources: Authentication Guide · Biometrics Guide · Passkeys vs Hardware Security Keys · Biometric Authentication Platforms Buyer's Guide