Liveness Detection: Methods, Metrics, and Testing

Liveness detection is a biometric control that estimates whether a sample comes from a live person who is present during capture, rather than from a photo, replay, mask, or other artefact. In face verification, it helps answer “is this a live capture?” before a separate face-matching system answers “does this face match the reference?”

The standards term for detecting artefacts presented to a biometric sensor is presentation attack detection, or PAD. Liveness and PAD are often used interchangeably in product discussions, but the boundary matters: attacks can also inject synthetic or replayed media into the data path without presenting anything to the physical camera.

Key takeaways

• Liveness and face matching answer different questions. A live stranger can pass liveness and still be the wrong person; an accurate image of the right person can match while being a replay.
• Passive and active methods create different trade-offs. Passive checks observe a normal capture, while active checks ask the user to complete a prompted action.
• PAD and injection defense cover different attack paths. A strong capture flow must consider both the sensor and the software pipeline after it.
• A single accuracy percentage is not enough. Evaluation needs attack-error rates, genuine-user error rates, test conditions, demographic and device slices, latency, and retry behavior.
• Testing must resemble the intended deployment. Attack instruments, cameras, compression, lighting, geography, and user population all affect results.

What liveness detection does

A remote face-verification flow usually contains several distinct decisions:

1. Capture integrity: Did the sample originate through the expected camera and application path?
2. Presentation attack detection: Does the sensor appear to be observing a live biometric characteristic rather than an attack instrument?
3. Biometric quality: Is the sample suitable for analysis?
4. Face matching: Is the captured face sufficiently similar to the trusted reference?
5. Contextual risk: Do the device, network, account, and behavioral signals support the same conclusion?

Collapsing these decisions into one “verified” result makes weaknesses hard to locate. Keeping them separate allows a team to tune policy, explain outcomes, and respond differently to low quality, suspected spoofing, identity mismatch, and high contextual risk.

Liveness is therefore a control inside an identity decision, not proof of identity by itself.

Presentation attacks and injection attacks

A presentation attack occurs at the biometric sensor. The attacker presents something intended to be captured as if it were the target person. Examples include:

• a printed or displayed face image;
• a video replay on another screen;
• a cut-out or partial artefact;
• a two-dimensional or three-dimensional mask;
• makeup, prosthetics, or other appearance modification.

An injection attack changes the capture path. Prerecorded, altered, or generated media may be inserted into a virtual camera, application, operating-system interface, emulator, or network request. The physical camera might never see the forged sample.

This distinction changes the defense. PAD can detect visual or behavioral evidence associated with a presented artefact, but an injected stream may avoid the physical conditions that the PAD method expects. Defenses can therefore include application integrity, trusted capture, replay resistance, session binding, payload authentication, virtual-camera detection, and server-side consistency checks in addition to biometric analysis.

Passive, active, and hybrid liveness

Passive liveness

Passive liveness analyzes a capture without asking the user to perform a conspicuous challenge. Depending on the implementation, it may inspect texture, depth cues, reflections, motion, image formation, temporal consistency, or other signals.

The main benefit is low interaction cost: the check can happen during an ordinary selfie or short capture. The trade-off is that its security depends heavily on the tested attack set, capture channel, model, and threshold. “Passive” describes the user experience, not a universal level of assurance.

Active liveness

Active liveness asks the user to respond to a prompt, such as changing head pose or following a randomized sequence. The response can add challenge-response evidence and make a fixed replay less useful.

The trade-offs are added time, accessibility requirements, localization needs, and user error. Predictable or reusable challenges can also lose value, so the challenge design and session binding matter as much as the visible gesture.

Hybrid liveness

A hybrid flow combines passive analysis with an active challenge, often escalating only when the passive result is uncertain or the surrounding risk is higher. This can preserve a short path for most genuine users while collecting more evidence in selected cases.

Method	User interaction	Main strength	Main limitation	Useful pattern
Passive	Normal capture	Low friction	Depends on capture conditions and tested attacks	Default screening
Active	Prompted action	Adds challenge-response evidence	More abandonment and accessibility work	Higher-risk or uncertain cases
Hybrid	Conditional	Can balance evidence and friction	More policy and orchestration complexity	Risk-based escalation

The right choice depends on the action being protected. Account recovery, high-value transfers, age checks, employee access, and initial customer onboarding do not necessarily justify the same threshold or interaction.

