Skip to main content

​
What Is Liveness Detection?

Liveness detection checks whether the face (or document) in front of the camera belongs to a real person physically present at capture time, rather than a photo, a screen, or a mask.
Liveness detection is not a face matching comparison — neither 1:1 nor 1:N. It makes no comparison at all. It is a distinct analysis of the capture itself. A face can match the document perfectly and still fail liveness. See Face Matching and Biometric Data for how the two checks differ and how their results combine.

​
How It Works

Liveness detection uses trained neural networks that analyse the captured image or video stream itself — its optics, texture and digital characteristics — rather than comparing facial features between two images. Signals the models are trained on include:
  • Depth and perspective cues — how facial features fall off with distance and lighting, which differ between a real face and a flat surface such as a phone screen or a printout.
  • Skin texture and reflection — real skin scatters light differently from paper, glass, and mask materials.
  • Digital artefacts — compression noise, moiré patterns from photographing a screen, resampling from digital enlargement, and unnatural edges.
The models return a single liveness probability per capture, not a per-signal breakdown. iDenfy compares that probability against your configured threshold to produce a pass or fail. The dashboard and webhooks report the score and, where the provider supplies one, a specific failure reason — but not individual “depth” or “texture” sub-scores.

​
Types of Spoofing Attacks

Fraudsters use presentation attacks to trick biometric systems. Broadly:

​
2D Spoofing (Flat Fakes)

The most common and easiest type of attack, using flat surfaces that lack the depth of a real face.
  • Printed photos — high-resolution photographs held in front of the camera.
  • Screen replays — a photo or pre-recorded video shown on a phone, tablet, or monitor.
  • Paper masks — printed faces with eyes and mouth cut out, worn by the attacker.
  • Deepfakes shown to the camera — AI-generated video played back on a screen.

​
3D Spoofing (Physical Fakes)

More sophisticated attacks using physical objects that mimic human depth and volume: silicone or latex masks, resin busts printed from a 3D scan, and realistic mannequin heads. These are rarer and harder to detect; detection rates are meaningfully lower than for 2D attacks, and active liveness performs better against them than passive.

​
Injection Attacks

Rather than showing something to the camera, the attacker bypasses the camera entirely — feeding a synthetic or replayed stream through a virtual camera driver or an emulator. This class is covered by a separate, optional check rather than by liveness scoring itself. See Injection and virtual camera detection.

​
Face Capture Guidance

Before the liveness check runs, users go through a face capture step. The web flow gives real-time feedback while the camera is live — telling the user to fit their face in the frame, move closer, or move further away — so fewer captures are rejected for poor positioning.
This on-screen guidance is presentation only. It runs in the user’s browser to help them frame the shot; it performs no liveness or anti-spoofing analysis, and it never decides the outcome of a check.

​
Automatic Capture

Where automatic capture is active, the photo is taken once the face has been held in position for a moment, without a manual tap. Breaking the framing resets the progress. If the user cannot complete an automatic capture, a manual capture button appears after a short delay as a fallback. Removing the manual tap shortens the step and reduces motion blur in the captured image.
Automatic capture is being rolled out as an A/B test across the web flow, so only a share of your users see it — the rest keep the existing manual capture button. It doesn’t apply to sessions where users can upload an image at the capture step, and mobile SDK sessions are not included.

​
Liveness Detection Methods

Liveness runs independently on the Face step and the Document step. Each can be enabled separately, each has its own pass threshold, and each reports its own result.

​
Passive Face Liveness

Best for: maximum conversion and a seamless user experience. Passive liveness runs on the selfie the user already takes. It requires no additional action — no blinking, smiling, or head movement.
  • How it works — a single captured image is analysed and scored between 0 and 1.
  • Threshold — configurable per token; the default is 0.5. Captures scoring below it are rejected.
  • What it catches — printed photos, screen replays, and masks or heavy face coverings.
  • User experience — invisible to the user; no instructions, no extra step.

​
Passive Document Liveness

The same approach applied to the document image, to confirm the user is holding the physical document rather than a copy. Two spoof detection pipelines are available, plus an optional portrait check:
  • Screen replay — the document was photographed from a screen. Reported as the suspicion reason DOC_MOBILE_PHOTO.
  • Printed copy — the document is a printout or photocopy. Reported as DOC_PRINT_SPOOFED.
  • Portrait substitution (optional) — the portrait area has been replaced or overlaid. Reported as the fraud tag PORTRAIT_SUBSTITUTION.
