> For the complete documentation index, see [llms.txt](https://docs.1kosmos.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.1kosmos.com/identity-verification/verification-methods/biometric-and-liveness.md).

# Biometric and Liveness

***

### Overview

A document scan proves the document is real. A biometric and liveness check proves the **person holding it** is real, present, and the same person pictured on the ID.

1Kosmos runs both as a single, passive step. The user is asked for one selfie. Behind the scenes:

1. **Face detection** locates and aligns the face.
2. **Passive liveness** scores the capture for signs of a printed photo, screen replay, deepfake, or 3D mask.
3. **Face match** compares the live capture against the portrait extracted from the document.

There are no blink prompts, head turns, or "say a sentence" challenges by default. The whole step takes 3–5 seconds.

### Liveness levels

A flow's **Liveness Level** sets how aggressive the passive-liveness model is. You're trading off false rejections (turning away genuine users) against false acceptances (letting a spoof through).

| Level        | False reject | False accept | When to use                                                                                                                |
| ------------ | ------------ | ------------ | -------------------------------------------------------------------------------------------------------------------------- |
| **Soft**     | Lowest       | Highest      | Re-verification, recovery flows, anywhere a genuine user struggling to capture is a worse outcome than a borderline spoof. |
| **Regular**  | Balanced     | Balanced     | Default. Right for the vast majority of consumer KYC and SaaS onboarding.                                                  |
| **Hardened** | Highest      | Lowest       | High-value accounts, financial onboarding, situations where you'd rather lose a user than admit a spoof.                   |

The level is set per flow under **Step 2: Face Liveness Settings**.

{% hint style="info" %}
**You can switch levels per flow, not per session.** If your risk model needs different strictness for different user segments — say, soft for re-verification and hardened for first-time onboarding — create two flows and pick the right one when generating the session.&#x20;
{% endhint %}

### Face matching score

After liveness, the live selfie is compared to the portrait on the document. The result is a **similarity score** between 0.0 and 1.0.

* The flow sets a **threshold** — the minimum score required to pass. Default is 0.50. The recommended range is 0.50–0.80.
* Lowering the threshold accepts more genuine variations (lighting, age, glasses) at the cost of accepting more lookalikes.
* Raising the threshold tightens the match. Above 0.85, expect to start failing legitimate users beards regrown, weight changes, older document photos.

The threshold is set per flow on the same screen as liveness level.

### What the user sees

{% stepper %}
{% step %}
**Permission prompt**

The browser asks for camera permission. 1Kosmos checks the camera meets the minimum&#x20;
{% endstep %}

{% step %}
**Begin selfie**

The UI displays an oval frame and a single CTA.
{% endstep %}

{% step %}
**Position and capture**

The user centers their face in the oval. Auto-capture fires when alignment and quality thresholds are met. No instructions to blink or move.
{% endstep %}

{% step %}
**Result**

A success screen appears. The user has no insight into the score only the verdict  to preserve robustness against tuning by adversaries.
{% endstep %}
{% endstepper %}

### Anti-spoofing coverage

The passive-liveness model is trained against the following Presentation Attack Instrument (PAI) categories:

* **Print attacks** — printed photos, magazine cutouts, paper masks.
* **Replay attacks** — phone, tablet, and laptop screen replays of a still photo or video.
* **3D mask attacks** — silicone, latex, and paper masks.
* **Deepfake attacks** — synthetic faces injected via virtual camera drivers.
* **Cut-out attacks** — eye- and mouth-hole cutouts in printed photos.

1Kosmos's PAD (Presentation Attack Detection) is iBeta Level 2 certified to ISO 30107-3.

{% hint style="info" %}
**Injection attack defense.** Beyond what's visible in the camera frame, 1Kosmos detects attempts to inject pre-recorded video through virtual camera drivers — the most common deepfake delivery vector in 2026. This runs on every session at no extra configuration.
{% endhint %}

### Edge cases worth knowing

* **Lighting.** Backlit and very dim captures get a retry prompt. Liveness models cope with normal indoor lighting; harsh sun directly behind the user is a common failure case.
* **Children.** Face match is less reliable on subjects under 13. The face-match threshold should be lowered, or the use case routed to a manual-review queue.
* **Identical twins.** 1Kosmos's models cannot reliably distinguish identical twins; if your use case must, pair the face match with an additional knowledge-based or biometric factor.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.1kosmos.com/identity-verification/verification-methods/biometric-and-liveness.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
