Biometric Authentication Security: What an Assessment Actually Tests

Biometric authentication is sold as the end of the password. The honest description is narrower: it replaces a secret the user knows with a measurement of the user's body, and every measurement has a decision threshold attached to it. That threshold is where the security lives. A face system that accepts one impostor in ten thousand is a different product from one that accepts one in a thousand, even when both are described as "AI face login", and neither of them is a lock in the sense a deadbolt is a lock.

Three things make this harder than it looks. Biometric comparison is probabilistic where a password comparison is deterministic, so there is no such thing as a correct or incorrect answer for a single attempt, only a score and a cut-off. The characteristic is not revocable: a leaked password is changed in ninety seconds, a leaked face is leaked for life. And the standards that certify liveness were written for attacks that arrive in front of a camera lens, while the attacks that decide fraud outcomes in 2026 mostly arrive through a virtual camera driver, which those standards exclude from their scope by design.

This guide is about the measurement and the evidence: what a competent assessment of a biometric system actually tests, where the templates live and what that changes, which attacks each control is supposed to stop, what the 2026 legal exposure looks like, and how to read the test report a vendor sends you.

A biometric system is a decision rule, not a lock

Every biometric system performs the same four operations in the same order: capture a sample through a sensor, extract a feature vector from it, compare that vector against a stored reference to produce a similarity score, then apply a threshold and emit a decision. Everything security-relevant is a property of one of those four steps. The sensor can be fed an artefact. The extractor can be fed a sample that never touched a real human, if the capture path is software rather than glass. The comparison can happen on a chip the attacker does not control or on a server the attacker might. The threshold can be tuned for convenience, and it can be changed by a model update that nobody classified as a security change.

That decomposition is why a biometric assessment is not a penetration test in the ordinary sense. A pentester probes an application for reachable weaknesses. A biometric assessment has to enumerate the capture paths the product actually exposes - native mobile SDK, web camera, kiosk hardware, call-centre voice, door controller - the attack species feasible on each, and the control responsible for each species. The output is a matrix of cells, each one tested with a result or marked untested with a reason. "We tested the liveness" is not a result. "We presented 40 printed photographs, 40 screen replays and 20 silicone moulds to iOS SDK build 4.2.1 on three device models, and 38, 39 and 20 were rejected" is a result, and it can be falsified.

The attacker also does not have to defeat the best-defended path. They choose the weakest one. A product with a hardened native client and a web fallback that runs the same liveness model in a browser is only as strong as the browser path, because that is where a fraudster with a virtual camera driver will go. Coverage has to be expressed over the union of paths, not over the flagship client. Ask for the capture-path inventory before you ask for the test plan: if the vendor cannot list the paths, the plan cannot have been scoped against them, and whatever certificate exists was issued for a configuration that is not the one you run.

The four numbers that decide whether the system works

The first is the false match rate, sometimes called the false acceptance rate: the proportion of comparisons between two different people that score above the threshold. It is a property of the algorithm, the threshold and the population, and it is meaningless without the last two. The second is the false non-match rate, or false rejection rate: the proportion of comparisons between two samples of the same person that fall below the threshold. The two move in opposite directions as the threshold moves, which is why a system cannot be described as accurate in the abstract. They are often compressed into a single equal-error rate, the threshold at which the two are equal, and that compression is a marketing convenience. Production systems almost never operate at the equal-error point, because the costs of the two errors are wildly asymmetric. A bank that rejects one genuine customer in a hundred and accepts one impostor in ten thousand is not operating at equal error, and should not.

The third and fourth numbers come from the presentation-attack literature and matter most for a system facing a hostile public. APCER, the attack presentation classification error rate, is the proportion of attack presentations that the detector classifies as genuine. BPCER, the bona fide presentation classification error rate, is the proportion of genuine presentations the detector classifies as an attack. They are only meaningful as a pair, because a detector achieves a perfect APCER by rejecting everything. The convention in the ISO/IEC 30107 series is to report APCER at a fixed BPCER, so "APCER 0.5 per cent at BPCER 5 per cent" is a testable sentence and "99.5 per cent accurate" is not.

