Biometrics: types, error rates, liveness, and privacy

The cold mornings

Daniel’s company replaces the warehouse punch cards with fingerprint time clocks. The pilot looks great in the office. Then winter arrives, and on cold mornings about one in five warehouse workers can’t clock in on the first try: dry, cracked, or dusty fingers don’t read. A few of the older workers never managed to enroll at all. The queue at the clock gets long, someone props the side door open, and the shift supervisor starts writing times on paper. Then legal sends a note asking where the fingerprint data is stored, whether the workers signed a consent form, and what happens to the data when someone leaves.

In the factors article we met biometrics as “something you are,” summarized in a few paragraphs. That’s enough to design a sign-in screen. It isn’t enough for the decisions practitioners actually get asked to make, like the ones Daniel is now facing: should matching happen on the device or on a server, what false-accept rate is acceptable, is the liveness check good enough for a payment, are we even allowed to store this data here?

Biometrics looks simple from the outside (“scan your face and you’re in”) and is subtle underneath. It’s the only category of factor where a design mistake can harm people permanently, because nobody can issue you a new fingerprint. It’s also the factor with the most specific law around it. So it gets its own article, built around one mental model: a biometric system never asks “is this Sara?” and gets a clean yes or no. It measures a similarity score between a fresh sample and a stored template, and compares that score with a threshold someone chose. Almost every decision below is really about where to put that threshold and how far to trust the sample.

The main modalities

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

Two structural distinctions matter more than the modality itself. The first is verification versus identification. Verification, one to one, asks whether this is the person they claim to be: one fresh sample against one stored template, as when you unlock your phone or Daniel’s workers clock in with their employee number. Identification, one to many, asks who this person is: one sample against a whole database. Identification is much harder, because error rates that are negligible one to one explode when you search millions of templates and get millions of chances to match the wrong person. Most authentication is one to one; large-scale identification belongs to border control and law enforcement, with different risks and legal profiles.

The second distinction is physiological versus behavioral. Fingerprint, face, iris, voice, and vein measure a physical trait captured at a moment. Behavioral biometrics measures how you act, and its signals accumulate continuously. We treat it separately near the end because it plays a different role.

How matching works

Understanding the pipeline is what lets you reason about failures. Whatever the modality, every biometric system 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, runs a liveness or presentation-attack-detection check, extracts features, 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 sign-in]
    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 stand out. The system doesn’t store or compare raw images at match time; it compares feature templates, compact mathematical representations, and a good template can’t be turned back into the original image. Liveness runs before or alongside matching, because a matcher that happily accepts a good photo is worthless without a liveness gate in front of it. And the final decision is a threshold comparison, with a threshold someone sets. That’s where error rates come from.

The error metrics: FAR, FRR, EER

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

Because matching is a score against a threshold, exactly two mistakes are possible. In a false accept, an impostor’s score clears the threshold and they get in; the rate is the FAR, the False Accept Rate, also called the False Match Rate in ISO terms. It’s the security error. In a false reject, a legitimate user’s score falls short and they’re turned away; the rate is the FRR, the False Reject Rate, or False Non-Match Rate. It’s the usability error, and it’s what Daniel’s workers were hitting on cold mornings.

FAR and FRR aren’t independent dials. They’re two ends of the same dial, the threshold. Raise it, demanding a closer match, and fewer impostors get through, but more legitimate users are rejected on an off day with a wet finger or bad lighting. Lower it, and legitimate users breeze through while impostors have a better chance. With a fixed system you can’t minimize both. You pick a point on the curve that fits the risk. Unlocking a music app? Lean toward a low FRR, because a frustrated user matters more than a rare false accept. Authorizing a bank transfer? Lean toward a low FAR, because asking a real user to try again beats letting an impostor in. A warehouse time clock sits somewhere in between: a buddy clocking in for a friend is a real but limited risk, and a queue of workers who can’t clock in is a daily cost.