How a liveness decision is produced

Although implementations differ, a well-structured flow commonly follows these stages:

1. Start a bound session. The backend creates a short-lived attempt associated with the expected user, action, device, and policy.
2. Guide capture. The interface checks framing, visibility, lighting, and motion while giving accessible instructions.
3. Protect the input path. The application limits replay and substitution opportunities and binds the sample to the current session.
4. Check sample quality. Unusable input is separated from suspected attacks; asking for a better capture is different from rejecting fraud.
5. Run PAD or liveness analysis. The system produces scores or categorical evidence based on the configured method.
6. Match the identity when required. A separate biometric comparison links the live capture to a trusted reference.
7. Combine risk signals. Device, IP, attempt history, velocity, and account context may change the required action.
8. Apply policy. The result may be pass, retry, step-up, manual review, or decline.
9. Record the decision. Audit data should identify versions, thresholds, evidence, timing, and the reason for the outcome.

Retries deserve explicit rules. Unlimited attempts give attackers more opportunities and can hide operational problems. Overly strict limits, however, can punish genuine users with older cameras, disabilities, poor connectivity, or difficult lighting.

The metrics that matter

ISO/IEC 30107 separates errors involving attack presentations from errors involving genuine users. Common PAD terms include:

• APCER — Attack Presentation Classification Error Rate: the proportion of attack presentations of a specified type that are incorrectly classified as bona fide.
• BPCER — Bona Fide Presentation Classification Error Rate: the proportion of genuine presentations incorrectly classified as attacks.

These values must be interpreted together and at a stated operating point. Lowering a threshold may reject more attacks while also rejecting more genuine users. Aggregating all attacks into one average can conceal weakness against a particular instrument, such as replays or masks.

Other operational measures are also necessary:

• failure to acquire or complete;
• retry and abandonment rates;
• decision latency;
• results by device, operating system, camera, and network condition;
• results across relevant demographic groups;
• manual-review rate and reviewer agreement;
• confirmed fraud and false-positive outcomes after deployment.

Face matching introduces its own false-match and false-non-match measures. Those should not be presented as liveness metrics. A complete report names the subsystem, population, threshold, test set, and denominator for every rate.

What independent PAD testing proves—and what it does not

Independent evaluation is valuable because it gives a repeatable test plan, documented attack instruments, and results produced outside the vendor’s own demonstration. ISO/IEC 30107-3 specifies principles for PAD testing and reporting.

Certification or laboratory testing does not prove that every deployment will perform identically. Read the scope:

• Which product and version were tested?
• Was the mode active, passive, or both?
• Which attack species and presentation levels were included?
• Which devices, cameras, and environmental conditions were used?
• What thresholds and retry rules applied?
• Did testing cover only presentation attacks, or also injection attacks?

A deployment can diverge from a laboratory result through different cameras, compression, SDK integration, thresholds, capture guidance, or policy. Treat the report as evidence about a defined configuration, then add testing for the actual environment.

How to evaluate a liveness system

1. Define the protected action

State what happens after a pass and the harm caused by a false accept or false reject. The consequence of opening a low-risk account may differ from authorizing account recovery or a large transfer.

2. Build an attack model

List relevant presentation instruments and injection paths. Include ordinary replays and prints before focusing only on sophisticated synthetic media. Consider whether an attacker possesses a high-quality image, a video, identity documents, account credentials, or control of the device.

3. Demand scoped evidence

Request per-attack results at the proposed operating threshold, not an unlabeled “99%” figure. Review genuine-user errors, completion, latency, device coverage, accessibility, and independent test scope alongside attack performance.

4. Test the real integration

Run the production SDK or capture component on the devices, browsers, bandwidth, and lighting your users actually have. Test interruption, permission denial, backgrounding, retries, emulators, virtual cameras, and reused sessions.

5. Evaluate the whole decision

Test face matching, document or database evidence, session binding, device and network signals, step-up logic, review tools, audit records, and recovery paths. A liveness result cannot compensate for a weak enrollment reference or an insecure fallback.

6. Monitor after launch

Track outcome shifts by product version, device segment, geography, acquisition channel, and policy. Changes can indicate a new attack, a model regression, a camera-specific issue, or a traffic-mix change. Preserve versioned evidence so historical decisions remain explainable.

