Biometrics: types, error rates, liveness, and privacy

Why biometrics deserves its own article

In the factors article we met biometrics as “something you are” — one of the five categories, summarized in a few paragraphs. That summary is enough to design a login screen. It is not enough to make the decisions a practitioner actually gets asked to make: should matching happen on the device or on the server? what FAR do we accept? is our liveness good enough for a payment? are we allowed to store this data in this jurisdiction?

Biometrics is deceptively simple on the surface (“scan your face and you’re in”) and genuinely subtle underneath. It is the only factor category where a design mistake can harm the user permanently, because you cannot reissue a fingerprint. It is also the factor most surrounded by specific law. So it earns a dedicated deep dive.

By the end of this article you will understand the main modalities, exactly what FAR/FRR/EER mean and how the matching threshold trades one against the other, what liveness and anti-spoofing really require, how templates must be stored, which regulations bind you, and where behavioral biometrics fits.

The main modalities

“Biometric” covers any measurable human characteristic stable enough to tell one person from another. In practice a handful of modalities dominate.

Two structural distinctions matter more than the modality itself.

Verification (1:1) vs identification (1:N). Verification answers “is this the person they claim to be?” — one fresh sample against one stored template. That is what unlocking your phone or logging in does. Identification answers “who is this person?” — one sample against a whole database. Identification is far harder: error rates that are negligible at 1:1 explode when you search against millions of templates, because you get many chances to false-match. Most authentication is 1:1; large-scale 1:N is the realm of border control and law enforcement, with different risk and legal profiles.

Physiological vs behavioral. Fingerprint, face, iris, voice, vein measure a physical trait. Behavioral biometrics measures how you act. Physiological traits are captured in a discrete moment; behavioral signals accumulate continuously. We treat behavioral separately at the end because it plays a different role in a system.

How matching actually works

Understanding the pipeline is what lets you reason about failure. Every biometric system, regardless of modality, runs roughly the same stages.

flowchart TB
  accTitle: Biometric enrollment and verification pipeline
  accDescr: Two lanes. Enrollment lane captures a sample, extracts features, and stores a protected template in a secure store. Verification lane captures a new sample, extracts features, runs a liveness or presentation-attack-detection check, then a matcher compares the sample against the stored template to produce a similarity score, which a threshold converts into an accept or reject decision.
  subgraph ENROLL[Enrollment · once]
    C1[Capture sample] --> F1[Extract features]
    F1 --> T1[(Store protected template)]
  end
  subgraph VERIFY[Verification · every login]
    C2[Capture sample] --> L2{Liveness / PAD}
    L2 -->|Spoof suspected| RJ[Reject]
    L2 -->|Live| F2[Extract features]
    F2 --> M2[Matcher vs template]
    M2 --> S2[Similarity score]
    S2 --> TH{Score ≥ threshold?}
    TH -->|Yes| OK[Accept]
    TH -->|No| RJ
  end
  T1 -. compared against .-> M2

Three things are worth underlining:

• The system never stores or compares raw images at match time. It compares feature templates — compact mathematical representations. A good template is not reversible into the original image (more on that under storage).
• Liveness runs before, or alongside, matching. A matcher that would happily accept a high-quality photo is worthless without a liveness gate in front of it.
• The final decision is a threshold comparison, and the threshold is yours to set. That is where error rates come from.

The error metrics: FAR, FRR, EER

This is the part every practitioner must be able to reason about out loud.

The two errors

Because matching is a similarity score against a threshold, exactly two kinds of mistake are possible:

• False Accept (FA): an impostor’s score clears the threshold and they get in. The rate of this happening is the FAR — False Accept Rate. This is the security error. Also called False Match Rate (FMR) in the ISO vocabulary.
• False Reject (FR): a legitimate user’s score falls short and they get bounced. The rate is the FRR — False Reject Rate. This is the usability error. Also called False Non-Match Rate (FNMR).

The trade-off is the whole game

FAR and FRR are not independent knobs — they are two ends of the same knob, the threshold:

• Raise the threshold (demand a closer match): fewer impostors slip through (FAR ↓) but more legitimate users get rejected on a slightly-off day — wet finger, bad lighting (FRR ↑).
• Lower the threshold (accept looser matches): legitimate users breeze through (FRR ↓) but impostors have a better chance (FAR ↑).

You cannot minimize both at once with a fixed system. You choose a point on the curve that fits the risk. Unlocking a music app? Bias toward low FRR — a frustrated user matters more than a rare false accept. Authorizing a bank transfer? Bias toward low FAR — you would rather ask a legitimate user to retry than let an impostor through.

EER and how to read a spec sheet