The EER, Equal Error Rate, is the point where FAR equals FRR. It collapses the whole curve into one number, which makes it handy for comparing systems: a sensor with a 0.1% EER is generally better than one with 2%. But almost nobody runs at the EER. Real deployments deliberately sit off it, usually at a low, fixed FAR such as “no more than 0.001%,” and accept whatever FRR that implies, so a vendor who quotes only the EER is hiding the operating point. And a single FAR figure means nothing without its FRR, or the other way round. “A false accept rate of 1 in 50,000” sounds great until you learn the FRR at that setting is 8%, and one in twelve users gets locked out on rainy mornings.

Two more rates are easy to confuse with these. FTE, Failure to Enroll, is the share of people who can’t register a usable template at all, such as manual workers with worn fingerprints or people with certain eye conditions for iris. It’s an inclusion problem, and those older warehouse workers were Daniel’s FTE. Your fallback has to cover them or you’ve excluded them. FTA, Failure to Acquire, is the share of capture attempts that produce no usable sample, a finger too dry or a face out of frame. A high FTA quietly inflates the FRR people experience in the real world.

When you evaluate a vendor, never accept a lone number. Ask at what FAR the FRR was measured and on which public dataset, then ask about FTE and about performance against presentation attacks under a recognized standard. The reference benchmarks are NIST’s FRVT, FpVTE, and IREX evaluations and the ISO/IEC 19795 testing methodology. A vendor who can map their claims onto those is serious.

Liveness and anti-spoofing

A matcher only answers whether the sample matches the template. It doesn’t answer whether the sample comes from a real person who’s actually there. That second question is liveness detection, formally presentation attack detection (PAD), standardized in ISO/IEC 30107. Without it, the best matcher in the world falls to a printed photo, a replayed video, a silicone finger, or an AI deepfake.

The attacks vary by modality. Against faces, attackers use printed photos, phone screens replaying video, paper or 3D-printed masks, and more and more often deepfakes injected straight into the camera stream. Against fingerprints, they cast a lifted print in gelatin, silicone, or wood glue. Against voice, they use recordings, spliced audio, or real-time voice clones; by the mid-2020s there were documented bank frauds using AI-cloned voices. Against iris, they use high-resolution prints, sometimes with a contact lens on top.

Liveness comes in two styles. Active liveness asks the user to do something: blink, turn their head, read a random number aloud, follow a moving dot. It’s harder to beat with static media but adds friction, and sophisticated replays can script around it. Passive liveness analyzes the sample itself for signs of a real presentation, such as skin texture and reflectance, depth from a 3D sensor, micro-movements, blood flow under the skin, or the artifacts a screen leaves when it’s held up to a camera, with no extra action from the user. It gives the best experience, and it’s where consumer flows have moved.

Strong systems layer both, and ISO 30107 rates PAD by level: Level 1 defends against cheap artifacts like a printed photo, Level 2 against more sophisticated ones like a well-made mask. When a payment or onboarding flow depends on it, ask which level was independently tested by a lab such as iBeta, not merely claimed. A plain 2D face match without liveness is one of the most common and dangerous designs out there: it looks like strong security and falls to someone holding up a photo. If you can’t fund real liveness, a well-implemented passkey is a better use of the budget than a face scan that only looks secure.

Storing biometric data

Biometrics differs from every other factor in one way that drives every storage rule: it can’t be revoked. If a password database leaks, everyone resets their password. If a database of raw fingerprints leaks, those fingerprints are compromised for the rest of every affected person’s life. There’s no reset.

So a serious system never stores the photo of your face or the image of your fingerprint. It stores a template, and it uses template protection so that even the template can’t be turned back into the trait or linked across systems. Cancelable biometrics applies a repeatable, revocable transformation to the features before storing them, so a leaked template can be revoked and the person re-enrolled under a new transformation, which recovers a kind of reset. Biometric cryptosystems, such as fuzzy vaults and fuzzy extractors, bind the biometric to a cryptographic key so the stored data reveals neither the trait nor the key on its own. The reference standard is ISO/IEC 24745, whose core requirements are irreversibility, unlinkability, and renewability.