The operating-point problem is not academic. A table reporting a fingerprint false match rate of 0.001 per cent with no statement of threshold, dataset or sample quality has told you nothing you can use, because the same algorithm at a stricter threshold on a harder dataset produces a number two orders of magnitude different. When you compare two vendors, compare the sentences rather than the digits. "FMR 1 in 10,000 at FNMR 4 per cent on the NIST FRTE 1:N dataset, model version 2026-04, all demographic groups" is a claim you can check. "99.98 per cent accuracy" is a claim about the style guide.

What NIST SP 800-63B-4 actually requires

The most useful specification in this field is also the one most biometric products quietly fail. NIST Special Publication 800-63B-4, published in 2025, permits biometrics for authentication while constraining them so tightly that several popular designs are out of scope by construction. The requirements are worth restating in substance, because they turn a vague quality argument into a checklist.

Biometrics SHALL be used only as part of multi-factor authentication with a physical authenticator, meaning something the subscriber has; a biometric characteristic is explicitly not recognised as an authenticator by itself. The service SHALL always provide a non-biometric alternative. The system SHALL operate at a false match rate of one in 10,000 or better for all demographic groups, which is a per-group requirement rather than an average. It SHOULD show a false non-match rate below 5 per cent. Presentation attack detection SHOULD be implemented for iris and fingerprint and SHALL be implemented for facial recognition. Voice comparison SHALL NOT be used at all. Testing SHOULD demonstrate an impostor attack presentation accept rate below 0.07. The attempt policy is capped too: no more than five consecutive failures, or ten where conformant PAD is present, a delay of at least thirty seconds once the limit is reached, and an overall ceiling of fifty consecutive attempts, or one hundred with PAD.

Four of those clauses are commercially inconvenient, which is why they are so often absent from product documentation. "Only with a physical authenticator" kills the design where a face is the sole factor on a web login. "Always provide a non-biometric alternative" kills the design whose only recovery path is a support call. "One in 10,000 for all demographic groups" kills the design that quotes a global average and has never measured a per-group differential. "Voice SHALL NOT" kills a category of call-centre authentication still being sold in 2026.

Be precise about what that document is. SP 800-63B-4 is mandatory for US federal agencies and advisory everywhere else, so a private product can ignore it lawfully; what it cannot do is ignore it credibly. When an incident reaches a regulator, opposing counsel or an insurer, the first question is which recognised standard the design was measured against, and "we did our own testing" is a weaker answer than a document with a version number. For remote identity proofing rather than authentication, the companion volume SP 800-63A-4 section 3.14 goes further and requires technical controls against injected media - detecting virtual cameras, emulators and modified devices - plus documentation of the tested attack types and their false negative rates. That is the closest thing to a formal acknowledgement that the camera is not a trust boundary.

Where the template lives, and why it matters

The single most consequential architectural choice is whether the biometric comparison happens on the device the user is holding or on the server the operator controls. When it happens locally, the raw sample and the template never leave a trusted execution environment, and the server receives only a cryptographic proof that a user was verified. That is the model behind FIDO2 and WebAuthn: the authenticator generates an asymmetric key pair per credential, the private key stays in the secure element, and the biometric match is a local gate on using that key. The user-verification flag in the assertion tells the relying party that a local check happened; nothing about the fingerprint or the face crosses the network. A breach of the relying party therefore yields no biometric data at all, which is the only way to make a non-revocable secret safe.

When the comparison happens on the server, the operator is collecting special-category personal data at scale and inheriting the obligations that come with it. That model is common in identity proofing, where the operator needs to compare a selfie against a document portrait, and there the server-side match is unavoidable. It is not unavoidable for ordinary login. A product that uploads a face template on every sign-in, when it could have wrapped the same session behind a device-bound key, has chosen the architecture with the larger breach radius, the larger legal surface and the larger retention problem.

The middle case is the one that produces most of the incidents in practice: match-on-device hardware, but with a template backup that syncs to the cloud for convenience, or a "recovery" flow that uploads a selfie to a vendor when the device is replaced. Those flows quietly convert a local-verification design into a centralised biometric database, and they are usually added by a product team that was never told the difference. If you audit one thing before the deep technical work, audit every code path that sends an image or a template off the device, including the support tools.

