What Is a Digital Injection Attack in Identity Verification and How Do You Detect It?

What is a digital injection attack in KYC?

A digital injection attack in KYC is any method that delivers a selfie, liveness video or document image to the verification service without that media passing through the physical camera the flow expects. NIST SP 800-63A-4 describes injection as inserting modified or forged media between the capture point, such as a phone, and the component that performs the comparison or review.

A deepfake injection attack is the most common pairing today. The attacker generates a face swap, a reenacted video or a fully synthetic face, then injects it so the system treats it as a live capture. NIST notes that a biometric comparison performed on the captured sample does not prevent this, because the comparison runs on whatever media arrives.

Injection differs from presentation attacks, where someone holds a printed photo, a screen or a mask in front of a real camera. Presentation attacks leave physical clues the camera can see, such as moire patterns, screen edges or paper texture. Injected media has none of those clues because no second surface was ever filmed.

How attackers inject media: virtual cameras, emulators, hooking and API replay

Four techniques account for most injection attempts against selfie and video KYC. Each one replaces the camera at a different layer, which is why each needs a different control.

A virtual camera is a software driver that registers itself as a webcam. A browser or desktop app asks the operating system for a camera, receives the virtual device, and gets whatever stream the attacker routes into it, including a real-time face swap. The sibling guide on virtual camera injection covers source policy for web flows.

An emulator runs the mobile app inside a simulated Android or iOS environment on a computer. The emulator maps its camera to a video file or host stream, so the app believes it is filming. Emulators also make it easy to script thousands of attempts with fresh device identifiers.

Hooking uses runtime instrumentation on a rooted or jailbroken phone, or a repackaged copy of the app, to intercept the camera API inside the app process. The app code is untouched from its own point of view; the frames it receives have been swapped before they reach it.

API replay skips the client entirely. The attacker studies the upload request, then calls the backend directly with a crafted or previously accepted payload. Simple versions resend an old selfie; more careful ones submit a new deepfake with valid-looking session fields. These overlap with replay attacks, where the risk is stale evidence reused across sessions.

How do injection attacks bypass liveness detection?

Injection attacks bypass liveness detection by removing the physical scene that liveness checks were built to inspect. Passive presentation attack detection looks for signs that a camera is filming a print, screen or mask. When the frames come from a virtual camera or a hooked API, there is no second surface to find, so a deepfake can score as a live person.

Active liveness raises the bar without closing the gap. If the flow asks the user to turn their head or blink, a real-time face reenactment tool can follow the prompt and stream the result through a virtual camera. A challenge only helps when the server can confirm the response came from the session it issued and from a trusted capture path.

Gartner made the same point in February 2024, quoting analyst Akif Khan that PAD standards and testing do not cover digital injection attacks using current AI-generated deepfakes. The comparison between liveness detection and deepfake detection explains how the two checks answer different questions.

What NIST SP 800-63A-4 and CEN/TS 18099 require for injection attacks

NIST SP 800-63A-4, published in July 2025, has a dedicated section on digital injection prevention and forged media detection. It applies to all remote identity proofing, unattended and attended, that uses optical capture, remote biometric capture or video sessions. NIST also says plainly that even its listed mechanisms are not sufficient to address every case.

CEN/TS 18099:2024, Biometric data injection attack detection, became valid on 16 December 2024. It defines biometric data injection attacks against enrolment and verification, gives guidance on detecting injection attack instruments and mitigating their risk, and describes how to build a test plan for an injection attack detection system. It leaves presentation attack testing to ISO/IEC 30107. The full text is sold by national standards bodies; the scope summary here comes from the published catalogue entry.

Certification programmes are starting to test for injection too. The FIDO Alliance Face Verification certification lists injection attacks among the threats it tests, alongside liveness checks.

How to detect injection attacks: layer device, session and media checks

Detecting injection attacks means checking two things for every submission: whether the capture path can be trusted, and whether the media itself shows manipulation. Either check alone leaves a gap. A clean device can still stream a deepfake from a virtual camera that evades source checks, and a perfectly genuine-looking video can arrive from an emulator.

Encryption does not close the gap. TLS protects the channel once both ends are established, but a hooked or repackaged client is still an endpoint, and it will send forged frames over a perfectly valid encrypted connection.

A practical stack for selfie and video KYC looks like this:

• Use platform attestation (for example Google Play Integrity on Android or App Attest on iOS) and app integrity checks to reject emulators, rooted or jailbroken devices and repackaged builds.
• On web flows, inspect the camera source and block or step up known virtual camera drivers according to your policy.
• Issue a server-side, single-use challenge and bind it to the capture so the backend can confirm freshness and sequence before it scores anything.
• Send every selfie, video and audio clip to media analysis for face manipulation, generative artifacts and pixel-level edits, as NIST requires.
• Correlate results with device, account and network telemetry, and search for the same face or file across attempts.
• Test the whole path with injected deepfakes, replayed files and emulator runs, and record false negative rates per attack artifact.

Where NeuroVerify fits: media analysis that complements device integrity

NeuroVerify covers the media-analysis layer. It examines the face image, video or audio that reached your backend, whatever route it took, and returns one unified risk score with signal-level evidence. It does not inspect the device, detect emulators or identify virtual camera drivers; those signals should come from your attestation and app integrity tooling, and your policy combines both.

One request to the NeuroVerify API runs six signals: Visual Safety Screening, Live Presence Verification, Face Manipulation Detection, AI Generative Model Analysis, AI Pixel-Level Manipulation and AI Content Compliance. The generative-model and pixel-level signals map to the NIST expectation that media be analysed for manipulation and deepfake tool signatures. Eligible image requests return in under 200 ms p95 under defined test conditions, so the check fits inside a synchronous onboarding step.

The detection models build on ARCAS 1B, Neural Defend's own deepfake detection foundation model; the ARCAS paper reports pooled accuracy of 99.99% on GenImage and 97.65% on OpenFake. On the public VendorBench-100 benchmark of 100 adversarial still images, Neural Defend ranked first of 36 systems with an MCC of 0.876 against 0.646 for the next vendor. That benchmark does not measure injection, video or audio, and one of its authors also co-authored the ARCAS paper; the corpus and results are public.

Integration uses mobile SDKs for Android, iOS and Flutter, backend SDKs for Python, TypeScript, Go and Java, or the REST API, with managed cloud, private cloud, on-premises and air-gapped deployment. Neural Defend holds ISO/IEC 27001, ISO/IEC 27701, ISO/IEC 42001 and SOC 2 Type II certifications.

Where detection helps, where it does not, and what to do after a hit

Media analysis is strongest when the injected content was generated or edited, because face swaps, reenactment and synthetic faces leave statistical traces. It is weakest when an attacker injects a genuine, unedited recording of the real person, such as a stolen video. That case is a replay problem, and it is caught by session binding, freshness checks and duplicate-media search rather than by manipulation scores.

Treat every score as a signal for a policy decision. Route high-risk results to step-up or manual review, and keep thresholds tied to your own false positive tolerance.

When injection is suspected, preserve the app version, device and session identifiers, challenge data, raw media, timestamps and the decision log before changing anything. Restrict the vulnerable route, then re-verify identities that were enrolled through it.