Certified liveness detection: what an ISO/IEC 30107-3 conformance letter does and does not say

This page sits in the deepfake detection hub and follows the liveness and injection overview, which explains what a presentation attack is and why injection attacks fall outside the standard. Here the question is narrower: what does the paper behind the word "certified" actually say?

01What does ISO/IEC 30107-3 cover?

ISO/IEC 30107-3:2023, Edition 2, published in January 2023, is 39 pages from ISO/IEC JTC 1/SC 37. Its abstract says it establishes "principles and methods for the performance assessment of presentation attack detection (PAD) mechanisms", "reporting of testing results from evaluations of PAD mechanisms" and "a classification of known attack types (Annex A)" (ISO catalogue). Out of scope are the standardisation of specific PAD mechanisms, "detailed information about countermeasures (i.e. anti-spoofing techniques), algorithms or sensors", and system-level security assessment. The abstract fixes the boundary in one sentence: "The attacks considered in this document take place at the biometric capture device during presentation. Any other attacks are considered outside the scope of this document."

Two consequences follow for a liveness claim. The standard does not define a passing score, so "ISO 30107-3 compliant" means tested and reported the way the standard describes, not passed at a level the standard sets. And a camera feed replaced in software, the injection attack, is not a presentation at the capture device, so a 30107-3 letter says nothing about it.

02What error rates does the letter report?

The standard's two subsystem metrics are the attack presentation classification error rate and the bona fide presentation classification error rate. As quoted from the standard in the SC37 working group's own slides, APCER is the "proportion of attack presentations using the same PAI species incorrectly classified as bona fide presentations in a specific scenario" and BPCER is the "proportion of bona fide presentations incorrectly classified as attack presentations in a specific scenario" (Busch, SC37 WG3 slides). The qualifier "using the same PAI species" is the point: an APCER is reported per species of attack instrument, a printed photo, a screen replay, a mask, and there is no single APCER for a system.

The same slides carry the standard's advice on summaries. A PAD mechanism "may be reported in a single figure" only as a BPCER at a fixed APCER, written BPCER20 for APCER 5 percent, BPCER100 for 1 percent and BPCER10 for 10 percent, and the standard's guidance is explicit: "DON'T use neither the equal error rate (EER) nor the half-total error rate (HTER)". The APCER and BPCER page sets these definitions beside the ACER that academic anti-spoofing papers still report.

03How does an accredited lab run the test?

The published method read for this page is that of iBeta Quality Assurance, accredited by NIST's National Voluntary Laboratory Accreditation Program under lab code 200962-0 with ISO 30107-3 in its scope. The lab's methodology page describes three test types, PAD subsystem, data capture and full system, and three effort levels of its own design, which it notes are "similar to the FIDO Alliance Levels A & B" but differ from them (iBeta test methodology). The levels are the lab's, not the standard's; the standard has no levels.

Six species of attack are selected per test. For a Level 1 liveness-only test, each species is created and applied within 8 hours, "targeting to present 150 attacks alternated with 50 genuine presentations". Subjects are cooperative volunteers who pose for the photographs, videos or casts the artefacts are made from; the lab states it uses only cooperative subjects because the resulting artefacts are better and the test therefore more conservative. Before any attack, the software version and the exact capture device are recorded, and both are named in the letter.

The bona fide side has a cap. The lab now limits BPCER, or FNMR in a full-system test, to 15 percent for a pass at Levels 1 and 2 and to 10 percent at Level 3; the page records that the limit "were initially unconstrained", then 20 percent, then 15, and is "reviewed every 6 months". A system that rejects more than 15 genuine presentations in a hundred fails the letter however well it blocks attacks.

04What does the letter itself contain?

The lab publishes letters only with the vendor's written consent, and its index lists for each one the date, the vendor, the level, the product, the version tested and the bona fide limit applied. Reading the index on 10 November 2026, the letters state a software version down to the build number, the handset model and operating system version it ran on, the level, and that the configuration was tested "to the ISO 30107-3 Biometric Presentation Attack Detection Standard and found to be in compliance" with that level. The attack error rate is given in the letter; the bona fide error rate is "calculated and may be found in the final report", which is not published.

So a letter pins down five things: the standard, the level, the configuration, the number of species, and the attack error rate at that level. It leaves open the species list in most cases, the BPCER, every other version and device, and every attack that is not a presentation.

05What does "certified" not mean?

It does not mean a certification. The lab's page states that its testing and reporting show the solution "is compliant or conforms with the ISO 30107-3 testing and reporting requirements" and that this "does not translate to a certification of the vendor product"; it adds that the word certification was used until a NVLAP audit in March 2019 corrected it. It does not mean an accuracy figure for recognition: liveness and matching are different subsystems, and the face verification metrics page covers the second, with the IJB-C row worked in pairs as its example. It does not mean the system was attacked with a deepfake: the standard's scope stops at the capture device, and the academic face anti-spoofing benchmarks, with their print and replay protocols, measure the same thing from the research side. And it does not carry over to a new app version or a different phone, because the letter names one of each.

No conformance letter predicts how a liveness check performs against an attack species, a device or a software version it did not test.