The strongest architecture keeps the template on the user’s device, inside secure hardware, and matches there. Apple’s Secure Enclave, a Trusted Execution Environment, or Android’s StrongBox hold the template where even the operating system can’t read it. Touch ID, Face ID, and Windows Hello all work this way, and your biometric never reaches Apple’s or Microsoft’s servers. On smart cards and some sensors, both the template and the comparison live inside the chip and the trait never leaves it. The device then vouches for the result, “a valid biometric unlocked this key,” usually through a FIDO2 or WebAuthn assertion. The server learns that the enrolled person is present and never sees the biometric itself.

Central biometric databases are sometimes unavoidable, as with national ID systems or some border controls, but they concentrate irreversible risk and need correspondingly extreme controls. For an ordinary product, and for Daniel’s time clocks, the default should be on the device, in secure hardware, matched locally. Before anyone builds central biometric storage, someone in the room should ask: “What’s our plan the day this database leaks?” For passwords the answer is a forced reset. For biometrics there’s no good answer, and if the team can’t produce one, the design is what’s wrong.

Privacy and regulation

Because the data is sensitive and irrevocable, biometrics is one of the most specifically regulated areas in identity. You can’t treat it as just another attribute.

Illinois’s Biometric Information Privacy Act (BIPA) is the strictest and most litigated law in the United States. It requires written notice and explicit consent before collecting biometric identifiers, demands a published retention and destruction schedule, and, crucially, gives individuals a private right of action, so people can sue directly for statutory damages per violation. Several very large settlements have come out of BIPA, many of them over exactly the kind of fingerprint time clock Daniel installed. Texas and Washington have their own biometric laws, and more states are following. In the EU and UK, GDPR Article 9 makes biometric data used to uniquely identify someone a special category of personal data that can’t be processed unless a specific condition applies, usually explicit consent, and it brings data protection by design, impact assessments, minimization, and strict purpose limits with it. Most modern data-protection laws follow the same pattern: Mexico’s LFPDPPP classes biometrics as sensitive, Brazil’s LGPD treats it as sensitive personal data, and so on. Assume biometrics is a regulated category wherever you operate, and check the local law.

The practical backbone is the same across regimes: explicit, informed consent; data minimization, meaning a protected template rather than an image, kept on the device when possible; a defined retention and deletion policy; and an alternative for people who can’t or won’t enroll. That last point loops straight back to FTE. It’s an inclusion requirement and a legal one, not a nice extra.

Behavioral biometrics

Everything so far has been physiological. Behavioral biometrics identifies a person by patterns in how they act, and it plays a genuinely different role. It looks at typing dynamics, the rhythm and the time between keys and your usual typos; mouse dynamics, how you move, curve, and click; touch and swipe, the pressure, speed, arc, and angle on a screen and how you hold the phone; and gait and handling, the motion-sensor patterns while you walk with the device.

It’s silent: there’s no prompt and no scan, just signals already present as someone uses the app. It’s continuous rather than a single moment: a fingerprint proves presence at sign-in, while behavioral signals keep proving it throughout the session, a natural fit for the continuous verification idea the Zero Trust article develops. It’s always a supporting signal, never the only factor, because it needs a learning period to build a profile for each user and it drifts, so it feeds an adaptive risk engine rather than deciding access alone. And it’s very good against account takeover. When someone who types and swipes differently is driving a session whose password was correct, behavioral analytics is often what notices. That’s why banks and customer identity platforms deploy it heavily, through vendors such as BioCatch, TypingDNA, and the behavioral modules of fraud platforms: it raises security with no visible friction. Think of it as the quiet co-pilot of the risk engine from the factors article. It doesn’t 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 modality is best in general. The right one is the one whose error profile, cost, and resistance to spoofing fit the use case and the people using it. A payment app on modern phones leans on face or fingerprint because the hardware and the 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 invest heavily in defenses against cloning.

When one modality isn’t enough, systems use multimodal biometrics, combining two traits such as face and voice and fusing their scores. Fusion can happen at the feature, score, or decision level, and done well it lowers both error rates at once and forces an attacker to spoof two different traits simultaneously. The cost is more capture friction and more hardware, so it’s reserved for higher-assurance settings rather than unlocking a phone. The useful rule is to match the modality’s failure mode to your tolerance for risk. If false rejects are merely annoying, tune loosely and choose something convenient. If a false accept is catastrophic, such as moving money or crossing a border, tune tightly, insist on tested liveness, and consider a second trait or a different second factor altogether.