Template protection: irreversibility, unlinkability, renewability

Encrypting a template protects it until the moment it is used, and not after. ISO/IEC 24745:2022, the standard for biometric template protection, sets three requirements that encryption on its own does not satisfy. Irreversibility means the template cannot be turned back into a usable biometric sample. Unlinkability means templates derived from the same person in two different systems cannot be correlated. Renewability, or revocability, means a compromised template can be replaced without replacing the person's face.

Why irreversibility is not theoretical: face recognition templates have been partially reconstructed from stored feature vectors in published research, and the general attack against any similarity-match oracle is hill climbing, where an attacker iteratively adjusts a synthetic sample, submits it, and keeps whatever raises the score. If the attacker can call the comparison function - through a stolen API key, a misconfigured endpoint or an insider - a template becomes a search problem rather than a secret. The countermeasure is not a stronger cipher but a limit on the oracle: rate limits, per-subject attempt caps, anomaly detection on the score distribution, and no endpoint that returns the raw similarity score to an untrusted caller.

Unlinkability is the requirement most often missed, because it is invisible in a single-system review. If the same face template is used as the reference in the office door system, the payroll app and a partner's onboarding flow, then those systems can be joined into a single identifier without anyone's consent, and a compromise in the weakest one exposes the identity used in the strongest. Salting and binding a template to a system-specific key is the fix, and it has to be designed in, not retrofitted, because the reference data is already enrolled.

Renewability is where biometrics diverge sharply from every other credential. A password can be revoked. A fingerprint that has been copied - lifted from a glass, reconstructed from a photograph, or harvested from a compromised template store - cannot. Every design therefore needs an answer to the question of what happens when the biometric is no longer trustworthy: a second enrolled finger, a device-bound key that can be re-issued, and an account recovery path that does not depend on the compromised characteristic. If the answer is "we would ask them to use their face more carefully", the design has no answer.

Presentation attacks and the species that matter

A presentation attack is an attempt to interfere with the capture subsystem by placing something in front of it. The vocabulary comes from the ISO/IEC 30107 series: an attack presentation instrument, or PAI, is the object presented, and a species is a class of instrument with a common construction. For faces the species that recur in real fraud are a printed photograph, a screen replay of a photograph or video on a phone, a paper or vinyl mask, a silicone or 3D-printed prosthetic, and increasingly a real-time face swap rendered to a screen. For fingerprints they are a moulded silicone or gelatin finger, a printed transparent overlay, and a lifted latent print transferred to a carrier. For iris they are a printed contact lens and a high-resolution print with a hole for the pupil. For voice they are a replay, a text-to-speech synthesis and a converted recording of another speaker.

Each species fails against a different control. A printed photograph is defeated by depth sensing, texture analysis or a challenge-response that requires motion. A screen replay is defeated by detecting the display itself - moire patterns, refresh artefacts, absence of a 3D surface. A silicone mask defeats texture analysis but is usually caught by depth and by multi-frame consistency, and it is the species that most often separates an expensive sensor from a cheap one. A lifted print defeats an optical sensor's anti-spoofing but often fails against a capacitive one. A synthesised voice defeats almost everything unless the channel carries liveness evidence, which is one of the reasons NIST refuses to recognise voice as an authenticator.

Two conclusions follow. First, a PAD result has to be reported per species; an aggregate number across a mixed attack set tells you the composition of the test, not the strength of the detector. Second, the species list for your threat model is not the list in the standard - it is the list a motivated attacker can build for your product. For a consumer app with photo-based onboarding, the relevant question is what a fraud ring can fabricate for twenty dollars, not what a university laboratory can fabricate for twenty thousand.

Liveness, APCER and the trade nobody prices

Presentation attack detection is the mechanism that decides whether a presented sample is live, and it comes in two shapes. Passive detection analyses the capture itself - depth, reflectance, micro-movement, screen artefacts, sensor noise - without asking the user to do anything. Active detection issues a challenge: blink, turn, read a phrase, smile on request. Active challenges are harder to spoof with a static artefact and easier to spoof with a responsive pipeline, since a real-time deepfake can obey an instruction. Passive detection is invisible to the user and easier to defeat with a sufficiently good artefact.

