Liveness detection exists to answer one question at onboarding: is there a real person in front of this camera right now, or is this a photograph, a screen, a mask or a generated video. Almost every deployed answer to that question involves enrolling a face — computing a biometric template and storing it so it can be compared later.
There is a different way to get the signal, and it does not require keeping a face at all. A live human body has a pulse, and the pulse is visible in a video of skin as a periodic colour change too small for a person to notice. Measuring it is called remote photoplethysmography, or rPPG, and it turns liveness into a signal-processing problem rather than a biometric one.
This is how it works, what it costs, and where it honestly falls short.
Why challenge-response ages badly
The familiar approach is active: blink, turn your head, follow the dot, smile. It has two problems that have gotten worse rather than better.
The first is that users dislike it. Every added instruction is an abandonment opportunity in the highest-value moment of an onboarding flow, and the instructions are hardest for exactly the people least able to complete them.
The second is that the difficulty of faking a specified motion has collapsed. A challenge that can be described in a sentence can be produced by a video generator, and a system that accepts a rendered head turn is measuring compliance with an instruction rather than presence of a person.
Passive methods measure something the subject does not perform. A pulse is not a gesture that can be complied with; it is either present in the signal or it is not.
The pulse is in the pixels
Each cardiac cycle pushes blood through the capillary bed near the skin surface. Haemoglobin absorbs light unevenly across wavelengths, so as blood volume rises and falls, the colour reflected from skin shifts — by a fraction of one percent, far below perception, but well within what a camera sensor records.
Recovering it takes a specific chain:
- Region selection — track patches of skin that are well perfused and reasonably stable, typically the forehead and both cheeks, and average colour over each region per frame.
- Projection — combine the colour channels using a method built to cancel motion-induced intensity change while preserving the blood-volume component. Plane-orthogonal-to-skin and chrominance-based projections are the two standard families.
- Resampling — put the samples on a uniform time grid, because phone cameras do not deliver a constant frame interval and spectral analysis assumes one.
- Band-pass filtering — keep only the frequency range a human heart rate can occupy, roughly 0.7 Hz to 4 Hz, which is about 42 to 240 beats per minute.
- Spectral analysis — find the dominant peak inside that band and measure how far it stands above the surrounding noise floor.
What comes out is a frequency and a signal-to-noise ratio: an estimated heart rate, and a measure of how confident the estimate is.
The cross-region check is what makes it hard to fake
A single strong peak in the plausible band is not sufficient evidence. Noise is broadband, and a five-second window has coarse frequency resolution, so a spurious peak somewhere in a wide band is not a rare event. Any flicker with a periodic component — a display refresh, an overhead light, a rhythmic motion — can produce one.
The discriminating test is agreement. On a real face, the forehead and both cheeks are perfused by the same heart, so their independently estimated rates cluster. On a photograph, a screen or a mask, whatever periodic content exists is not driven by a shared physiological source, and the per-region estimates scatter.
So the decision is built from the spread across regions rather than from the strength of any one:
- No peak in any region — a flat signal. A print, a still image or an unperfused surface. This is a spoof, and it is the easiest case.
- Peaks that disagree widely — periodic content without a shared source. Not evidence of a person.
- Peaks that agree, with the pulse band standing clear of the noise — consistent with a live face.
- Anything in between — inconclusive, and it must be allowed to say so.
The tolerance for “agree” has to be set carefully. Too tight and a genuine face where one region lands a frequency bin off gets rejected. Too loose and noise clusters pass. It sits above the frequency resolution of the analysis window and well below the scatter that non-pulse signals produce — we do not publish our tuned value, because a threshold is an attacker's target rather than an integrator's parameter.
Inconclusive is a verdict, not an error
This is the design decision that matters most operationally, and the one most systems get wrong.
rPPG has real preconditions. It needs enough usable frames, an effective frame rate high enough to resolve the band, a face that stays in view, and lighting that does not saturate the skin regions. Any of those can fail for reasons that have nothing to do with fraud: a slow phone, a dark room, a moving train.
A binary system has to map those cases onto live or spoof, and both mappings are bad. Calling them live opens a trivial bypass — degrade the capture until the check gives up. Calling them spoof rejects legitimate people for owning an older handset.
The third verdict fixes it, provided it carries a machine-readable reason:
| Reason | What actually happened | Right next step |
|---|---|---|
| Insufficient samples | The usable capture window was too short | Retry with guidance to hold still |
| Low effective frame rate | The device could not sustain the needed cadence | Retry, or route to an alternative check |
| Weak pulse signal | A peak exists but does not stand clear of noise | Retry once, then escalate to review |
| No pulse | Flat signal across every region | Treat as a presentation attack |
Failing closed to inconclusive rather than to a decision is the correct posture. It converts an ambiguous physical measurement into a routing decision the flow can handle — retry, alternative evidence or human review — instead of forcing a verdict the signal does not support.
Anti-replay: the sample must belong to a moment
Any video-based check faces replay. A capture that passed once is a capture that can be submitted again, and no amount of signal quality distinguishes an excellent recording from an excellent live subject if the transport accepts arbitrary bytes.
The mitigation is structural rather than analytical. The server issues a session before capture begins, with a short lifetime. Samples are bound to that session and accepted only inside its window. A submission arriving against an expired or already-consumed session is rejected regardless of how good the signal looks.
The session lifetime is a genuine trade-off: long enough for a person to complete the capture on a slow connection, short enough that a replay window is not useful. Whatever it is, the session issuance, binding and expiry all belong in the evidence record, because “this capture happened within this window” is the claim being made.
What you give up by not enrolling a face
The honest limitation. Pulse-based liveness answers presence — is a live person here. It does not answer identity — is this the person on the document.
Those are separable, and separating them is often the right architecture. Presence is checked without retaining anything biometric. Identity, when the process needs it, is established by comparing the captured face against the identity document that was submitted in the same case — a one-to-one comparison within a single case, which is a much narrower operation than maintaining an enrolled gallery.
What you cannot do without a stored template is one-to-many search: asking whether this person appears anywhere in a population of previous applicants. That is a genuine capability, it is genuinely useful against organised fraud rings, and it requires building the face database that this design exists to avoid. Which way that trades depends on the fraud you actually face and the retention posture you can defend, and it is a decision for the risk owner rather than the architect.
What to require from any liveness vendor
Whether you build this or buy it, the questions are the same:
- What is retained — frames, a derived template, or only a verdict with reason codes and metrics.
- Is there a third verdict — and does it carry a reason code your flow can route on.
- What are the capture preconditions — stated as numbers, so an integrator can predict which devices will fail.
- How is replay prevented — and is the binding verifiable after the fact from the evidence record.
- What does the evidence record contain — enough to reconstruct the decision, without storing more of a person than the decision needed.
The last one is the summary of the whole approach. A liveness check should leave behind a defensible record of a decision, not a copy of a face. Measuring the pulse instead of enrolling the person is one way to make those the same thing.