Back to Insights
EXPLAINERAUGUST 27, 202612 min read

A Photograph Has No Pulse: How Liveness Detection Decides a Human Is Actually There

Sigilith Research

Institutional AI governance & accountability

A note on scope. This is an explainer about a field, written from public standards and published literature. It describes attacks and countermeasure families (the taxonomy any serious practitioner works from) and deliberately describes no production system's mechanics, including our own. An article about anti-spoofing that disclosed its author's thresholds and logic would be a gift to exactly the people it is about.

The short version

  1. A face is not a secret. Most people's faces are already public: posted, tagged, scraped, resharable at will. A system that only matches faces authenticates the picture, not the person. The prior question, the one liveness detection exists to answer, is whether a live human being was in front of the camera at all.

  2. The attacks are a ladder, not a list. A printed photograph, a replayed video, a silicone mask, a deepfake on a screen, and a stream injected behind the camera's back are not five versions of one trick. Each defeats a different check, each betrays itself differently, and the defense that catches one is routinely blind to the next.

  3. "99% accurate" is not a liveness result. The governing standard, ISO/IEC 30107, measures two error rates that pull against each other (attacks accepted, and genuine people rejected), reported per species of attack. A vendor quoting one number without the other, or an average without the worst case, has answered neither question.

1. A camera will report whatever it is shown

Regulated onboarding used to begin at a desk. A person walked in, a person looked at them, and whatever else went wrong in the process, one fact was never in doubt: somebody was there.

Electronic KYC moved that encounter onto a phone camera, and the camera turned out to be a peculiar kind of witness. It is precise, tireless, and completely credulous. It will report a live customer, a photograph of that customer, a video of that customer played on a second screen, and a latex reconstruction of that customer's face with exactly the same confidence, because reporting what it is shown is all a camera does.

The standards community calls the exploitation of this credulity a presentation attack: a presentation to the biometric capture device made with the goal of interfering with the system's operation (usually to impersonate someone, occasionally to avoid being recognized at all). The thing presented, whether paper or screen or silicone, is a presentation attack instrument, and the vocabulary comes from ISO/IEC 30107-1, the framework standard that gave the field a common language.

The attacks form a ladder, ordered roughly by effort:

  • Print attacks. A photograph, printed and held to the camera. The floor of the ladder, nearly free, and still attempted at scale because it still sometimes works.
  • Replay attacks. A real video of the real victim, played into the camera from another device. Motion, blinking, even a compliant head-turn are all present: the victim once really performed them.
  • Mask attacks. From printed paper masks to silicone and latex work with genuine depth. These exist to defeat systems that learned to catch flat things.
  • Deepfakes. A swapped or wholly synthetic face, animated convincingly in real time by tooling that has collapsed in cost from research project to free download. Presented on a display, a deepfake is a replay attack with better content; its more dangerous form comes one rung higher.
  • Injection attacks. The attacker stops showing things to the camera and replaces the camera: a virtual camera driver, a tampered application, or a hardware capture card feeds footage directly into the capture pipeline. The sensor never sees the attack, which places injection formally outside the presentation-attack framework, a gap the industry has had to organize itself around and one this article returns to below.
Figure 1The attack ladder, and which countermeasure family catches each rung
Caught byLight challengeMaterial & texturePhysiologyDisplay forensicsDevice & network

  • A virtual camera, tampered client, or hardware capture card feeds footage past the sensor: the camera never sees the attack, which places it outside classic PAD entirely (ISO/IEC 30107 scopes itself to attacks at the sensor). Defense shifts to the integrity of the capture pipeline itself: device and channel attestation, tamper detection, and treating the path from sensor to server as part of the attack surface.

Attack classes and countermeasure pairings are drawn from the public literature (ENISA 2022; Yu et al. 2022): families, not mechanisms, and no vendor’s implementation. Select any rung for why it fails. The reading that matters: no family covers every rung, and a fake that survives one family tends to fail another. That is the argument for layering, and for treating any single check as a partial answer.

The European Union Agency for Cybersecurity (ENISA), surveying remote identity proofing in 2022, classified essentially this ladder (photo, replay, mask, deepfake) and paired each rung with countermeasures. The pairing is the important part. There is no single test for "fake"; there are families of tests, each aimed at a different way of being fake.

2. What defends: the five countermeasure families