Biometrics can quietly exclude people

A biometric that works for most people can quietly lock out a minority, which is an inclusion failure and, more and more, a legal one. FTE isn’t an abstract number; it’s people who can’t use your system. Manual workers, older adults, and some medical conditions produce worn or hard-to-read fingerprints, as Daniel found out. Some disabilities, injuries, and eye conditions interfere with iris or face capture. Speech impairments and noisy places break voice. And face recognition and other systems have shown demographic gaps in performance, with higher error rates for some skin tones, ages, or genders when the training data wasn’t representative. NIST’s FRVT program measures these demographic differences explicitly, and ignoring them means shipping a system that’s less accurate for some of your users than for others.

The rule that follows is firm: biometrics always needs an equivalent fallback that isn’t biometric, such as a PIN, a passkey, or a hardware token, and that fallback must not be weaker than the biometric it backs up. A fallback so weak that attackers go after it instead, the recovery 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. For the warehouse, that meant a badge plus PIN at every clock, available to anyone, with no questions asked.

Templates age

Another subtlety catches real deployments out: biometric traits drift. Faces age, gain and lose weight, grow beards; fingerprints wear down with manual work; voices change with health and age. The template captured at enrollment slowly moves away from the live sample, and the result is an FRR that quietly rises over time. Legitimate users get rejected more often, not because the system got worse, but because they changed relative to a frozen reference.

Mature systems handle this with template updates, carefully refreshing the stored template when the user authenticates successfully so it tracks gradual change. It has to be done cautiously. Update too eagerly and an attacker’s near miss could poison the template; update from failed matches and you’d teach the system to accept the wrong person. So updates happen only after high-confidence successful verifications, and some deployments also schedule periodic re-enrollment. Biometric accuracy isn’t a fixed number on a datasheet; it decays without maintenance, and your operating plan has to account for that.

Biometrics and passkeys

The cleanest place for biometrics in modern authentication is behind a passkey, and the reason ties this article to the previous ones. A passkey, a FIDO2 or 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, and the network only ever sees a cryptographic signature.

That arrangement sidesteps biometrics’ worst risk. There’s 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 in presentation attack detection you’d struggle to build yourself. And the experience is exactly what people already expect: look at your phone or touch the sensor. So the strongest consumer design isn’t “add face recognition to our sign-in.” It’s “adopt passkeys and let the platform’s biometrics unlock them.” The biometric becomes the convenient local gate on a phishing-resistant cryptographic factor.

Recap

With biometrics, the details decide everything. Modalities differ in cost, precision, and how easily they’re spoofed, and the deeper splits are verification versus identification and physiological versus behavioral. Matching produces a similarity score against a threshold, never a clean yes or no. FAR and FRR are two ends of one threshold; the EER compares systems but is rarely where they run, so always ask for the FAR together with its FRR, plus FTE and FTA. Liveness, or presentation attack detection, is non-negotiable, because without it a matcher falls to a photo, a recording, or a deepfake. Storage must avoid raw images, prefer protected or cancelable templates, and ideally match on the device in secure hardware, because a biometric leak can’t be undone. BIPA, GDPR Article 9, and local laws on sensitive data require consent, minimization, retention limits, and an inclusive fallback. And behavioral biometrics is a silent, continuous supporting signal that shines against account takeover.

Three questions to test yourself

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

Hands-on exercises

1. Read the operating point off a real report. Find a public NIST FRVT or FpVTE report, or a vendor datasheet that cites one, and locate a FAR and FRR pair at a stated threshold. Write one sentence describing that operating point in plain language (“at a false-accept rate of 1 in N, about M% of legitimate users are rejected”).
2. Audit your own devices. For a phone and a laptop you use, find out where each stores its biometric template (secure enclave, TEE, or something else) and whether matching happens on the device. Note whether the biometric ever leaves it.
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 anyone who declines. Check it against the explicit-consent bar in GDPR Article 9.