The cost that never appears in a vendor comparison is the false rejection imposed by aggressive liveness. A detector tuned to reject 99.9 per cent of attacks will also reject a meaningful fraction of genuine users - people in poor light, people wearing glasses, people with a disability that prevents the requested motion, people whose device camera is scratched. Those rejections convert into support tickets, abandoned sign-ups and a manual review queue, and the manual review queue is the real attack surface, because a queue is staffed by humans who can be social-engineered. A system that pushes 8 per cent of genuine users into manual review has not solved the problem; it has moved the problem to a channel with weaker controls.

The correct way to set the trade is to price both errors explicitly. Take the number of authentication attempts per month, multiply by the false match rate to get expected false accepts, multiply by the false non-match rate to get expected false rejects, and put a cost on each. Then choose the operating point that minimises the total, and write that operating point into the requirement. The number that comes out is almost never the vendor default, and that is the point: the default was chosen by whoever wrote the SDK sample code.

The scope hole: a PAD certificate does not test injection

ISO/IEC 30107-3:2023 defines how to test and report presentation attack detection, and its scope is deliberately narrow: attacks presented to the biometric capture device. The mobile profile, ISO/IEC 30107-4:2024, makes the same limitation explicit. Everything that is not an attack at the capture subsystem is outside the document, including system-level security assessment. A lab letter that says a product passed Level 1 or Level 2 conformance is therefore a statement about artefacts shown to a camera, tested on specific devices and configurations, at a specific version, and it says nothing about a video stream that never touched a lens.

That gap is where the fraud moved. An injection attack is a software intrusion into the pipeline between the camera and the matching engine: a virtual camera driver feeding pre-rendered frames to the SDK as if they came from hardware, an emulator presenting a synthetic device with a synthetic sensor, a hooked SDK whose return values are replaced, or a direct API call that submits a captured sample with the client-side checks skipped entirely. To the liveness model, injected frames look like a camera feed, because the model only sees pixels. A system can hold a Level 2 PAD certificate and still accept a deepfake, and in 2026 several have.

The emerging countermeasures are separate from PAD and should be evaluated separately. CEN/TS 18099:2024, approved in October 2024 and published in December, is the first specification for testing biometric injection attack detection, and it gives a structure for the test plan even where no certification scheme exists yet. On the device side the controls are attestation and integrity: Play Integrity on Android, App Attest on iOS, secure-element key binding, checks for emulators, rooted or jailbroken devices, hooking frameworks and screen-sharing or virtual-display services, plus binding the liveness decision to a nonce and to the attested device so that a valid result cannot be replayed from another session. NIST SP 800-63A-4 section 3.14 requires exactly this family of controls for remote proofing, and requires the provider to document which attack types were tested and what the false negative rate was.

Injection attacks, capture path by capture path

On a native mobile client, the injection surface is the operating system's camera abstraction. Android exposes virtual camera providers through the camera framework and through accessibility and display-capture services; a device with a virtual camera installed presents the SDK with frames it never captured. The controls worth testing are the ones that establish provenance rather than the ones that inspect pixels: attestation of the app and device integrity, a check that the camera used is a physical device with the expected characteristics, detection of screen capture and overlay services, and refusal to run the biometric flow when the device fails an integrity verdict. Each of these can be tested by a competent red team in a day, and each of them is frequently absent because it generates support friction on rooted devices.

On the web client, the assumptions are worse. A browser gives the page a media stream and no reliable statement about what produced it; virtual camera devices are a supported feature of every major desktop operating system and are trivial to install. A liveness model running in WebAssembly in the browser can be examined by the attacker, and a comparison made in JavaScript can be bypassed by calling the API directly. The defensible posture is that web capture is a lower-assurance path: it deserves its own risk acceptance, its own rate limits and, for high-value actions, a step-up to a native client or an in-person check. Pretending the web path has the same assurance as an attested native path is the most common architectural error in this field.

