ISO/IEC 30107-3

The international standard that defines how to evaluate presentation attack detection in biometric systems. What method it sets, what metrics it establishes, and the two things attributed to it that are not actually in its text.

In short

ISO/IEC 30107-3 is the international standard that defines how a biometric system's ability to detect presentation attacks is tested and reported. It sets the test method, the metrics used to express the result, and the way that result must be reported.

It is a measurement standard. It is not a certification, it does not grant a seal, and it does not define conformance levels: it defines how to measure so that two results are comparable.

What the standard defines

The standard's value is in the procedure, because that is what turns a product claim into a result a third party can verify.

  • The test method — a lab builds a set of presentation attack instruments, presents them to the system under controlled conditions, and records what the system did with each presentation.
  • The metrics — how the result is expressed, so a report from one lab reads consistently against one from another.
  • The report — what must be declared alongside the number: what was tested, with what instruments, on what system, and under what conditions. A result without that context means nothing.

What the standard does not do is evaluate anyone on its own. It is the test manual, not the test.

The metrics it establishes

These are the three that support any reading of a report, and they are not interchangeable. A report that states only one of them does not let you evaluate the system's behavior.

  • APCER — the proportion of attack presentations incorrectly classified as legitimate. How many attacks got through.
  • BPCER — the proportion of legitimate presentations incorrectly classified as an attack. How many real users were rejected.
  • IAPMR — in a full-system evaluation, the proportion of attack presentations that ended up producing a match.

APCER and BPCER move in opposite directions: a system tuned to let fewer attacks through rejects more legitimate users. That is why the two are read together, and why a test says considerably more about a product than a marketing description of its liveness detection.

The standard does not define levels: the levels belong to iBeta's testing program

It is the most repeated mistake in the industry, and it shows up in vendor materials, in tenders, and in technical notes.

ISO/IEC 30107-3 has no levels. Those tiers belong to the testing program of iBeta, a lab that applies the standard's methodology and organizes its tests by attack potential — that is, by the time, skill, equipment, and cost it takes to build the instrument:

  • Level 1 — low-cost, easy-to-build attack instruments, made with materials and tools within anyone's reach.
  • Level 2 — more sophisticated and costly instruments, closer to an attacker with resources and time.
  • Level 3 — highly prepared instruments, such as custom-made hyper-realistic masks. The lab added it after the two previous levels.

The distinction matters when comparing vendors: the standard is the method, the level is the rigor of the test, and the lab is who runs it. A vendor that says it is "ISO/IEC 30107-3 certified" without naming the lab or the level is stating which manual it was measured against, not what result it got.

The standard does not evaluate injection attacks

This is the boundary of the standard's scope, and it needs to be said plainly, because a certification is often read as if it covered the entire synthetic-face problem.

The scope of ISO/IEC 30107-3 is presentation attacks — the ones that happen in front of the capture device: something is shown to the sensor, and the sensor works normally.

A video injection attack operates on another layer. It shows the sensor nothing: it replaces the video feed before it reaches the application, using a virtual camera, an emulator, or device tampering. The image never passed through a lens, so no test under this standard says anything about it.

No certification under this standard covers injection. Detecting it requires verifying the origin of the feed and the integrity of the execution environment, which are different controls that depend in part on what the device's operating system exposes.

Frequently asked questions

It is the international standard that defines how to evaluate and how to report a biometric system's ability to detect presentation attacks. It sets the test method, the result metrics (APCER, BPCER, and IAPMR), and what must be declared alongside the number for the result to be interpretable. It is a measurement standard: it does not grant a seal or evaluate anyone on its own, it defines how to measure so that two tests are comparable.

They do not exist: the standard does not define conformance levels. The levels belong to iBeta's testing program, a lab that applies the standard's methodology. Level 1 uses low-cost, easy-to-build attack instruments; Level 2 adds more sophisticated and costly instruments; the lab also added a Level 3 for highly prepared instruments. The standard is the method, the level is the rigor of the test, and they are different things.

No. Its scope is presentation attacks, the ones carried out by showing something to the capture device. An injection attack replaces the video feed before it reaches the application, without passing through the camera, and falls outside what this standard evaluates. No certification under this standard, from any vendor, says anything about injection.

Four facts, and all four are verifiable: which lab ran the test, which level of its program was passed, on what date, and against which version of the product. The date and the version are the ones most often left out, and the ones that matter most, because a result from two years ago was obtained against attack instruments from two years ago.

One identity, one SDK

VU ONE brings identity verification, authentication and fraud protection together on a single identity graph.

The verification you run at signup stays available to authentication and to your fraud rules, with no repeated processes and no duplicated data.

Verify, Authenticate and Protect, consolidated in one place.

Request a demo