The EER — Equal Error Rate is the single point where FAR = FRR. It collapses the whole trade-off curve into one number, which makes it convenient for comparing two systems: a sensor with a 0.1% EER is generally better than one with a 2% EER. But beware two traps:

• Almost nobody operates at the EER. Real deployments deliberately sit off it — usually at a low, fixed FAR (e.g. “FAR ≤ 0.001%”) and accept whatever FRR that implies. A vendor quoting only EER is hiding the operating point.
• A single FAR figure is meaningless without its FRR, and vice versa. “FAR of 1 in 50,000” sounds great until you learn the FRR at that setting is 8% and a twentieth of your users get locked out on rainy mornings.

Two more rates you will see and should not confuse with the above:

• FTE — Failure to Enroll: the fraction of people who cannot register a usable template at all (worn fingerprints from manual labor, certain eye conditions for iris). It is an inclusion problem — your fallback path must cover these users, or you have excluded them.
• FTA — Failure to Acquire: the fraction of capture attempts that produce no usable sample (finger too dry, face out of frame). High FTA quietly inflates real-world FRR.

Liveness and anti-spoofing

A matcher only answers “does this sample match the template?” It does not answer “is this sample coming from a real, present human?” That second question is liveness detection, and formally presentation attack detection (PAD), standardized in ISO/IEC 30107. Without it, the strongest matcher in the world is defeated by a printed photo, a replayed video, a silicone finger, a wax model, or an AI-generated deepfake.

The attacks it defends against

• Face: a printed photo, a phone screen replaying video, a paper or 3D-printed mask, and increasingly deepfakes injected into the camera stream.
• Fingerprint: a lifted latent print cast in gelatin, silicone, or wood glue.
• Voice: a recording, a concatenated splice, or a real-time voice clone — by the mid-2020s there are documented bank-fraud cases using AI-cloned voices.
• Iris: a high-resolution printed iris, sometimes with a contact-lens overlay.

Active vs passive liveness

• Active liveness asks the user to do something: blink, turn your head, read a random number aloud, follow a moving dot. It is harder to spoof with static media but adds friction and can be scripted around with sophisticated replays.
• Passive liveness analyzes the sample itself for signs of a real presentation — skin texture and reflectance, depth from a 3D sensor, micro-movements, sub-surface blood flow, sensor-level artifacts of a re-presented screen — with no extra user action. Best UX, and where the market has moved for consumer flows.

The strong systems layer both, and PAD is rated by level in ISO 30107: Level 1 defends against cheap artifacts (a printed photo), Level 2 against more sophisticated ones (well-made masks). When a payment or onboarding flow is on the line, ask which PAD level was independently tested, by a lab such as iBeta, not merely claimed.

Storing biometric data: the irreversible-leak problem

Here is the property that makes biometrics different from every other factor: it cannot be revoked. If a password database leaks, everyone resets. If a raw-fingerprint database leaks, those fingerprints are compromised for the lifetime of every affected person. There is no reset. This single fact drives every storage rule below.

Never store raw images

A serious system does not store the photo of your face or the image of your fingerprint. It stores a template: an extracted, compact feature vector. And it should use template protection so that even the template cannot be turned back into the original trait or linked across systems:

• Cancelable biometrics: apply a repeatable, revocable transform to the features before storing, so a leaked template can be revoked and a new transform re-enrolled — recovering a form of the “reset” you otherwise lack.
• Biometric cryptosystems: bind the biometric to a cryptographic key (fuzzy vault / fuzzy extractor) so the stored data reveals neither the trait nor the key on its own.
• The reference standard for all of this is ISO/IEC 24745 (biometric information protection), whose core requirements are irreversibility, unlinkability, and renewability.

Prefer on-device matching in secure hardware

The strongest architecture keeps the template on the user’s device, inside secure hardware, and matches there:

• Secure Enclave / TEE: Apple’s Secure Enclave, a Trusted Execution Environment, or Android’s StrongBox hold the template in memory the OS itself cannot read. Touch ID, Face ID, and Windows Hello all work this way — your biometric never reaches Apple’s or Microsoft’s servers.
• Match-on-card / match-in-sensor: on smart cards and some sensors, both the template and the comparison live inside the chip; the trait never leaves it.
• The device then attests the result (“a valid biometric unlocked this key”) to the server — typically via a FIDO2/WebAuthn assertion. The server learns “the enrolled human is present,” never the biometric itself. This is exactly why passkeys + device biometrics is such a clean design: the network sees a cryptographic signature, not your face.