At the API layer, the injection surface is whatever the client is trusted to compute. If the endpoint accepts a template, a score or a boolean "liveness passed" from the client, the attacker supplies it. If the endpoint accepts an image, the attacker supplies any image, and the only defence is server-side detection plus metadata that ties the image to a session the server issued. The audit question is simple and brutal: which values in the request does the server verify rather than accept? Anything the server accepts is attacker-controlled, and no amount of client-side hardening changes that.

The kiosk and door-controller path adds the physical channel: a reader can be fed a moulded finger, a photograph or a replay, and the enrolment record can be edited by whoever has maintenance access. The controls are tamper detection, signed firmware, and an audit trail of enrolment changes that is separate from the device. That last one matters more than it sounds, because an insider who can add an enrolment is an insider who has created a permanent credential that no revocation event will notice.

Enrolment is the attack surface nobody tests

Every assessment tends to focus on verification, and the compromise usually happens at enrolment. There are four recurring patterns. The first is morphing: two faces blended into a single image that matches both contributors, which defeats a one-to-one check against a document and was originally an attack on passport issuance. The second is substitution, where the attacker controls both sides of the comparison - a stolen document plus a live face that matches the document's photograph - so every check passes while the identity behind it is wrong. The third is duplicate enrolment, where the same person enrols twice under different identities to double their transaction limits. The fourth is insider enrolment, where an operator with legitimate access creates or edits a reference record.

Each has a control, and each control is a process rather than a model. Morphing is detected by comparing the enrolment image against the document portrait with a dedicated morph detector, and by keeping the original capture rather than a re-encoded thumbnail. Substitution is reduced by binding the enrolment to an independent channel - a document chip read, a credit file check, a video interview - rather than to the attacker's own selfie. Duplicate enrolment is caught by searching the whole population for near-duplicates at enrolment and on a schedule, using a stricter threshold than authentication because the cost of a false positive is a manual review, not a lockout. Insider enrolment is controlled by separation of duties and an immutable audit log.

The reason this section exists in a guide about authentication is that no amount of verification hardening compensates for a poisoned reference set. A face-recognition system with a 1-in-10,000 false match rate and one enrolled impostor has an effective false match rate of one, for that identity, forever. When you scope an assessment, scope the enrolment flow with the same rigour as the login, and test it with the same artefacts.

The threshold is a versioned artefact, not a constant

A threshold that was validated in March is not the threshold running in November, because model updates, sensor changes, camera pipeline changes in the operating system, and SDK upgrades all move the score distribution. The failure mode is quiet: a vendor ships an accuracy improvement, the score distribution shifts, and the operating point that used to yield one false accept in ten thousand now yields one in three thousand, with no change to any configuration the customer can see. Nothing in the build pipeline treats that as a security event unless somebody made it one.

The fix is to treat the model, the threshold and the PAD detector as one versioned artefact with a change-control process. Any change to that artefact reopens the test matrix: at minimum the false match and false non-match measurements on a fixed evaluation set, and the APCER at the agreed BPCER for each PAI species. The evaluation set itself has to be versioned and has to contain the populations you actually serve, which is the subject of the next section. Keep the previous artefacts deployable, because the fastest safe response to a bad model release is a rollback, and a rollback you cannot perform is not a control.

There is a measurement discipline that goes with this. Log the model version and threshold with every decision, so that a complaint about a false rejection six weeks ago can be attributed to the artefact that produced it. Without that field, an investigation into "the system started rejecting me" has no way to distinguish a threshold change from a lighting change from a device change, and the case becomes an argument about memory.

Demographics: one threshold, many populations

A single threshold applied to a diverse population does not produce a single error rate across that population. NIST Interagency Report 8280, published in December 2019 as part three of the Face Recognition Vendor Test, measured one-to-one false positive differentials that were much larger than the false negative ones and present across many, though not all, of the algorithms it evaluated: false positive rates varied by factors of 10 to beyond 100 across demographic groups, with the highest rates for West and East African and East Asian faces and the lowest for Eastern European faces in the application-photo dataset, higher rates for women than men, and elevated rates for the very young and the elderly. A subset of the tested algorithms showed no detectable differential, which is the important half of the finding: it is an algorithm property, not a law of physics, and it is measurable before you deploy.