The public literature (ENISA's analysis, and comprehensive academic surveys of face anti-spoofing) sorts the defenses into a handful of recurring families.

Active challenge and illumination. The system introduces something fresh at capture time and checks that the scene responds. The early form asked the user to perform (blink, smile, turn your head), which is cheap but double-edged: a recorded victim has already performed, and a puppeted deepfake can perform on demand, while every real customer pays the friction. The stronger form challenges the physics rather than the person: a pattern of light, issued at capture and never reused, must return from the scene the way light actually returns from a three-dimensional, skin-covered face. A recording cannot answer a challenge that did not exist when it was made. Freshness is the point: it binds the capture to this moment, in front of this camera.

Trained anti-spoof networks. Models trained on genuine and attack imagery learn the differences people cannot articulate: the texture of skin versus the texture of paper, the way living tissue scatters light beneath its surface where silicone and print reflect from it, the frequency artifacts that betray a reproduction. This is the family NIST evaluates in its FATE PAD track (passive, software-only detection on ordinary 2D imagery), precisely because it requires no special hardware and no user cooperation.

Physiological signals. A live face is not a surface; it is perfused tissue. Since a 2008 Optics Express paper showed that ordinary ambient-light video of skin carries the cardiac pulse as a minute periodic color change, remote photoplethysmography has offered PAD a signal no photograph or mask possesses: blood. A high-fidelity replay of genuine video can still carry the victim's recorded pulse, which is one reason this family corroborates rather than decides. Micro-motion, the involuntary, sub-perceptual movement of a living head, belongs to the same family.

Display and recapture forensics. When the attack instrument is a screen, the screen itself testifies: moiré interference between its pixel grid and the camera's sensor, refresh and rolling-shutter artifacts, bezels and reflections, the double compression of footage that has been through a codec twice. This family catches the replay and the displayed deepfake not by judging the face, which may be flawless, but by noticing the medium.

Device and network intelligence. The capture does not happen in a vacuum. Emulators, virtual camera drivers, tampered applications, impossible device histories, and the tell-tale correlation of many "different" applicants sharing one device or one network are all signals about the session rather than the face, and they are the primary defense against attacks the camera never sees.

The reading that matters is the shape of the whole table: every family has a blind spot. A texture model can be fooled by a good enough screen; display forensics say nothing about a mask; a challenge means little if the pipeline that reports the answer is compromised. The field's actual defense is the layering: a fake that survives one family fails another, and building an instrument that passes all of them simultaneously is a different order of problem from beating any single check.

3. The standard: ISO/IEC 30107 and its two error rates

Claims in this market are loud, so it matters that the field has a measuring instrument. It is ISO/IEC 30107 (Part 1 the framework and vocabulary, Part 3 the testing and reporting methodology, Part 4 a profile for mobile devices), and its most useful contribution is two error rates with unlovely names:

  • APCER, the attack presentation classification error rate: the proportion of attacks, of a given instrument species, that the system wrongly accepts as genuine.
  • BPCER, the bona fide presentation classification error rate: the proportion of genuine people the system wrongly rejects as attacks.

Three properties of this pair do most of the work of separating serious claims from marketing.

First, the two rates pull against each other. Tighten a system until no attack survives and it starts rejecting real customers; loosen it until every real customer passes and attacks begin to slip through. Where a deployment sits on that dial is a policy decision about which error costs more, which is why a serious PAD result is always the pair, quoted together, and a lone "accuracy" figure is the sound of half a trade-off.

Figure 2Two error rates, one dial. Tighten either and the other answers
APCERAttacks accepted as genuine6.7%

the fraud that gets through

BPCERReal people rejected as attacks6.7%

the customers turned away

Where a deployment sits on this dial is a policy decision about which error costs more. That is why a serious PAD result is always the pair, quoted together, per attack species.

Illustrative geometry only: the curves are drawn to show the shape of the trade-off and are measured from no system, ours included. ISO/IEC 30107-3 defines APCER per species of attack instrument, reported alongside BPCER; the number that describes a system is the pair at its worst species, and a vendor quoting a single “accuracy” figure has answered neither question.

Second, APCER is reported per attack species. An average across species lets a strong performance against cheap printouts launder a weakness against silicone masks. The number that describes a system is its worst species, and 30107-3's per-species discipline exists to stop the average from hiding it. Research papers often compress the pair into ACER, a simple average of the two: convenient for ranking algorithms, and exactly the compression the standard's reporting rules exist to resist.

Third, the trade-off lands on real people. In regulated onboarding the bona fide error is not an abstraction: a false rejection is a person denied an account, often on modest hardware in imperfect light, and often the first account that person has ever opened. A system tuned as if only APCER mattered exports its caution as exclusion. This is why BPCER deserves equal billing, and why the standard gives it equal billing.

Around the standard sits an evaluation ecosystem. NIST's FATE PAD track tests passive detection algorithms on sequestered data the developers never see; its 2023 report covered 82 algorithms across impersonation and evasion scenarios, and its headline finding was bracing: performance varies enormously, and no algorithm dominated across all attack types. The FIDO Alliance runs accredited-laboratory certification of biometric components, testing against cataloged attack species at escalating levels of attacker effort, with live subjects. Certification against these regimes is meaningful. And bounded. It certifies performance against the species tested, at the effort level tested, on the day tested. It is a floor, not a ceiling, and it says nothing at all about the attack in the next section.

4. Injection: the attack the camera never sees

ISO/IEC 30107 scopes itself to attacks at the sensor: things physically presented to a camera. An injection attack declines to participate. By feeding footage into the capture pipeline through a virtual camera, a modified client, or a hardware interception device, it attacks the system at a layer the PAD standard was never written to cover, with content (very often a real-time deepfake) that no longer needs to survive being photographed off a screen.

This is the structural reason "we are PAD-certified" cannot end a due-diligence conversation. The certificate describes the guarded door; injection is the corridor around it. ENISA's remote-identity-proofing work flags precisely this migration, and the defensive weight shifts accordingly: to the integrity of the capture pipeline itself (is this a real camera on a real device running an untampered client?), to attestation and device intelligence, and to challenge designs whose correct answer depends on physical optics unfolding in front of a real sensor at capture time, which an injected stream, rendered before the challenge existed, struggles to fake on schedule. None of these defenses is exotic or secret as a category. As with everything else in this field, the security lives in the execution, not the concept.

5. Why a human stays in the loop

Everything above describes machinery, and the machinery's own standard is a reminder that it errs in both directions at once. Neither error rate is ever zero. Somewhere between the clear pass and the clear attack is a band of sessions (bad light, an odd device, a borderline signal, a genuinely novel instrument) where the honest machine output is not a verdict but an ambiguity.

What happens to that band is a governance question, not a computer-vision question. A system that quietly resolves its own ambiguities is making institutional decisions nobody can later account for; in regulated onboarding, where a rejection is an adverse action against an identifiable person, "the model was not sure" is not an explanation a regulator, an auditor, or the rejected customer will accept. The defensible pattern is escalation: the ambiguous session goes to a person with authority, the evidence assembled in front of them, and the resolution is recorded (who decided, on what basis, when). The machine's error rates describe frames. An institution is judged on decisions, and decisions need deciders.

6. Six questions to ask any liveness vendor

The field's public structure (the ladder, the families, the standard) compresses into a short due-diligence list:

  1. Which attack species were tested, at what level of attacker effort, and does the list include masks and displayed deepfakes, or end at printouts?
  2. What is APCER per species (worst species, not the average), and at what BPCER? One number without the other, or an average without the worst case, is half an answer.
  3. Who ran the test? Accredited laboratory or sequestered NIST-style evaluation is one kind of claim; a self-reported benchmark is another.
  4. What answers injection, which sits outside the PAD standard's scope: capture-pipeline integrity, device attestation, anything binding the capture to a real sensor in real time?
  5. Where do the ambiguous sessions go? If the answer implies the machine resolves everything, ask who is accountable for the sessions it resolves wrongly.
  6. What record survives? If a rejection is challenged a year from now, can the vendor, can you, produce what was captured, what fired, and who decided?

7. Where this sits in our own work

Our entry in this field is Sigilith Sentry, and consistent with the scope note at the top, what we will say here is what we say publicly: one capture, an active light challenge, analysis that happens server-side rather than on the device, escalation of ambiguous sessions to a named human officer, and a sealed, tamper-evident record of every verdict. It establishes presence, not identity: no documents read, no names stored. How it does these things is not in this article, on purpose. In this field, an explainer that answered that question would be answering it for the wrong audience.

The questions in section 6, though, we commend without reservation. Including, and especially, when the vendor being asked is us.

Sources

Also Applicable To

Public Sector
Critical Infrastructure
Telecommunications
Sigilith

Evidence infrastructure for consequential AI decisions: records built to outlive the systems that made them.

Est. in the decision path

{ CORRESPONDENCE }

syed@sigilith.com

Vendor-risk questionnaires and security reviews are welcome with a first message.

LinkedIn

© 2026 Sigilith, Inc. · A Delaware corporation. All rights reserved.

Set in Instrument Serif · Inter · IBM Plex Mono