Liveness detection, what is built, what has not cleared review, and what depends on deployment

Our passive anti-spoof model has not cleared an adversarial security review, so we do not describe anything here as anti-spoof or as certified liveness: that claim is withheld until it is earned. No accredited laboratory has evaluated any of it, see NIST/iBeta.

First, a word that means two unrelated things in our own material

"Liveness" in this document means a live human being present at capture. Elsewhere on this site, in anything about consensus, "liveness" means a distributed system continuing to make progress. They share a word and nothing else. We mention it because our own lexicon contains both, and a reader moving between the two sections will otherwise be misled.

What the check is for

An identity document check establishes that a document is genuine and that the face on it matches the face in front of the camera. It does not establish that the face in front of the camera belongs to a person who is actually there. A photograph, a screen replaying a video, or a mask can all present a face.

Liveness detection is the step that tries to close that gap, and it comes in two shapes:

• Active: the person is asked to do something in the moment: turn, blink, follow a prompt. The challenge is unpredictable, so a pre-recorded artefact cannot satisfy it.
• Passive: the system analyses the capture for the signatures of a replayed or printed image, without asking the person to do anything.

Where we actually stand on each

Active: built and exercised. The challenge-gesture gate has been built and run end to end against real device capture inside the verification flow.

Passive: exists, not cleared. The model exists. It has not cleared an adversarial security review, which is why nothing here claims it catches a printed photograph or a screen replay. NIST/iBeta is the stage after that one, and it has not started either, so there are two unfinished assessments here, not one.

The part vendors never mention: capability depends on how it is deployed

Our inference layer runs in one of three modes, and not every check is available in every mode. Voice liveness, specifically, is active only when a separate inference service is configured and reachable; in the default mode it is off.

So "does Solidus do liveness?" has a configuration-dependent answer, and a deployment that has not been set up for the inference service is running less than a deployment that has. That is true of every vendor in this space and almost none of them say it. Ask us, and ask them, which checks are active in the configuration you would actually be running.

A threshold is a choice, not a fact

The gate compares a model score against a configurable threshold. Move it up and more genuine users are rejected; move it down and more artefacts get through.

There is no correct value, only a chosen operating point, which means any figure a vendor quotes about detection is a figure at their chosen threshold, on their test set. That is precisely why an accredited laboratory result means something and a self-reported one does not.

Why there is no number on this page

We publish no detection rate, no spoof-resistance figure and no pass rate. Any number we generated would be self-graded at a threshold we chose, against data we chose, and would be the opposite of evidence.

And there is no demonstration a stranger can run. This step lives inside a real verification session; there is no standalone public demo of it. We would rather say that than point at something that does not prove what it appears to.