Common evaluation mistakes

Treating liveness as identity proof

A live person can use someone else’s document or a synthetic identity. Pair presence evidence with a trusted reference and other customer-due-diligence controls.

Comparing vendors with one headline number

Percentages without denominators, attack types, thresholds, and genuine-user errors are not comparable. Ask for the operating curve or results at the threshold you intend to use.

Ignoring the injection path

Camera-facing PAD and application integrity solve related but different problems. Test whether prerecorded or generated media can bypass the expected sensor path.

Confusing poor quality with fraud

Blur, glare, occlusion, accessibility needs, and low bandwidth can cause uncertainty. A quality retry should use different messaging and policy from a suspected attack.

Blocking every uncertain attempt

Binary policy can raise false positives and exclude genuine users. Risk-based retry, active step-up, another factor, and trained review are often safer than forcing one detector to decide everything.

Leaving recovery weaker than enrollment

Attackers target the easiest path. If account recovery or factor reset bypasses the original assurance, strong onboarding liveness does not protect the account lifecycle.

A deployment checklist

Before launch, confirm that:

• the protected action and required assurance are documented;
• presentation and injection threats are modeled separately;
• test results identify versions, thresholds, devices, attack instruments, and denominators;
• liveness, quality, and face-match outcomes remain separate;
• sessions and captures are short-lived, bound, and resistant to replay;
• retry, step-up, review, and recovery policies have explicit limits;
• accessibility and low-end-device journeys are tested;
• logs preserve the reason, evidence, configuration, and version for each decision;
• monitoring can detect shifts by attack type and user segment;
• privacy retention and access controls match the sensitivity of biometric data.

Using Didit for liveness inside an identity workflow

Didit provides Passive Liveness at $0.10 per check and Active Liveness at $0.15 per check. Its listed certifications include iBeta Level 1 PAD. Teams can combine liveness with ID Verification, face matching, and Device and IP Analysis in a workflow, then choose when to retry, step up, review, or stop.

The full KYC bundle is listed at $0.33 and combines ID Verification, Passive Liveness, Face Match, and IP Analysis. Current module prices are published on the pricing page. These product facts describe available controls; an organization must still set thresholds and review rules for its own risk, users, and regulatory obligations.

Frequently asked questions

Is liveness detection the same as face recognition?

No. Liveness estimates whether a biometric sample comes from a live, present person. Face matching compares that sample with a reference to estimate whether they depict the same person. Many flows need both.

What is presentation attack detection?

PAD is the automated detection of attempts to interfere with a biometric system at the sensor by presenting an artefact or altered characteristic. It is the standards-oriented term commonly associated with liveness controls.

Is passive or active liveness better?

Neither is universally better. Passive methods usually reduce interaction, while active methods add challenge-response evidence at the cost of friction and accessibility work. Evaluate both against the same attack model, user population, devices, and operating policy.

Can liveness detection stop deepfakes?

It can be one layer against some synthetic-media attacks, but it is not a complete deepfake defense. Injection controls, trusted capture, forensic and provenance signals, face matching, contextual risk, and secure recovery remain necessary.

What do APCER and BPCER mean?

APCER measures attack presentations incorrectly classified as genuine; BPCER measures genuine presentations incorrectly classified as attacks. Both depend on the tested attack types and operating threshold.

Does a PAD certification cover injection attacks?

Not automatically. Certification scope must be read carefully. PAD testing focuses on presentation attacks under defined conditions; injection and application-path defenses may require separate evaluation.

How often should liveness be used?

Use should follow the risk of the action. It may be appropriate at enrollment, recovery, high-risk authentication, or sensitive transactions, but repeated biometric capture also creates privacy and user-experience costs.

Primary references

• NIST glossary: Presentation Attack Detection
• ISO/IEC 30107-1:2023 biometric presentation attack detection framework
• ISO/IEC 30107-3:2023 PAD testing and reporting
• NIST FATE Part 10: Performance of passive, software-based PAD
• NIST SP 800-63B-4: Authentication and authenticator management
• FIDO Alliance face verification certification program

Liveness works best when its claim stays narrow and testable: it adds evidence that a biometric sample came from a live person at capture. Identity, authorization, and ongoing risk decisions must be built around that evidence rather than inferred from it.