Deepfakes and Injection Attacks in ID Verification: How to Defend

Why deepfakes are a KYC problem, not just a media problem

Remote onboarding rests on one assumption: the person in front of the camera is a real, live human who matches the identity document. Selfie matching and liveness checks were built to test that assumption. Generative AI has made it cheaper to attack it, because a convincing face, a lip-synced video or a face swap on a live feed no longer needs studio skills or expensive tools.

For compliance, risk and product teams the practical consequence is specific. A deepfake that passes onboarding produces an account that looks fully verified: a genuine-looking document, a matching face, a clean audit trail. It can then be used for mule activity, synthetic identity abuse, credit fraud or account resale. The failure is invisible at the time and expensive later. Fraud teams usually find it through downstream behaviour, which is why onboarding controls and fraud detection need to share signals.

This page covers attacks on the selfie and video step and how to defend it. Forged physical documents are a separate problem, covered in our guide to detecting forged IDs. The basics of face matching and liveness in onboarding are in the biometric verification guide.

Two attack families: presentation and injection

The most useful distinction for defenders is where in the capture pipeline the fake enters. Many vendor pages blur the two, and that hides the real gaps in a control set.

Presentation attacks

In a presentation attack the sensor still captures something physical. The attacker holds up a photo, plays a clip on a second screen, or wears a mask. Deepfakes enter this family when the generated face is shown on a screen to the camera. These attacks leave physical traces: screen moiré, glare, bezels, flat depth, unnatural reflections, missing micro-movements. Mature PAD models are built to look for exactly these traces.

Injection attacks

In an injection attack the camera is bypassed. The attacker replaces the video stream with a file or a real-time generated feed, so the verification software receives "perfect" frames that never passed through a lens. Common routes include virtual camera drivers, emulators, modified mobile apps and browser manipulation. Because the feed is digital, there are no screen artefacts to detect, and a deepfake can be rendered at full quality and tuned in advance against the vendor's known challenges.

This is why injection is the more serious trend for remote KYC. A liveness model that is excellent at spotting a phone held up to a lens can still be defeated if it will accept whatever video the client hands it. Scale also matters: an injection toolkit can be scripted and run against many accounts, while a presentation attack needs physical effort for each attempt.

Face swap fraud in live video

Face swap fraud is a particular case, relevant to both live video calls and active liveness. Real-time face-swap software maps the attacker's expressions onto a target face, so the "person" can blink, turn their head and follow instructions. Delivered through a virtual camera, it is an injection attack. Shown on a second screen, it is a presentation attack. Defenders should test both variants.

What the trend data does and does not tell you

Europol, the EU law enforcement agency, has analysed deepfakes through its Innovation Lab and has repeatedly flagged generative AI as lowering the barrier for criminals, including for fraud and document and identity abuse. Readers should check the current publications on the Europol website rather than rely on a summary here.

Be careful with the numbers you see in vendor marketing. Headline figures about deepfake growth often come from a single vendor's own traffic, measure different things (attempts, detections, incidents) and are rarely comparable. We do not quote figures here for that reason. A more reliable approach is to measure your own funnel: how many sessions fail liveness, how many show virtual camera or emulator signals, and how many "verified" accounts later turn out to be fraudulent.

Three patterns are widely reported by practitioners and are worth building your threat model around:

• Attacks move to the weakest channel. When a mobile SDK is hardened, attackers shift to web capture, where there is less control over the environment.
• Attacks are tested against the product. Fraud communities share what passes and fails, so static challenges (for example "turn your head left") become predictable.
• Fakes are combined. A generated face is paired with a forged or stolen document, a synthetic email and phone, and a clean-looking IP, so a single-signal check sees nothing wrong.

Detection methods that work together

No single technique stops deepfakes. The aim is to make an attack expensive, because each layer forces the attacker to defeat a different kind of evidence.

1. Passive and active liveness (PAD)

Liveness detection decides whether the capture shows a live person rather than an artefact. Passive approaches analyse a short capture for texture, depth cues, reflections, motion and other signs of a physical, live subject without asking the user to do much. Active approaches add challenges such as head movement, or a random on-screen light sequence reflected from the face. Challenge-response with unpredictable, server-chosen challenges is harder to pre-render than a fixed one. For a short definition, see the Day 38 article on liveness detection (What Is Liveness Detection? Definition and How It Works), which will be published alongside this page.

2. Injection attack detection

This looks at the capture channel rather than the face. Signals include whether the video source is a real hardware camera or a virtual one, whether the app or browser has been tampered with, whether the device is an emulator or rooted, whether the frame timing, resolution and metadata look like a genuine sensor stream, and whether the SDK's own integrity checks pass. Capturing inside a controlled SDK or hardened web component is generally easier to defend than accepting uploaded video files.

