Biometric Authentication Platforms Buyer’s Guide: How to Compare Matching, Liveness and Privacy Controls

Biometric authentication products all claim high accuracy and strong liveness, but the numbers are rarely comparable and the biggest risks sit in architecture and privacy, not in the matcher. This buyer's guide covers platforms that authenticate people by face, fingerprint, iris or palm: on-device biometrics behind passkeys and FIDO authenticators, server-side face authentication for customers, and workforce biometric readers and kiosks. It helps identity, fraud and privacy teams set requirements, read vendor test evidence, ask the right questions and run a proof of concept. Behavioural signals are covered separately in the Behavioural Biometrics Buyer's Guide, and the detail of presentation attack testing in the Biometric Liveness and Presentation Attack Detection Guide.

Key takeaways

• Prefer local matching on the user's device or authenticator; central biometric databases add breach and privacy exposure that cannot be undone.
• Treat biometrics as one factor bound to a device or credential, never as a standalone secret, in line with NIST SP 800-63B-4.
• Ask for independent test evidence on matching (FMR and FNMR per demographic group) and presentation attack detection, at stated operating points.
• Test injection attacks separately, because PAD certification of the capture path does not cover virtual cameras or tampered apps.
• Settle the legal basis and retention first: biometric data used for unique identification is special category data under UK and EU GDPR, and laws such as Illinois BIPA add consent and destruction rules.

Define requirements

• Use case: workforce sign-in, customer sign-in, step-up for high-risk transactions, account recovery, or physical entry. Each has different error costs.
• Verification or identification: one-to-one verification (is this the enrolled person?) carries far less risk than one-to-many identification against a gallery. Most authentication needs only verification.
• Assurance target: the authenticator assurance level you need. See the NIST SP 800-63B-4 Authenticator Assurance Levels Guide.
• Population: size, devices, accessibility needs, and users who cannot or will not enrol. A non-biometric alternative is required by NIST SP 800-63B-4 and expected by privacy regulators.
• Channels: mobile app, web, kiosk, door reader, contact centre.
• Jurisdictions: where users live and where data will be processed. See the Biometric Privacy Laws Map.

Architectures compared

NIST SP 800-63B-4 states that biometrics shall only be used as part of multi-factor authentication with a physical authenticator, and that local verification on the authenticator is preferred over central comparison because central storage raises additional privacy concerns. That alone eliminates many standalone "face as password" designs for higher assurance levels.

Evaluation criteria

Vendor accuracy claims often quote a false accept rate without a matching false reject rate, or results at a threshold you will never use. Ask for both rates at the same threshold, from the same test, on a population that resembles yours. NIST's FATE PAD evaluation (NIST IR 8491) found accuracy varied widely between algorithms, so marketing figures are not a substitute for independent reports.

Privacy and legal requirements

• UK and EU GDPR: biometric data processed to uniquely identify a person is special category data under Article 9, which needs an Article 9 condition (often explicit consent) as well as an Article 6 lawful basis, and a data protection impact assessment is normally expected. The UK ICO biometric guidance is under review following the Data (Use and Access) Act 2025, so check the current version.
• US state laws: the Illinois Biometric Information Privacy Act requires written notice, written release, a public retention and destruction policy and limits on disclosure. See the Illinois BIPA and Biometric Privacy Guide.
• Vendor role: confirm whether the vendor is your processor or claims any right to reuse images or templates, for example to train models. Contract terms should prohibit reuse without your agreement.
• Retention and deletion: templates and images should be deleted when the purpose ends, with evidence. Ask how deletion reaches backups and sub-processors.

Questions to ask vendors

• Is matching done on the device, on a token, or on your servers? If on your servers, where, and who can access the template store?
• Give us FMR and FNMR at the threshold you recommend, per demographic group, from an independent ISO/IEC 19795-1 test.
• Which PAD test reports do you hold, from which laboratory, under ISO/IEC 30107-3, and which attack species and levels were tested?
• How do you detect injection attacks such as virtual cameras, emulators and manipulated video streams, and how was that tested?
• Do you retain enrolment images, for how long, and can we turn retention off?
• Can templates be revoked and re-enrolled if your systems are breached? What would you notify, and how fast?
• What is the fallback for users who cannot enrol or repeatedly fail, and how is that fallback protected from abuse?
• Do you use customer images or templates to train or tune models? Under what terms?
• Which FIDO certifications do your authenticators or SDKs hold, and against which requirement version?

Red flags

• Accuracy quoted as a single percentage with no FMR, FNMR, threshold or test population.
• "Certified liveness" with no named laboratory, standard or test level, or a PAD report presented as proof against injection.
• Biometrics offered as the only factor, with no device binding, for sign-in to sensitive systems.
• Central storage of raw face or fingerprint images by default, or no deletion API.
• Voice proposed as an authentication factor; NIST SP 800-63B-4 says voice-based comparison shall not be used. See the voice biometrics guide.
• No demographic performance data, or refusal to discuss bias testing.
• Contract terms allowing the vendor to reuse biometric data for its own purposes.

Proof of concept

1. Write the success criteria first: target FNMR, maximum acceptable step-up rate, completion time and accessibility outcomes.
2. Enrol a pilot group that reflects your real population in age, skin tone, devices and accessibility needs, with informed consent and a DPIA in place.
3. Measure genuine-user failure rates and completion times per group and per device type over at least two weeks.
4. Commission an authorised presentation attack and injection test against the pilot configuration, not just the vendor's lab build.
5. Test failed-attempt throttling, the non-biometric fallback and the recovery journey, including abuse of the fallback.
6. Request deletion of a pilot user's data and confirm, with evidence, that templates and images are gone.
7. Stream authentication events to your SIEM and fraud tools; check you can see enrolments, failures, PAD rejections and fallbacks.
8. Plan rollout in rings, with the ability to switch any ring back to the previous authenticator if error rates exceed the agreed limit.

Measures to track after rollout: FNMR and fallback rate by user group, PAD and injection rejections per thousand attempts, enrolment completion rate, deletion requests completed on time, and account takeover incidents through the biometric route.

Framework mapping

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support across authentication, customer identity, IAM and fraud prevention. Browse vendors in our products directory or contact us.

Related NHI Mgmt Group resources: Biometrics Guide · Biometric Liveness and Presentation Attack Detection Guide · Passwordless and Passkeys Guide · Deepfake Detection Buyer's Guide · Identity Verification Buyer's Guide