Eight years later the shape of the problem has improved and not disappeared. NIST's Face Recognition Technology Evaluation now publishes summary measures of demographic differentials - worst-to-best ratios, and ratios of specific regions against a reference - for one-to-one algorithms, updated as vendors submit. The numbers per algorithm are less useful to a buyer than the requirement they support, which is the one NIST wrote into SP 800-63B-4: a false match rate of one in 10,000 or better for all demographic groups. Meeting that clause requires per-group measurement on a dataset that contains the groups you serve, and it requires the measurement to be repeated when the model changes.

The operational consequence is not only fairness, though fairness is the stronger argument. It is that an attacker selects the population with the weakest error rate. If one group's false match rate is fifty times the average, then the attack is to look like that group, and the system's headline number is irrelevant. A security review that reports a single aggregate error rate has therefore not measured the security property; it has measured the marketing property.

Accessibility, fallback and the recovery path

Biometric systems fail for people whose biometrics change: a cut finger, a new pair of glasses, a facial injury, a voice affected by illness, a hand tremor that prevents a challenge gesture. They also fail for people whose biometrics are unusual - very dry skin, very dark or very light irises, a prosthetic eye, a facial difference. Those are not edge cases to be handled by a support script; they are a predictable fraction of the user base, and every one of them hits a fallback path that is usually weaker than the biometric itself.

NIST's requirement that a non-biometric alternative SHALL always be provided is a security requirement disguised as an accessibility one. If the alternative is a password, the system's security is the strength of that password plus the strength of the reset flow. If the alternative is a support agent who resets on request, the system's security is the strength of the support agent's verification, which in most organisations is a date of birth and a postcode. The fallback is not an exception to the control; it is part of the control, and it has to be assessed with the same attack tree. A biometric login in front of an account-recovery process that can be social-engineered is an expensive way to protect a door next to an open window.

For employees, the same logic applies with a legal twist: an accessibility need may require an exemption from a mandatory biometric policy, and a refusal to provide one is a discrimination risk in most jurisdictions. Design the exemption before the policy ships, document it, and make sure the exempted path is not a shared password on a sticky note. That failure mode is so common that it deserves its own line in the assessment report.

What to log, and what must never be logged

The evidence a biometric decision needs is small and specific: a timestamp, a session identifier, the subject or credential identifier, the capture path, the device integrity verdict, the model and threshold version, the modality, the similarity score, the liveness decision and its score, and the outcome. That set answers the questions that arise in a dispute - was the model the validated one, was the device attested, was the rejection a liveness failure or a match failure - without storing anything that cannot be deleted on request.

The evidence it must never contain is the sample. A stored face image, a fingerprint image or a voice recording is special-category personal data in the European Union, a biometric identifier under several US statutes, and a permanent liability in a breach. If a sample has to be retained for a fraud investigation, retain it under a documented basis, a defined retention period, access control and a deletion job that actually runs, and keep it out of the general application logs and out of the analytics pipeline. The most common finding in this category is not a deliberate design choice but a crash-reporting SDK that captured the camera frame as context.

Two operational details decide whether the log is useful. First, log the score, not only the decision: without the score you cannot reconstruct the operating point or detect drift. Second, log the reason code on failure, because "authentication failed" cannot distinguish a spoof attempt from a scratched lens, and the two require opposite responses. Rate-limit and lock-out logic should key on the reason code, not on the generic outcome, or the attacker learns nothing while your genuine users get locked out.

The law that changes the design: GDPR, the AI Act, BIPA, CUBI

In the European Union, biometric data processed to uniquely identify a person is a special category under Article 9(1) of the GDPR, which means the processing needs a condition from Article 9(2) - most often explicit consent, occasionally a substantial public interest basis set by law - in addition to an Article 6 lawful basis. Consent has to be freely given, which is difficult to argue for employees whose workplace access depends on a fingerprint, and several supervisory authorities have said so directly. A large-scale biometric system also triggers a data protection impact assessment under Article 35(3)(b), and the assessment has to do real work: describe the technology, the necessity and proportionality, the risks of false acceptance and false rejection separately, and the measures taken. A DPIA that lists "encryption" and stops has not been written; it has been filled in. The technical evidence a supervisory authority expects overlaps heavily with the access-control measures in the GDPR Article 32 technical measures guide, and the two documents should be written to agree with each other.