3. Device and network intelligence

Device, IP and behavioural signals are independent of the face. Many attempts from one device, an anonymising network, a location inconsistent with the claimed address, or a device fingerprint tied to earlier rejected sessions are all useful risk signals. ScreenlyyID provides IP and device intelligence that can be used alongside biometric checks, and email, phone and address validation add further independent evidence.

4. Document-to-face consistency

Compare the selfie to the portrait on the document, and also check that the document capture itself is genuine and recent. Consistency analysis looks for oddities such as a portrait that is too clean compared with the printed photo, signs the document image was itself replayed from a screen, or a selfie that matches one document but shows traits (such as apparent age) at odds with the data. Face matching alone is not enough, because a generated face can be built to match a stolen portrait. See document authentication for the document side.

5. Deepfake artefact analysis

Some systems analyse frames for generation artefacts: inconsistent lighting, boundary blending around the face, unnatural eye or teeth rendering, or temporal flicker. This can add signal, but it is a moving target. Generators improve and detectors trained on one family of fakes can miss another, so treat it as one layer, not the decision.

6. Data checks and risk decisioning

Electronic identity checks against authoritative data (see eIDV) confirm that the identity exists and fits the claimed details. A deepfake can be tuned to beat the camera, but it cannot make a synthetic identity appear in trusted data. Feeding all signals into a single risk decision, with manual review for borderline cases, avoids relying on any one score.

Certification: what it covers and what it doesn't

Independent testing is the best way to cut through vendor claims, but you need to know what each certificate proves.

• ISO/IEC 30107-3 is the international standard that defines how biometric presentation attack detection is tested and reported. It is published by ISO with IEC.
• iBeta is a testing laboratory that conducts PAD testing against ISO/IEC 30107-3 at defined levels, which differ in the sophistication of the attack artefacts used. Check the report or letter itself for the level, the attack types tested and the product version.
• Injection attack testing is a newer area. PAD conformance to ISO/IEC 30107-3 addresses presentation attacks, not injection. The European standards body CEN has published a technical specification on biometric injection attack detection (CEN/TS 18099). Confirm the current status of that and any related standards with the standards body, and ask vendors whether they have been independently tested against injection.

The point most buyers miss: a PAD certificate is evidence about the lens-facing half of the problem. A vendor can hold one and still accept injected video. Ask for evidence on both, and ask whether the tested configuration (SDK, version, device types, web or mobile) is the one you will deploy. Standards and test programmes evolve, so verify current requirements directly with the bodies concerned.

Regulatory context

Regulators generally expect firms to verify identity using reliable, independent sources and to manage the risks of non-face-to-face onboarding. Specific expectations on biometric and remote verification differ by country and sector, and they change. Check the current rules with your regulator or legal counsel. This page is information, not legal advice. Biometric data is also sensitive personal data in many jurisdictions, so privacy obligations apply to how you collect, retain and process face images. Our biometric verification guide covers privacy in more detail.

How to defend your onboarding flow: step by step

1. Map your capture channels. List every place a selfie or video is taken: iOS, Android, mobile web, desktop web, assisted video calls, and any upload fallback. Each is a separate attack surface.
2. Write a threat model per channel. For each, note which presentation and injection attacks are feasible. Upload fallbacks and desktop web are usually the weakest.
3. Prefer controlled capture. Capture in an SDK or hardened web component rather than accepting pre-recorded files, and block or flag virtual cameras, emulators and tampered environments.
4. Use unpredictable liveness. Combine passive analysis with randomised challenges chosen server-side so attackers cannot pre-render the response.
5. Add independent signals. Layer in device and IP intelligence, email and phone validation, and eIDV data checks so a perfect-looking face does not decide the outcome alone.
6. Check consistency across the session. Compare selfie, document portrait, document data and claimed details, and flag mismatches.
7. Route risk to review. Set thresholds so borderline sessions go to manual case review and not an automatic accept.
8. Red-team and monitor. Test your flow with current deepfake and virtual-camera tools, track failure and fraud rates by channel and device, and retest after any SDK or vendor change.

Checklist for evaluating a vendor

Use these questions in a procurement review or proof of concept. Ask for evidence, not assurances.

Be wary of any vendor that quotes a single accuracy number for "deepfake detection" without describing the test set, attack types and conditions. Be equally wary of claims that one technique, such as artefact analysis, solves the problem.

Where ScreenlyyID fits

ScreenlyyID's identity verification API combines document authentication, biometric and liveness checks and eIDV database checks, with IP and device intelligence and email, phone and address validation available through the same platform. That lets you build the layered approach described above rather than depending on one signal. You can read more on biometric fraud detection and browse the wider identity verification hub. Sign-up is self-serve, so you can run your own tests against your own traffic and attack scenarios before committing.