Active vs Passive Liveness, why the old trade-off no longer holds

Between January and August 2025, a single bank’s digital loan onboarding absorbed 8,065 attempts to defeat its liveness detection, which works out to roughly thirty-three every day for eight months, and not one of those attackers held a mask up to a camera. Threat-intelligence firm Group-IB found they had fed AI-generated faces straight into the verification pipeline through virtual camera software, so the liveness check never saw a spoof at all.

Most buying conversations about liveness are still stuck somewhere else, on whether the system should ask the user to blink. That question mattered a great deal ten years ago, and onboarding teams have been trading conversion against fraud defence over it ever since. Independent lab results have since answered it, and the answer is not the one the industry spent a decade assuming.

What is Active Liveness Detection?

Active liveness detection asks the user to perform an instructed action, then confirms that the action happened in real time and in response to that specific instruction. The system issues a challenge the attacker cannot predict, because a printed photograph or a pre-recorded video cannot answer a prompt it has never seen.

Three prompt families cover almost every active implementation:

1. Motion challenges: Turn the head left, tilt down, move closer to the camera. The system tracks whether the face geometry shifts the way a real head would.
2. Expression challenges: Blink, smile, open the mouth. The system watches for the small changes around the eyes and mouth that accompany a genuine expression.
3. Randomised challenges: Follow a moving dot, or read aloud a number generated for that session. Randomisation is what stops an attacker from preparing the answer in advance.

Each family was designed against a specific attack of the 2010s, which was a static photograph or a replayed video held up to a camera. Against that threat, the logic held up well for years.

What is Passive Liveness Detection?

Passive liveness detection reads a single captured frame, or a very short capture, for evidence that a real human was physically present, and it issues no instruction to the user at all. From the user’s side, a passive liveness check looks like taking an ordinary selfie, because that is all it is.

The signals sit inside the image rather than in the user’s behaviour. A passive liveness check normally reads four families of evidence:

• Micro-texture: Human skin scatters light differently from paper, from a display panel, and from cast silicone, and the difference survives at ordinary phone-camera resolution.
• Depth and parallax: A real face is a three-dimensional surface, so the depth cues in a single frame differ measurably from those of a flat reproduction.
• Replay artefacts: Screens leave moiré patterns, refresh banding, and specular reflections that a live face never produces.
• Generative artefacts:  Synthetic media leaves statistical fingerprints in the frequency content of an image, invisible to the eye but straightforward to measure.

None of those signals requires the user to do anything, which is the entire point of the approach. The user takes one photo, and the decision happens behind it in a fraction of a second. Facial liveness detection explains how these signals work together to produce a single pass-or-fail decision. 

Passive vs Active Liveness Detection differences at a glance

The differences between the two methods are mostly about where the burden sits, because both defend against the same class of attack. The comparison below sets out the practical trade-offs rather than the marketing ones.

Accessibility deserves more weight than the market usually gives it. A prompt to blink, smile, or turn the head assumes a user who can perform that action on demand, and a meaningful share of any consumer base cannot. Clause 5.3 of ETSI EN 301 549, the harmonised European accessibility standard for ICT, requires that a system using biological characteristics must not rely on one such characteristic as its only means of identifying a user. Whichever liveness mode you choose, an alternative path is a design requirement in the EU rather than a nice-to-have, and active flows tend to need that path more often.

Why did the industry assume being active was safer?

The assumption came from a correlation rather than from a controlled comparison, and it hardened into received wisdom before anyone re-tested it.

Active Liveness was easy to explain

Active liveness offered something which is rare in security, it was a mechanism which a non-specialist could explain in one sentence. A photograph cannot blink, a replayed video cannot follow a randomly generated instruction, so demanding an unpredictable action must raise the attacker’s cost. Buyers found that reasoning persuasive, auditors found it visible, and product teams found it defensible in a review. Visibility became a proxy for rigour, and an interface that looks like it is working tends to be trusted more than one that says nothing.

What the lab record actually depicted

Vendors clearing the harder independent test tiers in the early years generally did so with active flows, and the market read that pattern as proof that the prompts were doing the work. The more likely explanation is that those vendors were simply further along. By 2023, the National Institute of Standards and Technology had already evaluated 82 passive, software-based presentation attack detection algorithms in Part 10 of its Face Analysis Technology Evaluation, which is not the profile of an immature technique. Passive detection was research-mature well before the market treated it as equally secure.

