Liveness Detection: Telling Real Faces From Presentation Attacks

A selfie proves someone submitted a face. It does not prove that face belongs to a live person sitting in front of the camera. An attacker holding up a printed photo, replaying a video, or wearing a silicone mask can pass a naive face match while defeating the entire purpose of the check. Liveness detection — formally, Presentation Attack Detection (PAD) — closes that gap by asking a narrower question: is this a real, present human?

The Attacks You Are Defending Against

Presentation attacks fall into recognizable categories, and defenses should map to each one:

• Print attacks: a photo of the target printed on paper or displayed on a second screen. Cheap, common, and effective against systems that only compare pixels.
• Replay attacks: a recorded video of the target played back to the camera, sometimes lifted from social media.
• 3D masks: paper cutouts, latex, or resin masks that add depth cues a flat photo lacks.
• Deepfake and injection attacks: synthetic video fed directly into the camera stream, bypassing the physical sensor entirely. This is the fastest-growing category and the hardest to catch with pixel analysis alone.

The ISO/IEC 30107-3 standard defines how PAD systems are tested, reporting an Attack Presentation Classification Error Rate (APCER) against a Bona Fide Presentation Classification Error Rate (BPCER). A vendor claiming "liveness" without publishing those numbers is telling you very little.

Passive Versus Active Signals

Liveness checks split into two families. Active methods ask the user to act: turn your head, blink, follow a dot, or read a random number aloud. The challenge is randomized so a pre-recorded video cannot satisfy it. Active checks are robust against replay but add friction and take several seconds.

Passive methods analyze a single frame or short clip without instructions. They read micro-texture, skin reflectance, moiré patterns from screens, specular highlights in the eyes, and subtle color shifts from blood flow. Passive liveness finishes in under a second and users often do not notice it happening, which lowers abandonment.

Many production systems combine the two: passive analysis by default, escalating to an active challenge only when the passive score is ambiguous or the session risk is elevated. That pattern keeps the median user fast while reserving friction for the sessions that warrant it.

Why Injection Attacks Change the Calculus

Print and replay attacks arrive through the camera, so a camera-facing model can inspect them. Injection attacks skip the lens: a virtual camera driver or a tampered app feeds frames straight into the capture pipeline. No amount of texture analysis helps if the "camera" is software.

Defending against injection means verifying the capture path, not just the image. Signals include hardware attestation, checks for virtual camera drivers, session integrity tokens, and confirming that pixel data carries the sensor noise a genuine camera produces. In a chat-based flow, this pairs naturally with device intelligence — the same session already yields device, network, and behavioral signals that raise or lower the confidence threshold for liveness.

Deploying Liveness Without Hoarding Biometrics

Liveness runs on a biometric — a face — which brings data-protection obligations under GDPR Article 9 and equivalents. Practical privacy engineering reduces exposure:

• Compute the liveness decision and discard the raw video; keep the pass/fail result and a score, not the footage.
• Apply data minimization: capture only the frames the model needs, not a continuous recording.
• Set configurable retention so biometric artifacts expire on a defined schedule rather than living indefinitely.
• Log the decision for your audit trail without storing the underlying biometric where a shorter horizon suffices.

Done well, liveness detection stops the majority of presentation attacks while the person barely notices — and while your systems hold far less sensitive data than a full video archive would demand. For general guidance on testing standards, review ISO/IEC 30107-3. This article is general information, not legal advice.