What liveness detection is, and what it does about deepfakes
The difference between passive and active liveness, why presentation attacks and injection attacks need entirely different defences, what ISO 30107 levels mean, and which checks actually hold up.
Verifying an ID card proves the card is genuine. Liveness detection answers a completely different question: is the person in front of the camera a live human, and are they the cardholder?
Confuse the two and you leave an obvious gap: a photo of a valid ID plus a video of its owner from social media becomes enough to pass verification.
Two different attacks, two different defences
Presentation attack
The attacker shows the camera something fake: a printed photo, a video playing on a tablet, a paper mask, a silicone face cast.
This class of attack is about what the camera sees, and so is the defence: texture analysis, depth, micro-movement, screen reflections, moiré patterns.
Injection attack
The attacker shows the camera nothing. They bypass the camera feed entirely — install a virtual camera driver, run in an emulator, or tamper with the frames the SDK receives on a rooted device.
This is the real threat today, and texture analysis cannot stop it, because the injected footage already is a real face. The defence is completely different: device integrity checks, app signature validation, virtual camera detection, server-side frame consistency analysis.
Deepfakes are weak as presentation attacks and strong as injection attacks. When a vendor says “we detect deepfakes”, the question to ask is: at which layer?
Passive or active?
Active liveness asks the user to do something: turn your head, smile, blink, follow a dot on screen.
- Upside: the challenge is random and issued in the moment, so a pre-recorded video does not fit.
- Downside: it costs the user effort. Drop-off rises measurably, especially among older users and in noisy environments.
Passive liveness asks for nothing. It analyses texture, depth and lighting consistency from a single frame or a short stream.
- Upside: practically invisible. The step finishes as fast as taking a selfie.
- Downside: on its own it is defenceless against injection attacks.
In practice the right answer is not one or the other but a layered setup: passive by default, step up to an active challenge when a risk signal fires, and device integrity checks throughout.
What ISO/IEC 30107-3 tells you
The standard defines how liveness detection is tested. Two metrics matter:
- APCER (Attack Presentation Classification Error Rate) — the share of fake presentations accepted as live. Lower is better.
- BPCER (Bona-fide Presentation Classification Error Rate) — the share of real users rejected. Also lower is better.
The two pull against each other. Tighten the threshold and APCER falls while BPCER rises: you become safer and lose more genuine customers.
The levels express the cost of the attack:
- Level 1 — cheap attacks: printed photos, video on a phone screen.
- Level 2 — expensive attacks: 3D-printed masks, silicone faces, professional make-up.
When asking a vendor for a report, one number is not enough. Which lab, which level, which attack species, what date — and what was BPCER at that operating point?
Türkiye sets an actual number
In most jurisdictions the expectation around liveness stays qualitative. Türkiye is an exception: its anti-money-laundering rules put a numerical ceiling on the false acceptance rate of the algorithm used where remote identity verification runs fully automatically, and require that ceiling to be evidenced by a report.
That makes it the most concrete yardstick available when comparing vendors. Because more than one form of certification is accepted, the right question is not “do you have a TSE report” but “which certification are you relying on, and what rate was measured”.
One thing to notice: the ceiling sits on false acceptance — the APCER side. Nothing caps the share of genuine users rejected. A system tuned hard enough to clear the bar can meet the rule while quietly costing you conversion. That is why you ask for both rates together.
What to ask
These questions separate serious liveness products from marketing:
- Passive, active, or both? Is there step-up logic?
- What is done about injection attacks? Is there virtual camera detection?
- Is device integrity checked — root, jailbreak, emulator, hooking?
- Is the decision made on the device or on the server? An on-device verdict cannot be trusted.
- Which lab ran the ISO 30107-3 test, at which level?
- What is BPCER alongside APCER? If only one is shared, the picture is incomplete.
- Were error rates measured across skin tones and age groups?
Do not skip the last one. Models trained on insufficiently diverse data produce systematically higher rejection rates for particular groups of users. That is both a fairness problem and a direct conversion loss.
Liveness is not matching
A common confusion: liveness detection is not the same as face matching.
- Liveness — is this a live human?
- Matching — is this live human the person in the DG2 photo from the chip?
They are separate steps and you need both. Matching without liveness can be passed with a photograph. Liveness without matching lets any live human pass with any card.
Where it belongs in the flow
Liveness goes last. The reason is practical: asking someone to show their face is the most personal step in the flow. A user who has already read both sides of their card has invested in the process, and is markedly more likely to finish.
Do it the other way round — start with liveness — and you lose people before they ever reach the card.
Common questions
- What is liveness detection?
- Liveness detection establishes that the person in front of the camera is live and present. It is a separate step from face matching: matching asks whether this is the person in the document, liveness asks whether it is a real human at all rather than a photo, video or mask.
- What is the difference between passive and active liveness?
- Active liveness asks the user to do something — turn their head, smile, follow a dot. Passive liveness asks for nothing and analyses texture, depth and lighting consistency instead. Passive finishes far faster but on its own is defenceless against injection attacks.
- Does liveness detection stop deepfakes?
- Partly. A deepfake shown to the camera is a presentation attack and can be caught by texture analysis. The real threat is bypassing the camera feed entirely with a virtual camera or emulator — an injection attack — which is stopped by device integrity checks and virtual camera detection, not texture analysis.
- What are APCER and BPCER?
- APCER measures the share of fake presentations accepted as live; BPCER the share of genuine users rejected. They pull against each other: tightening the threshold lowers APCER and raises BPCER. If a vendor shares only one figure, the picture is incomplete.