Each pipeline has its own strictness setting (soft, regular, or hard), letting you trade false rejections against detection rate per document type.
Printed copy detection is automatically skipped for document types that are legitimately paper-based, since a genuine paper document would otherwise be flagged. Screen replay detection is likewise skipped for a small set of document types where it is unreliable.

​
Active Liveness (3D)

Best for: higher-risk flows where an extra user interaction is acceptable. Active liveness replaces the standard static selfie with a short guided capture, producing a 3D face map rather than a single flat image.
  • How it works — the user frames their face in an on-screen oval, confirms they are ready, and moves closer to the camera while the SDK captures. On-screen feedback guides framing, distance, head angle, lighting and steadiness throughout.
  • Requirements shown to the user — look straight ahead, neutral expression with no smiling, no dark glasses, adequate lighting.
  • Security — the depth information from the movement is what raises the bar against screen replays, deepfake playback and masks, relative to a single still image.
  • User experience — adds roughly one extra step, with an instructional screen beforehand.
Active liveness is a guided distance-and-framing capture, not a randomised challenge-response. Users are not asked to blink, smile, turn their head to a randomised sequence, or read out digits.
Active 3D liveness and passive face liveness are mutually exclusive. Enabling active liveness replaces the standard face capture step; passive face liveness is not additionally applied to that session.

​
Injection and Virtual Camera Detection

An optional check, enabled separately and requiring passive face liveness to be on, targeting attacks that bypass the physical camera: virtual camera drivers, injected streams, and deepfakes fed directly into the capture pipeline. Alongside it, iDenfy applies its own heuristics:
  • Camera device screening — known virtual camera and screen-capture software is detected from the reported camera device, with a whitelist for legitimate virtualisation environments.
  • Frame border analysis — letterboxing and uniform borders characteristic of a re-broadcast stream.
  • Duplicate capture detection (face authentication) — a selfie that is near-identical to one submitted previously in the same account is rejected as a replay.
Detections surface as the fraud tag VIRTUAL_CAMERA.
Where the environment looks untrusted but face liveness itself passes, the session is tagged rather than rejected — it receives the UNTRUSTED_ENVIRONMENT risk tag for your review, and the verification continues.

​
Results and Rejection Reasons

Face liveness failures are returned with a specific reason where the model can supply one, and the end user sees matching guidance on how to retry: Document liveness failures return the poor-quality reasons (document not found, cropped, multiple documents, over-compressed image, poor exposure) alongside the spoof reasons listed above. Where results appear:
  • Dashboard — passive face liveness, passive document liveness and 3D liveness appear as separate checks, each with a pass/fail and a score out of 100.
  • Webhooks — suspicionReasons, fraudTags, documentValidity / manualDocument (DOC_SPOOF_DETECTED), and faceMatchResult (FACE_UNCERTAIN, FAKE_FACE). Face authentication sessions additionally return fail_reason and risk_tags.
Blur and glare are handled by a separate image quality check, not by liveness. A capture can be rejected for quality without ever reaching the liveness models.

​
Why Verification Might Be Rejected

Liveness detection is probabilistic. Genuine users are occasionally rejected, and the following factors make that more likely.Environmental factors:
  • Lighting — strong backlighting (silhouette effect) or heavy shadows obscure the facial detail the models rely on.
  • Image quality — blur, poor focus, or camera movement.
  • Positioning — extreme angles, or holding the device far enough away that the face occupies too few pixels.
Device and camera settings:
  • Beauty mode and skin-smoothing filters — enabled by default on many phones. They strip natural skin texture, which pushes a genuine face toward a spoof score. Advise users to disable them.
  • Camera quality — older, low-resolution cameras may not capture enough detail.
  • Virtualised or screen-sharing environments — capture through remote desktop, screen sharing, or a virtual camera driver is flagged as untrusted and may be tagged or rejected regardless of image quality.
Tuning: if false rejections are too frequent for your user base, lower the liveness threshold or relax the document pipeline strictness before disabling the check outright.