What Level 3 testing actually permits, and why that changes the answer

Most vendor claims about liveness security collapse into a single sentence about passing an independent test, and almost none of them tell you what passing that test permits. The tiers are published, so you can grade any claim yourself.

iBeta Quality Assurance, a NIST/NVLAP-accredited laboratory, evaluates presentation attack detection against ISO/IEC 30107-3 in three tiers of difficulty. The tolerances differ sharply between them.

Read the Level 3 row carefully, because the interesting number is the tolerance. A system can be handed a Level 3 confirmation letter while letting one attack in twenty through, and while wrongly rejecting one genuine user in ten. Those allowances exist because hyper-realistic silicone and urethane masks built by experienced attackers are genuinely hard to stop, and the standard’s authors set the given tolerances to match that difficulty level.

Against those allowances, a 0% attack acceptance rate and a 0% genuine-user rejection rate is not a marginal pass. Shufti’s passive single-selfie liveness recorded exactly that across 900 mask presentations and 100 genuine presentations, this was tested between 27 March and 24 April 2026 on a Google Pixel 4 running Android 12 and an iPhone 12 Pro running iOS 16.6.1. The confirmation letter sits on iBeta’s public register alongside every other letter the lab has issued, where Level 3 entries remain a small minority of the total. The device choice carries weight too, because a result obtained on older handsets tells you more about a real user base than one obtained on current flagships alone.

iBeta states plainly on that same page that its testing indicates conformance with ISO/IEC 30107-3 and that this “does not translate to a certification of the vendor product”. Any vendor selling you a liveness “certification” is describing something the laboratory does not issue.

The attack is neither active nor passive liveness stops

Both methods are presentation attack defences, which means both assume the image reaching the algorithm came from the device camera. Injection attacks void that assumption by feeding synthetic video straight into the capture pipeline through a virtual camera, an emulator, or an intercepted stream, so the liveness model scores a manufactured face without ever seeing a spoof held up to a lens.

The scale is no longer theoretical. Threat-intelligence firm Group-IB documented 8,065 biometric injection attempts against a single financial institution’s digital lending onboarding between January and August 2025, all using AI-generated faces delivered through virtual cameras, in its Weaponized AI research published in January 2026. Roughly thirty-three attempts a day at one institution is an industrialised operation, not opportunistic fraud, and neither an active prompt nor a passive texture check addresses it. Injection needs its own control layer, which is why Shufti separates that detection from liveness entirely. The mechanics are covered in Shufti’s breakdown of presentation and injection attacks.

What should you actually ask a liveness vendor?

Stop asking whether a vendor uses active or passive liveness detection, because the answer tells you almost nothing about how hard the system is to beat. Five questions do the work instead:

1. Which test tier did you clear, and can I see the letter? A published confirmation letter naming the tier, the product, and the version is checkable. A claim of “independently tested” is not.
2. What were the actual error rates? Level 3 permits 5% of attacks through and 10% of genuine users rejected. A vendor at the ceiling and a vendor at zero hold the same letter.
3. Which devices was the evaluation run on? Results from current flagships alone say little about the older handsets much of your user base carries.
4. How do you detect injection, and is it separate from liveness? If the answer folds injection into the liveness model, the system is scoring whatever the pipeline hands it.
5. What happens to a user who fails? A fallback route determines whether a false rejection costs you a customer or thirty extra seconds, and EN 301 549 makes that route mandatory for EU-facing services.

How Shufti handles the security versus friction trade-off?

If you run high-volume onboarding, you already know the shape of the problem. Every prompt you add to protect against fraud costs you genuine users who misread it, fail it, or abandon the flow, and the fraud team and the growth team end up arguing over the same screen.

Shufti face verification solution removes that argument by defaulting to passive liveness on an engine Shufti built and owns, so the user submits one selfie and the presentation attack decision happens behind it with no prompt at all. Active liveness stays available on the same engine as a deliberate step-up for high-risk moments, which means the friction becomes a risk decision you control rather than a fixed cost on every session. The passive mode holds iBeta Level 3 conformance under ISO/IEC 30107-3 at 0% attack acceptance and 0% genuine-user rejection.