Centralized biometric databases are sometimes unavoidable (national ID, some border systems), but they concentrate irreversible risk and demand correspondingly extreme controls. For an ordinary product, the default should be: on device, in secure hardware, matched locally.

Privacy and regulation

Because the data is sensitive and irrevocable, biometrics is one of the most specifically regulated areas in all of identity. You cannot treat it as “just another attribute.”

• BIPA — Illinois Biometric Information Privacy Act: the strictest and most litigated in the US. It requires written notice and explicit prior consent before collecting biometric identifiers, mandates a retention/destruction schedule, and crucially grants a private right of action — individuals can sue directly, with statutory damages per violation. Several very large settlements have come from BIPA. Texas and Washington have their own biometric laws; more US states are following.
• GDPR Article 9 (EU/UK): biometric data used to uniquely identify a person is a special category of personal data, prohibited to process unless a specific condition applies (typically explicit consent, or another Art. 9 basis). It pulls in data-protection-by-design, DPIAs, minimization, and strict purpose limitation.
• Local regimes: most modern data-protection laws mirror this. Mexico’s LFPDPPP classes biometrics as sensitive; Brazil’s LGPD treats it as sensitive personal data; other jurisdictions follow the same “special/sensitive” pattern. Assume biometrics is a regulated category wherever you operate and check the local law.

The practical compliance backbone is consistent across regimes: explicit, informed consent; data minimization (store a protected template, not an image; keep it on-device when you can); a defined retention and deletion policy; and an alternative for people who cannot or will not enroll — which loops straight back to FTE as an inclusion and legal requirement, not a nice-to-have.

Behavioral biometrics: something you do

Everything above is physiological. Behavioral biometrics identifies a person by patterns in how they act, and it plays a genuinely different role in a system.

• Keystroke dynamics: your rhythm, dwell and flight times between keys, habitual typos.
• Mouse dynamics: how you move, curve, and click.
• Touch and swipe: pressure, speed, arc, and finger angle on a screen; how you hold the phone.
• Gait and device-handling: motion-sensor patterns while walking or carrying the device.

Its defining traits:

• Silent and frictionless. It asks the user for nothing. There is no prompt, no scan — it observes signals already present as the person uses the app.
• Continuous, not point-in-time. Where a fingerprint proves presence at the moment of login, behavioral signals keep proving it throughout the session — a natural fit for the continuous-verification idea we develop in the Zero Trust article.
• Auxiliary, never a sole factor. It is a risk signal, not a login. It needs a learning period to build a per-user profile and it drifts, so it feeds an adaptive engine rather than gating access on its own.
• Excellent against account takeover (ATO). When “someone who types and swipes differently” is driving a session whose password was correct, behavioral analytics is often what catches it. That is why it is heavily deployed in banking and CIAM — real vendors here include BioCatch, TypingDNA, and behavioral modules inside fraud platforms — precisely because it raises security with no visible friction.

Think of behavioral biometrics as the quiet co-pilot of the risk engine from the factors article: it does not stop you at the door, it watches whether the person inside still moves like the person who was let in.

Choosing and combining modalities

No single modality is “best” — the right choice is the one whose error profile, cost, and spoof-resistance fit the use case and the population. A payment app on modern phones leans on face or fingerprint because the hardware and secure enclave are already there. A border post can justify iris for its precision and stability. A call center may be stuck with voice and must therefore invest heavily in anti-spoofing against clones.

When one modality isn’t enough, systems use multimodal biometrics — combining two traits (say face and voice) and fusing their scores. Fusion can happen at different stages (feature level, score level, decision level), and done well it lowers both error rates at once and raises the bar for an attacker, who now has to spoof two different traits simultaneously. The cost is more capture friction and more hardware, so multimodal is reserved for higher-assurance contexts rather than a consumer unlock.

A useful design rule: match the modality’s failure mode to your risk tolerance. If false rejects are merely annoying (unlocking a media app), tune loose and pick a convenient modality. If a false accept is catastrophic (moving money, crossing a border), tune tight, demand tested liveness, and consider a second trait or a second factor entirely.

Accessibility: biometrics can silently exclude

A biometric that works for most people can quietly lock out a minority — and that is both an inclusion failure and, increasingly, a legal one. Failure to Enroll (FTE) is not an abstract metric; it is real people who cannot use your system:

• Manual laborers, older adults, and some medical conditions produce worn or hard-to-read fingerprints.
• Certain disabilities, injuries, or eye conditions interfere with iris or facial capture.
• Speech impairments or noisy environments break voice.
• Facial and other systems have shown demographic performance gaps — higher error rates for some skin tones, ages, or genders when training data was unrepresentative. NIST’s FRVT program explicitly measures demographic differentials, and ignoring them ships a system that is less accurate for some of your users than others.