The AI Act adds a second track. Regulation (EU) 2024/1689 prohibits real-time remote biometric identification in publicly accessible spaces for law enforcement purposes under Article 5(1)(h), with narrow statutory exceptions, and treats biometric categorisation and several biometric identification uses as high-risk under Annex III. The application timeline moved: the Digital Omnibus on AI was adopted on 19 November 2025, entered into force on 27 July 2026, and pushed the high-risk obligations for stand-alone Annex III systems to 2 December 2027, with Annex I products at 2 August 2028. The prohibitions were not delayed. So a 2026 compliance plan should treat high-risk obligations as having a date rather than as a distant rumour, and should not confuse the delay in conformity-assessment machinery with a suspension of the duties.

In the United States the exposure is statutory and per-violation. Illinois BIPA allows $1,000 per negligent violation and $5,000 per intentional or reckless violation, or actual damages if greater, plus fees and injunctive relief, and any aggrieved person can sue. Public Act 103-0769, effective 2 August 2024, limited recovery so that repeated collection of the same identifier from the same person by the same method is a single violation, and confirmed that an electronic signature counts as a written release. On 1 April 2026 the Seventh Circuit held in Clay v. Union Pacific, No. 25-2185, that the limit applies retroactively to cases pending when it took effect. The settlements still run into millions: Deyerler v. HireVue at 3.75 million dollars for voice and face data in AI video interviews, with a final approval hearing on 28 October 2026; Melzer v. Kenvue at 4.7 million dollars for facial geometry from a skin-analysis tool; Tapia-Rendon v. WorkEasy at 1,685,000 dollars across 21,915 class members for fingerprint templates from cloud time clocks.

Texas has no private right of action and larger penalties. Under Tex. Bus. and Com. Code section 503.001 the attorney general may obtain a civil penalty of up to 25,000 dollars per violation, and the state has used it: 1.4 billion dollars from Meta in July 2024 and 1.375 billion from Google in May 2025, both under CUBI. Amendments effective 1 January 2026 exempt AI training and security-incident work, and clarify that an image being publicly available is not by itself consent to commercial capture. The lesson a technical team should take from those numbers is about data minimisation, not about legal drafting: the cheapest biometric programme is the one where the template never leaves the device, because there is no identifier to retain, disclose or breach.

The assessment itself: a matrix, not a checklist

The deliverable that separates a real assessment from a sales meeting is a matrix whose rows are capture paths and whose columns are attack classes, with each cell carrying either a tested result or an explicit untested status. Rows: native iOS, native Android, mobile web, desktop web, kiosk or reader, call-centre voice, API. Columns: print, screen replay, mask or prosthetic, moulded finger, injected video through a virtual camera, emulated device, hooked or repackaged client, API-level replay, template or score submission, duplicate enrolment, insider enrolment. A seven-by-eleven matrix is seventy-seven cells; a credible engagement tests forty to sixty of them and documents the rest as out of scope with a reason.

Each tested cell needs four fields: the attack instrument and how many presentations were made, the control that was supposed to stop it, the observed outcome, and the residual risk if the control failed. The count matters because a single successful attack proves a vulnerability while a single unsuccessful one proves nothing - the report should state the sample size per cell and never aggregate across species. Where a cell cannot be tested without special hardware or without an accounts-budget, say so, and where a cell is irrelevant because the path does not expose that surface - a kiosk with no network client cannot be fed a virtual camera - record the reasoning rather than the blank.

Two rules keep the matrix honest. Positive controls: every path gets a genuine user test with the agreed cohort, because a detector that rejects everything passes every attack test. And reproducibility: the report must name the build, the device models with their OS versions, the network conditions and the date, because a result against build 4.2.1 on one device is not a result for the fleet. When an item survives to production on the strength of one cell, the assessment should say exactly that in the summary, in those terms.

How to read a PAD report

