Liveness detection and deepfakes: what actually stops a fake face

What is liveness detection?

Liveness detection proves that a real, live person is in front of the camera during an identity verification, rather than a photo, a mask, a screen replay or a synthetic video. Against deepfakes it has to stop two different attacks: presentation attacks, which hold a fake up to the camera, and injection attacks, which feed synthetic video straight into the stream and never meet a camera at all.

The face is rarely where verifications fail. In video identity verification sessions on Dotfile over the past year, about 1 in 630 failed the face liveness and spoofing control. 1 in 24 failed because the data on the document did not match what the customer had declared, 26 times as often. A 1 in 630 failure rate measures what was caught, not what got through. So test your provider on injection, then put the rest of your effort where the volume is.

How does liveness detection work?

A liveness check runs inside the selfie step of an identity verification, alongside the face match against the document photo.

• Active liveness asks the person to do something: turn the head, follow a dot, read numbers aloud. It is harder to fake with a still image and costs some completion.
• Passive liveness analyses the captured video or image without any instruction: depth, texture, reflections, micro-movements, the signature of a screen or a print. It is invisible to the user.
• Face match compares the live face with the photo on the document. It answers a different question: liveness says someone is there, face match says it is the right someone.

Most modern providers combine passive liveness with a short video and a face match, and add document checks in the same session. Our guide to identity verification services covers how to choose one, and our explainer on how identity verification works covers the full flow.

What is the difference between a presentation attack, an injection attack and a deepfake?

A presentation attack puts an artefact in front of the camera: a printed photo, a phone screen playing a video, a silicone mask. Presentation attack detection (PAD) is tested under ISO/IEC 30107-3.

An injection attack bypasses the camera. A virtual camera driver, an emulator or a hooked app sends pre-recorded or generated video into the verification flow as if it came from the lens. The capture looks perfect because nothing was captured. Detection relies on device and stream integrity: is this a real camera, on a real device, in real time?

A deepfake is the content, not the route. The EU AI Act defines it as "AI-generated or manipulated image, audio or video content that resembles existing persons [...] and would falsely appear to a person to be authentic or truthful" (Article 3(60), Regulation (EU) 2024/1689). A face-swap can be presented on a screen or, far more effectively, injected.

FinCEN's alert on deepfake media (FIN-2024-Alert004, 13 November 2024) lists the red flags that matter in practice: a customer who "uses a third-party webcam plugin during a live verification check", a photo that is internally inconsistent or inconsistent with the date of birth and an identity photo that a reverse-image search matches to a gallery of AI-generated faces.

Is liveness detection required by regulation?

In the EU, for unattended remote onboarding by banks and financial institutions, yes. The EBA Guidelines on remote customer onboarding (EBA/GL/2022/15), applicable since 2 October 2023, expect institutions using unattended solutions to "perform liveness detection verifications" (paragraph 41(c)), to make sure the photo or video "is taken at the time the customer is performing the verification process" (41(b)) and to use "strong and reliable algorithms" for the face match (41(d)). When the evidence is too poor to be conclusive, the session should be interrupted and restarted or redirected to a face-to-face check (paragraph 40).

The AMLR, which applies from 10 July 2027, does not name liveness. It requires an identity document or an eID meeting the eIDAS levels "substantial" or "high" (Article 22(6), Regulation (EU) 2024/1624), and the reliability of a remote document check depends on proving the holder was there.

The AI Act treats the use case lightly: biometric verification "the sole purpose of which is to confirm that a specific natural person is the person he or she claims to be" is excluded from the high-risk biometric identification category (Annex III, point 1(a), Regulation (EU) 2024/1689).

How do you test a liveness provider against deepfakes?

Ask five questions, and ask for evidence rather than adjectives.

1. Which presentation attacks has it been tested against, by whom, to which level? An independent ISO/IEC 30107-3 evaluation report, not a badge.
2. How does it detect injection? Virtual cameras, emulators, rooted devices, browser capture on desktop. If the answer is only about the face, it does not.
3. What happens on desktop? Many flows move the user to a phone, where camera integrity is easier to establish. Know which path your users take.
4. What reason codes come back? "Rejected" is useless to an analyst. "Face authenticity failed" and "document data mismatch" lead to different actions.
5. What is the completion cost? Every active challenge loses people. Measure completion on your own users before and after.

Worked example: a face-swap at 2 a.m.

A fictional crypto platform receives an account application for "Daniel", 34, at 2 a.m. The identity verification session runs on a desktop browser. The document is a genuine-looking passport; the selfie video is fluid and the face matches the passport photo.

The provider rejects the session on liveness and spoofing. The reason codes say the video stream came from a virtual camera and the face shows blending artefacts at the jawline. The platform's analyst sees two more signals in the case: the form gives a date of birth in 1992 while the passport MRZ says 1974, and the same passport number appears on a rejected application from a week earlier. The face was fake, and the data would have caught it anyway.

What the data says about liveness and face checks

Based on video identity verification sessions run on Dotfile over the past year in which the provider returned a face result; aggregates only.

• About 1 in 630 (0.16%) failed the face liveness and spoofing control.
• 0.07% failed the face match against the document photo.
• About 1 in 24 (4.2%) failed the comparison between the document and the data the customer had declared.

Frequently asked questions

What does "liveness complete" mean?

In most identity verification flows, it means the person finished the liveness step: the video was captured and sent for analysis. It is not a result. The check then returns approved, rejected or needs review once the provider has analysed the face, the document and the data.

What is document liveness detection?

It checks that the identity document is physically in front of the camera, not a photocopy, a printout or an image on a screen. EBA/GL/2022/15 paragraph 33 asks you to check that a reproduction "has not been displayed on a screen".

Can deepfakes beat liveness detection?

A face-swap shown to a camera rarely beats a good presentation attack detector. Injected deepfakes are the real risk, which is why device and stream integrity matter as much as the face.

Is passive liveness enough?

For most onboarding, passive liveness with a short video and a face match is the right trade-off. Higher-risk flows can add an active challenge or an agent-led video session.

How is liveness different from a face match?

Liveness proves someone is physically there. Face match proves it is the same person as on the document. A verification needs both.

Where Dotfile fits

Dotfile's liveness ID verification check runs on Veriff, Checkout or Onfido and returns results by control: data consistency, compromised document, image integrity, visual authenticity and facial similarity, which covers face match, liveness and spoofing detection. Checkout's PVID-certified VideoCertified product and IDnow VideoIdent cover the cases where a regulator expects more. Extracted data is compared with the case, and you choose whether a provider's decision approves or rejects automatically. For the document side, see our document check and forensics guide.