The rule that follows is firm: biometrics must always have an equivalent, non-biometric fallback — a PIN, a passkey, a hardware token — that is not weaker than the biometric it backs up. A fallback so weak that attackers target it instead (the recovery-path problem from the MFA article) defeats the purpose; one so inconvenient that excluded users are effectively locked out defeats inclusion. Design the fallback as a first-class path, not an afterthought.

Template aging: enrollment isn’t forever

A subtlety that trips up real deployments: biometric traits drift. Faces age, gain and lose weight, grow beards; fingerprints wear with manual work; voices change with health and age. The template captured at enrollment slowly diverges from the live sample, and the practical result is a quietly rising FRR over time — legitimate users increasingly rejected, not because the system got worse, but because they changed relative to a frozen reference.

Mature systems handle this with template update: cautiously refreshing the stored template as the user successfully authenticates, so it tracks gradual change. This must be done carefully — update too eagerly and an attacker’s near-miss could poison the template; update from failed matches and you’d train the system to accept the wrong person. So updates happen only on high-confidence successful verifications. Some deployments also schedule periodic re-enrollment. The takeaway for a designer: biometric accuracy is not a fixed spec sheet number but a value that decays without maintenance, and your operational plan has to account for it.

How biometrics and passkeys fit together

The cleanest place biometrics lives in modern authentication is behind a passkey, and understanding why ties this whole article to the previous ones. A passkey (FIDO2/WebAuthn credential) keeps a private key in the device’s secure hardware. Your fingerprint or face doesn’t authenticate you to the server — it unlocks the local private key, which then signs the server’s challenge. The biometric never leaves the device; the network only ever sees a cryptographic signature.

This arrangement gives you the best of both worlds and sidesteps biometrics’ worst risk:

• The irreversible-leak problem disappears at the server — there is no central biometric database to breach, because the trait stays in the enclave.
• Liveness and matching are handled by the platform (Touch ID, Face ID, Windows Hello), which invests heavily in PAD you would struggle to build yourself.
• The user experience is exactly what people already expect: “look at your phone” or “touch the sensor” to log in.

So in practice, the strongest consumer authentication design is not “add face recognition to our login.” It is “adopt passkeys, and let the platform’s biometrics unlock them.” Biometrics becomes the convenient local gate on a phishing-resistant cryptographic factor — which is precisely why the factors and MFA articles kept pointing here.

Recap

Biometrics is the factor where the details decide everything:

1. Modalities differ in cost, precision, and spoofability; the deeper split is verification (1:1) vs identification (1:N) and physiological vs behavioral.
2. Matching is a similarity score against a threshold — never a clean yes/no.
3. FAR/FRR are two ends of one threshold; EER compares systems but is rarely the operating point; always demand FAR with its FRR, plus FTE and FTA.
4. Liveness / PAD is non-negotiable — a matcher without it is defeated by a photo, recording, or deepfake.
5. Storage must avoid raw images, prefer protected/cancelable templates, and ideally match on-device in secure hardware — because a biometric leak is irreversible.
6. BIPA, GDPR Art. 9, and local sensitive-data laws bind you: consent, minimization, retention limits, and an inclusive fallback.
7. Behavioral biometrics is a silent, continuous, auxiliary signal that shines against account takeover.

Three questions to test yourself

1. A vendor advertises a facial system with an EER of 0.4%. What three follow-up questions do you ask before trusting it for a payment-authorization flow?
2. Your product team wants to store face templates in a central cloud database “so users can log in from any device.” Explain the specific risk this creates that a password store does not, and propose an architecture that meets the same goal without central raw biometrics.
3. You are asked to add fingerprint login to a warehouse app used by workers whose fingerprints are often worn or dirty. Which two error metrics do you watch most closely, and what fallback do you design so no worker is locked out?

Hands-on exercises

1. Read the operating point off a real spec. Find a public NIST FRVT or FpVTE report (or a vendor datasheet that cites one) and locate a FAR/FRR pair at a stated threshold. Write one sentence describing the operating point in plain language (“at a false-accept rate of 1 in N, roughly M% of legitimate users are rejected”).
2. Audit your own devices. For a phone and a laptop you use, determine where each stores its biometric template (secure enclave / TEE / other) and whether matching happens on-device. Note whether the biometric ever leaves the device.
3. Draft a consent notice. Write a short BIPA-style notice for enrolling employees in a fingerprint time-clock: what you collect, why, how long you keep it, when you destroy it, and the alternative for someone who declines. Check it against GDPR Art. 9’s explicit-consent bar.