Vendors submit lab letters that look alike, and seven questions separate a meaningful one from a decorative one. Which PAI species were tested, and in what proportion? A report that lists printed photos and screen replays but no masks describes the cheapest quarter of the threat. Which devices and which SDK version, because a Level 2 result on one handset model does not transfer to a device with a different sensor and pipeline. At which BPCER was APCER measured? What was the test size per species, because 200 presentations and 20,000 presentations produce different confidence. Was the mobile profile tested, or only the generic document? Was injection attack detection tested separately, and if so against what plan - CEN/TS 18099:2024 is the reference to ask for. And when does the letter expire, given that the model has probably been retrained since.

Two further checks are worth making outside the letter. First, whether the tested configuration matches the deployed one: the SDK version, the liveness model version, the capture settings and the device allow-list. A certificate for version 3.x is silent about 4.x. Second, whether the vendor's own bug bounty or incident history mentions bypasses - a PAD bypass published in a conference paper or a bug bounty write-up is evidence about the deployed system that no letter supersedes. If a bypass exists for the detector family, the honest conclusion is that the residual risk is that bypass until a retest says otherwise.

The summary line for a report should therefore be something a non-specialist executive can act on, and it should never be "passed". The usable form is: on these paths, against these species, at these sample sizes, the detector rejected this proportion at this BPCER, using this model version, and these attack classes were not tested and remain unquantified.

What remediation actually looks like

Five findings account for most of the remediation work in this field, and only one of them is a model problem. The first is missing device attestation: the client can run anywhere, including on an emulator, so the first fix is an integrity verdict that gates the biometric flow and a server that refuses unsigned or unattested sessions. The second is no injection testing at all, which is fixed by adding the test plan and, until it passes, by reducing the assurance claimed for the client - a step-up to a native attested path for the high-value action rather than a wider liveness model.

The third is a server-side template store that did not need to exist, fixed by moving verification to the device with WebAuthn and keeping only public keys, then migrating the existing enrolments deliberately with a revocation plan rather than a big-bang cutover. The fourth is an enrolment process with no morph detection and no duplicate search, fixed with a detector, a population search at enrolment, and a periodic re-scan that flags near-duplicates for review. The fifth is telemetry that records only pass or fail, which is cheap to fix and makes everything else measurable afterwards.

What is not remediation: buying a more expensive liveness model, adding a second challenge gesture, or raising the threshold. Each of those changes one number inside the same architecture, and the findings above are architectural. The test of a remediation plan is whether re-running the matrix would move a cell from fail to pass, and a plan that cannot name the cell it moves is not a plan. Where the biometric gate sits in front of an application, a web security audit of the surrounding flows usually belongs in the same programme, because the account-recovery path beside the gate is frequently the weaker door.

Cost, scope and the lawful boundary

Cost in this work is driven by cells, not by days. The variables that matter are the number of capture paths, the number of species per path, the number of device models per path, the size of the evaluation cohort including the demographic spread needed to measure per-group error rates, whether injection testing needs bespoke tooling for each client, and whether the deliverable has to survive an audit or a courtroom. A single-path mobile product assessed against four species on three device models is a small engagement. A multi-path consumer platform assessed against eleven species with a 2,000-subject evaluation set, a report and a retest is a large one. Any quote that cannot be decomposed into those variables is a price, not an estimate.

The lawful boundary does not move because the subject is interesting. Testing requires written authorisation from the system owner, scope limited to systems they control, and a data handling plan for any captured sample, because a test that collects real faces from real users creates the exact special-category data problem the assessment is meant to reduce. Where the engagement touches employees, the employer's own systems, a policy in force beforehand and, in several jurisdictions, works council or employee-representation involvement are conditions of doing the work at all, not paperwork to be completed afterwards. And no assessment should involve capturing a third party's biometrics - a partner's system, a vendor's production tenant, a public camera - without that party's documented consent.

What the work can honestly deliver is a measured statement of what the system resists, what it does not, and what remains unquantified, expressed in numbers a board can read and an auditor can re-run. It cannot deliver a guarantee, and any provider who offers one has misunderstood either the technology or the word.