In short
Liveness detection assesses whether a presented face comes from a live person rather than a photograph, screen replay or mask. A liveness claim means nothing without the attack instruments it was tested against, who tested it and when — the reporting framework ISO/IEC 30107-3 defines.
What is being detected
Liveness detection assesses whether the face presented to a camera comes from a live person physically present. The broader term used in standards work is presentation attack detection, because what is being detected is an attack on the capture point rather than an absence of life as such — and naming it that way makes the right question obvious: an attack using what?
That question is the whole subject. Resistance is specific to the attack instruments a system has been tested against. A system that reliably rejects a photograph printed on office paper may do nothing about a high-resolution screen replay, and neither result tells you anything about a silicone mask.
There is no ISO 30107-3 certificate
ISO/IEC 30107-3 defines how presentation attack detection is tested and reported: the methodology, the terminology, and what a test report should state. It is a reporting framework, not a certification scheme, and it defines no pass mark.
So there is nothing to hold. A vendor claiming to be "ISO 30107-3 certified" is describing something that does not exist, in the same way and for the same reason as "NIST certified". What the standard does give you is the ability to compare two vendors' reports, provided both produced one.
Evaluation
What a liveness claim must state
Five things. If any is missing, the claim covers nothing you can rely on — and the last one is the one most often overlooked even by careful buyers.
| Stated | What it tells a buyer | If it is absent |
|---|---|---|
| Attack instruments used | Which specific attacks the result actually covers — printed photograph, screen replay, mask, and at what fidelity. | The result covers nothing specific. It may have been tested only against the easiest possible attack. |
| Who performed the testing | Whether it was independent, and whether the laboratory is one whose reports are taken seriously. | It was probably self-assessment, which is not worthless but is not the same thing. |
| Date of testing | Whether the result reflects the build you would actually receive. | It may predate the shipped version by several releases. |
| Attack level or fidelity | How good the attack was. A phone photograph and a high-resolution print are different tests. | The result may describe resistance to an attack nobody would attempt. |
| Where the check runs | Whether compression between the camera and the analysis has discarded the cues detection depends on. | Laboratory conditions may not apply on site, and the gap can be large. |
ISO/IEC 30107-3 describes a test methodology, not a pass mark. There is no certificate to hold, so a vendor claiming one is describing something that does not exist.
Threat model
Decide whether you need it before you specify it
Liveness adds cost, adds a failure mode, and can add a retry to every transaction. Those are worth paying where the threat is real and wasteful where it is not.
Unattended capture point
Usually worth it
An unattended gate or kiosk is where presenting a photograph or a screen is easiest and least likely to be noticed. This is the case liveness detection exists for.
High-value access
Usually worth it
Where the consequence of a successful substitution is severe, the cost of an extra check and an occasional retry is easy to justify.
Remote or self-service capture
Usually worth it
Nobody is watching the capture, and the person controls the device and the environment entirely. The threat is real and specifying against named instruments matters.
Capture in view of staff
Often over-specified
Someone holding a phone up to a camera in front of a staffed desk is conspicuous. The marginal value over the human already present is lower than it looks on a feature grid.
Low-consequence convenience
Often over-specified
A loyalty check-in or a staff canteen door. The cost of a failed liveness check — a retry, a queue — may exceed the cost of the attack it prevents.
Watchlist monitoring
Usually not the control
Nobody presents a photograph to a ceiling camera hoping to be recognised. The relevant controls here are quality gating and threshold policy, not liveness.
Two different problems
Presentation attacks and injection attacks
Related, frequently conflated, and defended against entirely differently. Specifying them as one capability leaves one of them undefended.
Presentation attack
Something physical is presented to a real camera: a printed photograph, a phone or tablet screen, a paper or silicone mask, a video played back. The camera is genuine; what is in front of it is not a live face.
Defended by: presentation attack detection, tested against named instruments under ISO/IEC 30107-3, running as close to the capture as possible so compression has not removed the cues.
Injection attack
Synthetic or recorded video is fed into the capture pipeline directly, bypassing the camera entirely — a virtual camera driver, a compromised client, a manipulated stream. There is no physical presentation to detect.
Defended by: securing and attesting the capture path — trusted capture hardware, signed streams, device attestation — not by analysing the face in the frame.
A deployment where the capture device is under your physical control — a gate, a turnstile, a fixed terminal — has a much smaller injection surface than one where capture happens on a device the user owns. That difference should shape the specification more than any vendor’s feature list does.
What Ayonix states
The registered claims on this page
Liveness and presentation-attack detection are available in supported capture workflows. What that means for a specific deployment is confirmed in writing rather than advertised as a rate.
ISO/IEC 30107-3 defines how presentation attack detection is tested and reported
- Source type
- Government or standards body
- Verified
- 2026-09-11 · Jan Mocary, Chief Technology Officer
What this does not establish
The standard describes a test methodology. It defines no pass mark and issues no certificate, so "ISO 30107-3 certified" describes nothing that exists. Ayonix makes no compliance claim against it; it is cited as the framework a buyer should require a test report to follow.
1:1 verification, 1:N identification, watchlist matching, face tracking, and liveness and presentation-attack detection
- Source type
- Ayonix first-party statement
- Verified
- 2026-09-11 · Jan Mocary, Chief Technology Officer
What this does not establish
Presentation-attack resistance is specific to the attack instruments tested for. Liveness is available in supported capture workflows, not universally.
No detection rate appears on this page
For the same reason no accuracy percentage appears anywhere on this site: a detection rate without its attack instruments, its testing laboratory and its date cannot be reproduced or compared, so it is not a fact a buyer can act on. Ask us the five questions in the table above; we would rather answer them for your deployment than publish a number that will not survive contact with your capture point.
Frequently asked questions
What is liveness detection?
Liveness detection assesses whether the face presented to a camera comes from a live person physically present, rather than from a photograph, a screen replay, a printed mask or a video. In biometric standards work the broader term is presentation attack detection, because what is being detected is an attack on the capture point rather than an absence of life as such.
What does ISO/IEC 30107-3 actually specify?
It defines how presentation attack detection is tested and reported — the methodology, the terminology and what a test report should state. It is not a certification scheme and it defines no pass mark. There is therefore no certificate to hold, and a vendor claiming to be "ISO 30107-3 certified" is describing something that does not exist. What the standard makes possible is a report you can actually compare between vendors.
What should a liveness claim state before I believe it?
Four things: which presentation attack instruments were used, at what level, who performed the testing, and on what date. A detection rate against unnamed attacks covers nothing specific — it might have been tested only against a printed photograph on office paper, which almost anything defeats. Also ask where the check runs, because compression between the camera and the analysis can remove the very cues detection depends on.
Is liveness detection always necessary?
No, and specifying it reflexively wastes money and adds failure modes. It matters most where the capture point is unattended and where the value of defeating it is high — an unattended gate, a remote verification. Where a camera is in direct view of a staffed position, a person presenting a phone screen to it is conspicuous, and the marginal value is lower. Decide from your threat model rather than from a feature list.
Does liveness detection stop deepfakes?
Those are related but distinct problems and should be specified separately. Presentation attack detection addresses something physically presented to a camera — a photograph, a screen, a mask. A synthetic video injected into the capture pipeline, bypassing the camera entirely, is an injection attack and is defended against differently, largely by securing and attesting the capture path. A vendor treating the two as one capability has not distinguished them.
Where should the liveness check run?
As close to the capture as the architecture allows. Presentation attacks are often detected through fine detail — texture, reflection, moiré patterns from a screen — and video compression between the camera and the analysis point removes exactly that detail. A liveness capability validated in a laboratory on uncompressed frames may perform quite differently on a compressed stream arriving over a network.
Does Ayonix publish presentation attack detection rates?
No, for the same reason no accuracy percentage appears anywhere on this site: a detection rate without the attack instruments, the testing laboratory and the date cannot be reproduced or compared. Liveness and presentation-attack detection are available in supported capture workflows, and the specific capability for a deployment — including what it has been tested against — is confirmed in writing rather than advertised as a number.
Next step
Specify liveness properly, or not at all
Bring the capture point and the threat you are actually defending against. Where liveness is warranted we specify it against named attack instruments; where it is not, saying so is more useful than selling it.