Most liveness detection vendors will show you the same demo. A phone, a face, a green checkmark. That tells you almost nothing about how the system behaves when someone actually tries to break it.
This guide gives you a framework to evaluate liveness detection software on the things that separate one vendor from another once the pilot ends and real volume starts. We do not rank products here. Vendor rankings age badly, and the right choice depends on your channel, your devices and your regulatory context. What does not change is the set of questions worth asking.
Deepfakes are becoming more sophisticated, increasing the risk of fraud and identity manipulation in digital environments. Download our 10-step guide to learn how to detect threats early and protect your organization with proven best practices.
What liveness detection software actually protects against
Liveness detection answers one question: is the biometric sample in front of the camera coming from a real person who is physically present right now?
That question splits into two very different attack surfaces, and a lot of buyer confusion starts here.
Presentation attacks happen in front of the camera. Someone holds up a printed photo, replays a video on a second screen, or wears a silicone mask. The sensor sees something real, but not a real person. This is the category that ISO/IEC 30107 covers, and the standard is explicit that it deals with attacks taking place at the capture device during presentation.
Injection attacks bypass the camera completely. The attacker feeds a synthetic video stream directly into the application, using a virtual camera, an emulator or a compromised device. Nothing is presented to a sensor at all, so a system that only evaluates the image content can be satisfied by a well made deepfake. These attacks sit outside the scope of ISO/IEC 30107-3, which means a PAD certificate says nothing about them.
A vendor can be strong on one and weak on the other. When you compare liveness detection software, treat these as two separate line items rather than a single score.
Criterion 1: independent PAD certification under ISO/IEC 30107-3
Ask for third party evaluation results, not internal benchmarks. The relevant standard is ISO/IEC 30107-3, which defines how presentation attack detection is tested and reported. Independent labs run these evaluations, and the results are the closest thing the industry has to a common language.
Two details matter more than the certificate itself.
Level 1, Level 2, and Level 3 are not the same test
Level 1 covers lower cost attack instruments such as printed photos and screen replays.
Level 2 covers more sophisticated instruments, including custom made masks, and Level 3 evaluations introduce attack instruments that reflect higher attacker effort and resources, like Tom Cruise’s Mission Impossible masks.
A vendor that says “iBeta certified” without specifying the level has told you very little.
Check the metric alongside the level. Subsystem evaluations usually report APCER but it is mandatory to confirm BPCER as well, the classification error rates for attacks and for genuine users. Full system evaluations report IAPMR, the rate at which an attack is matched as a genuine user. These are not interchangeable, and a strong number on one says nothing about the other, and it is important to balance both security with usability.
Results are bound to test conditions
Any figure you are shown, including a zero false acceptance result, describes performance against the specific attack instruments used in that evaluation, under that lab’s protocol, on that date. It is a strong signal. It is not a guarantee against attack types that were not in scope. A vendor who explains this distinction unprompted is usually the one who understands their own system best.
Government led evaluations
Beyond lab certification, look for participation in government led programmes. The DHS Science and Technology Directorate ran the Remote Identity Validation Rally through 2025, evaluating document validation, selfie to document matching and presentation attack detection at the Maryland Test Facility, with results published under anonymised system identifiers.
RIVR is useful for a specific reason: it tests with human participants under conditions closer to real deployment, and it reports both security and usability metrics side by side. That combination exposes the tradeoff most vendor decks hide. A system can accept zero attacks and still reject a meaningful share of genuine users, and RIVR makes both numbers visible at once. Willingness to be measured that publicly is itself informative.
Criterion 2: passive liveness or active liveness
Active liveness asks the user to do something. Blink, turn your head, follow a dot, read a number aloud. Passive liveness analyses the capture without asking for any action.
Active checks were the early answer to presentation attacks, and they still have a place in high risk flows. The cost is measured in abandonment. Every instruction is a moment where a user misunderstands, gets frustrated or gives up, and the effect is not evenly distributed. Older users, users with limited mobility and users on older devices drop off more.
Passive liveness removes that friction, but only if it is genuinely passive. Some systems described as passive still require a specific framing or a slow approach to the camera. Ask to see the actual capture experience on a mid range Android device, not on the demo phone.
Note that the two are evaluated differently. Passive evaluations process previously acquired samples, while active evaluations assess the complete capture process with real users, which is why transaction time and satisfaction only appear in the active results. Comparing a passive score to an active score is not a like for like comparison.
The practical question is not which approach is better. It is whether the vendor lets you configure the level of challenge per risk tier, so that a routine login and a high value account opening do not have to use the same flow.
Criterion 3: on-device or server-side processing
Ask where the biometric sample is analysed. On the device, or on a server after upload. On-device processing changes several things at once. The raw image does not have to leave the phone, which narrows your data protection exposure and simplifies conversations with legal and compliance teams. Latency drops, because there is no round trip. And the flow keeps working where connectivity is poor, which matters far more in field operations, rural branches and emerging markets than most vendor decks acknowledge.
Server side processing has its own advantages, including easier model updates and centralised logging. The point is not that one architecture wins. The point is that this is an architectural decision with downstream consequences for privacy reviews, cost per transaction and geographic reach, and it should be made deliberately rather than inherited from whichever vendor you picked.
Criterion 4: injection attack detection and capture chain integrity
This is where injection attacks are won or lost, and it is the criterion most often missing from evaluation checklists.
A liveness engine that receives a video frame has no way of knowing whether that frame came from the device camera or from software pretending to be the device camera.
Protection has to be built at the point of capture. Look for vendors that can explain, in technical terms, how they bind the captured sample to the physical sensor and how they detect emulators, virtual cameras and tampered runtime environments.
Ask directly: what happens if I run your biometric SDK on a rooted device with a virtual camera feeding a deepfake video? A good answer is specific. A vague answer about advanced AI detection usually means the check happens after capture, which is the wrong layer.
Get a tailored demo of our contactless biometric platform and see how it fits your specific use case.
Criterion 5: coverage across users and devices
Liveness detection has to work for everyone who needs to use it, not for the average of your user base. Ask for performance data broken down by demographic group, by device tier and by lighting condition. Systems that perform well in aggregate can still fail disproportionately for specific skin tones, ages or device classes, and those failures land as support tickets, branch visits and abandoned applications. Device coverage deserves its own question.
If your users include people on entry level Android phones with basic front facing cameras, confirm that the system runs on that hardware rather than requiring depth sensors or recent flagship chipsets. Universality is a technical property, and it is worth testing before you commit.
Criterion 6: SDK integration and documentation
Documentation quality is a reasonable proxy for engineering quality. Before signing, have one of your own developers integrate the SDK in a sandbox and time it.
Specific things to check:
- Platform coverage for the environments you actually ship, including native iOS and Android, and any web or hybrid framework in your stack
- SDK size and its effect on your app bundle
- How model updates are delivered, and whether they require a full app release
- Whether the UI is customisable enough to match your brand without forking anything
- What the fallback path looks like when liveness fails, and whether that path is auditable
Criterion 7: questions to ask in a liveness detection demo
Bring these to the vendor call.
- Which ISO/IEC 30107-3 level have you been evaluated at, by which lab, and on what date?
- What attack instruments were in scope, and which were not?
- What were your APCER and BPCER, or your IAPMR, and which metric applies to your evaluation type?
- How do you detect injection attacks, and at what layer?
- Is processing on-device, server side, or configurable?
- Can I see performance broken down by demographic group and device tier?
- What is the minimum device specification you support?
- What happens to the captured image after the decision is made?
The answers you get to questions two, three and six will tell you more than any comparison table.
Choosing the best liveness detection software for your risk profile
Choosing liveness detection software is less about finding the highest score and more about matching the system to where your risk actually sits. A remote onboarding flow for a digital bank has a different threat profile than an in branch identity check or a returning user login.
Start by mapping which of your flows face presentation attacks, which face injection attacks, and which face both. Then evaluate vendors against that map rather than against a generic feature list. The vendor that can explain its own limits clearly is usually the one that will still be working three years from now.
Get a tailored demo of our contactless biometric platform and see how it fits your specific use case.
References
- ISO/IEC 30107-3:2023, Information technology. Biometric presentation attack detection. Part 3: Testing and reporting, Edition 2, January 2023. ISO/IEC JTC 1/SC 37. https://www.iso.org/standard/79520.html
- ISO/IEC 30107-1:2016, Information technology. Biometric presentation attack detection. Part 1: Framework. ISO/IEC JTC 1/SC 37. https://www.iso.org/standard/53227.html
- iBeta Quality Assurance, ISO 30107-3 Presentation Attack Detection Test Methodology and Confirmation Letters. https://www.ibeta.com/iso-30107-3-presentation-attack-detection-confirmation-letters/
- U.S. Department of Homeland Security, Science and Technology Directorate, Remote Identity Validation Rally. https://www.dhs.gov/science-and-technology/remote-identity-validation-rally
- DHS S&T, DHS S&T Announces New Remote Identity Validation Rally, press release, 6 March 2025. https://dhs.gov/science-and-technology/news/2025/03/06/dhs-st-announces-new-remote-identity-validation-rally
- Maryland Test Facility, Remote Identity Validation Rally: Results. https://mdtf.org/rivr/Results
- Biometric Update, Aware active and passive liveness tested in RIVR’s biometric PAD track, April 2026. https://www.biometricupdate.com/202604/aware-active-and-passive-liveness-tested-in-rivrs-biometric-pad-track
- Identy.io, Identy.io Achieves Zero Attack Acceptance in DHS RIVR Face Liveness Evaluation, Business Wire, 18 March 2026. https://businesswire.com/news/home/20260318279525/en/Identy.io-Achieves-Zero-Attack-Acceptance-in-DHS-RIVR-Face-Liveness-Evaluation-Leads-Field-on-Speed-and-User-Satisfaction
- Identy.io, ISO/IEC 30107-3 PAD Level 2: Biometric Buyer’s Guide. https://www.identy.io/iso-iec-30107-3-pad-level-2-biometric-buyer-guide/
