Liveness Detection Deep Dive: ISO 30107-3, APCER, BPCER, and Architecture Patterns

Liveness detection — the ability to determine whether a biometric sample was captured from a live person rather than an artefact — is the line between a face verification system that works and one that a bad actor defeats with a photograph printed from a LinkedIn profile. This guide is written for security architects and engineering leads who need to evaluate, implement, or audit liveness in production systems.

Presentation attack taxonomy showing 2D, 3D, and digital injection categories with countermeasures

The attack surface is wider than most teams think

Without liveness detection, any face verification system is vulnerable to Presentation Attacks (PAs). The attack categories that matter in 2026:

Print attacks — a high-resolution photograph held up to the camera
Replay attacks — a video of the target's face played from a second device
3D mask attacks — silicone or resin mask matching the target's facial geometry
Deepfake / synthetic face injection — AI-generated video injected directly into the video stream, bypassing the physical camera entirely
Adversarial perturbations — slight, invisible image modifications that cause liveness models to misclassify attacks as genuine

Each requires different countermeasures. A system that defeats print attacks may be fully vulnerable to replay attacks.

ISO/IEC 30107-3: the standard that matters

The authoritative framework for evaluating Presentation Attack Detection (PAD) is ISO/IEC 30107-3. It defines two primary metrics:

APCER (Attack Presentation Classification Error Rate) — the proportion of attack presentations incorrectly classified as bona fide. Lower is better.
BPCER (Bona Fide Presentation Classification Error Rate) — the proportion of genuine (live) presentations incorrectly classified as attacks. Lower is better.

These metrics trade off: lowering APCER catches more attacks but increases BPCER, rejecting more genuine users. For financial-grade KYC, typical targets are APCER ≤ 2% for high-risk attack types and BPCER ≤ 0.5%.

One subtlety: ISO 30107-3 defines multiple evaluation scenarios (S1 through S4) that differ in whether the attack instruments were known to the PAD developer. Scenario S2 — unknown attack instruments at evaluation time — is the most meaningful for real-world assessment, since attackers will not use the same tools the model was trained against. Ask vendors specifically which evaluation scenario their APCER figures come from. S1 (known attacks) figures can be far more optimistic than S2. If they can't provide an evaluation report from an accredited third-party lab, do not use them for regulated KYC.

Active vs. passive liveness

Active liveness prompts the user to perform a challenge — look left, blink twice, smile. It's effective against static print attacks but adds friction (drop-off rates 15–30% higher than passive flows), can be defeated by replay of challenge videos, and creates accessibility issues for users with motor impairments. Active liveness is being phased out of high-volume consumer flows but retains value as a step-up challenge for suspicious sessions.

Passive liveness makes a liveness determination from a single image or short unguided video capture — no challenge required. The model infers liveness from texture analysis (skin micro-textures that printed images lack), reflection patterns (screens emit light uniformly; skin has specular highlights that change with angle), depth estimation from monocular cues, and temporal coherence (micro-expressions and involuntary pulse-driven skin-tone variation). For enterprise-grade KYC at scale, passive liveness with deepfake detection is the current best practice.

The deepfake injection problem

Passive liveness models analyse captured frame content. Sophisticated attackers bypass this entirely by injecting a synthetic video upstream of the camera interface — the application never receives a real camera feed. Defending against injection attacks requires signal channels outside the video frame:

Device integrity signals — Apple DeviceCheck / Google Play Integrity verifies the app runs on a genuine unmodified device; frame metadata can detect virtual camera injection; gyroscope and accelerometer correlation can distinguish a real device held by a real person from a desktop emulator
Cryptographic frame binding — the capture SDK signs each frame with a device-bound private key at capture time; the backend verifies this signature before passing frames to the liveness model; unsigned frames are rejected before inference
Request behaviour analysis — a genuine onboarding session produces characteristic API call sequences with normal timing distributions; automated attack pipelines produce anomalous patterns — identical session durations, no inter-frame variation, unusually clean network conditions

Architecture patterns for enterprise liveness

Pattern 1 — Server-side inference (most common): Frames are captured by a hardened SDK, encrypted end-to-end, and sent to a dedicated inference endpoint. The model runs server-side, keeping weights protected and enabling central monitoring. Fit: regulated industries where audit logging and centralised control are priorities.

Pattern 2 — On-device inference (edge): A lightweight model runs locally and produces a signed liveness assertion rather than transmitting frames. The server validates the signature. Fit: low-latency requirements, or where raw biometric data must not leave the device. Caveat: on-device models are inspectable by determined attackers; model obfuscation and regular rotation are essential.

Pattern 3 — Hybrid: Server-side passive liveness runs by default. High-risk sessions trigger an active liveness step-up challenge processed server-side. This is the pattern most large financial institutions are converging on in 2026.

Capture quality gates

Poor-quality frames inflate BPCER — genuine users get rejected not because of the liveness model but because frame quality was too low for a reliable inference. Implement client-side quality checks before submission:

const quality = await captureSDK.analyzeFrame(frame);
if (quality.blur_score > 0.4) {
  promptUser("Move to better lighting and hold still");
  return;
}
if (quality.face_coverage < 0.6) {
  promptUser("Move your face closer to the camera");
  return;
}
await submitForLiveness(frame);

Audit trail requirements for regulated KYC

For regulated KYC, every liveness decision must be logged with: session ID and timestamp; liveness score (not just pass/fail); model version used; decision (pass/fail/inconclusive); any anomaly signals triggered. This log must be tamper-evident and retained for your jurisdiction's applicable period — typically 5–7 years for AML purposes.

Vendor evaluation checklist

ISO 30107-3 PAD evaluation report from an accredited lab
APCER and BPCER reported at your target operating point
Disaggregated performance across demographics (age, skin tone)
Specific deepfake / generative AI attack coverage
Virtual camera injection defence mechanism
Model update cadence and change notification SLA
Data residency — where is inference performed?
Frame retention policy post-inference

For independent evaluation or to see our ISO 30107-3 report, contact our security team.