Biometric Injection Attacks: Detecting Virtual Cameras, Emulators and Deepfake Feeds

A selfie check can score perfectly on liveness and still accept a fraudster, because an injection attack never puts anything in front of the camera: it feeds a recorded or synthesised face straight into the capture pipeline. Presentation attack detection (PAD) judges what the sensor sees; injection attack detection (IAD) judges whether the data came from a genuine sensor at all. The two now have separate standards, with CEN/TS 18099:2024 for injection and ISO/IEC 30107 for presentation attacks, and NIST SP 800-63A-4 makes digital injection prevention a requirement for remote identity proofing. This guide goes deeper than our Biometric Liveness and Presentation Attack Detection Guide: it covers injection routes and where to detect them, the standards and what each actually requires, the evidence to demand from providers, how to test, and what to measure. It is for fraud, identity and security teams running remote onboarding, account recovery or step-up verification, and it is defensive throughout.

Source note: standards and vendor facts on this page are taken from the official documents listed under Standards and references, checked in November 2026. Detection layers, channel choices, rollout steps and checklist items are NHI Mgmt Group recommendations. Confirm against the official text before relying on it.

Key takeaways

• PAD results say nothing about injection. CEN/TS 18099 and the ISO/IEC 25456 working draft both put presentation attack testing out of scope, and ISO/IEC 30107-3 tests attacks at the sensor; you need separate evidence for each.
• NIST now requires injection controls. SP 800-63A-4 Section 3.14 says providers SHALL use technical controls to confirm media comes from a genuine sensor, such as detecting virtual cameras, device emulators or jailbroken devices, and SHALL analyse all submitted media for manipulation.
• Detect in layers, not in the model alone. Device and app integrity, a server-bound capture session, media forensics and fraud signals each catch attacks the others miss; a deepfake detector by itself is the weakest single layer.
• Independent testing deadlines are arriving. ETSI TS 119 461 V2.1.1 requires independent testing of injection and presentation attack detection by an accredited laboratory every second year, with the first test before the end of 2026.
• Web capture carries more injection risk than native apps. Browsers give you less device integrity signal, so web journeys need stronger session binding, more fraud signals and a clear route to manual or attended review.

What an injection attack is

The FIDO Biometrics Requirements describe injection as bypassing the capture device and inserting a face image or video so that it appears to have been captured live, and place it at attack point 2 of the ISO/IEC 19989-1 model, between the sensor and the rest of the system. A presentation attack, by contrast, is shown to the sensor: a printed photo, a screen replay, a mask. CEN/TS 18099 calls the means of injection an "injection attack instrument" (IAI) and scopes itself to what it calls Type 2 attacks.

The payload can be anything: a replay of a genuine video of the victim, a face swap, a fully generated face or a manipulated document image, which is why SP 800-63A-4 asks providers to analyse submitted media for signatures of generative AI and deepfake tools. MITRE ATLAS tracks the supporting techniques as AML.T0088 Generate Deepfakes and AML.T0015 Evade AI Model. What makes injection dangerous is scale: once an attacker has a working route, each new synthetic identity costs almost nothing, so one weakness becomes a stream of fraudulent accounts.

Injection routes and where to detect them

The table lists the main routes at the level needed to choose controls. It is not a guide to performing them.

Note the pattern: most routes are best stopped by proving the integrity of the device, app and session, before any image analysis runs. Media forensics catches what slips through.

The standards landscape

Injection standards are young and still moving. Status below is as shown by each source in November 2026.

For the identity proofing requirements around these, see the NIST SP 800-63A-4 Identity Proofing (IAL) Guide.

Detection layers

1. Device and app integrity

• Platform attestation: require a fresh app or device attestation token from the mobile platform for each capture session and verify it server-side, never in the client.
• Environment checks: detect emulators, rooted or jailbroken devices, instrumentation frameworks and virtual camera drivers. SP 800-63A-4 names a virtual camera, device emulator or jailbroken device as examples of what genuine-sensor controls should detect.
• Sensor authentication: where the platform can attest the camera itself, use it; SP 800-63A-4 lists sensor authentication or device attestation as a SHOULD.

2. Capture-session binding

• Server-issued nonce: start each capture with a single-use session identifier from the server and require it, signed and timestamped, in the upload.
• Active challenge: the FIDO requirements list challenge-response methods that are hard to generate on the fly, such as randomised light colours, an unscripted spoken phrase or a visual nonce. Verify the response appears in the media.
• Protected channel: SP 800-63A-4 requires authenticated protected channels for proofing data; pin the capture upload to your service.

3. Media forensics

• Manipulation analysis: run automated analysis on every image and video for modification, tampering and forgery, as SP 800-63A-4 requires, plus analysis for generative AI and deepfake signatures.
• Know the error rates: SP 800-63A-4 requires the attack artefact types tested and the false negative rates to be documented and available to relying parties on request. Ask for them.

4. Fraud and behavioural signals

• Channel analysis: SP 800-63A-4 requires analysing remote proofing channels for high-risk indicators such as blocklisted proxies and IP addresses, and recommends device fingerprinting, device tenure and transaction analytics.
• Velocity and reuse: the same device, face template or document across several applications is a stronger signal than any single image score.

5. Human review and attended fallback

SP 800-63A-4 says manual review SHOULD supplement algorithmic media analysis, and recommends offering a trusted referee to applicants who fail fraud checks in unattended journeys. Route injection detections and borderline scores to trained reviewers rather than silently rejecting them, so you learn from each attempt. See the Deepfake-Resistant Identity Verification Guide for the wider proofing flow.

Choosing capture channels and depth

• Native app first for high-risk journeys: account opening with credit, payout changes and account recovery benefit most from platform attestation and native capture SDKs. Offer web capture only with stronger session binding and a lower automatic approval ceiling.
• Web capture with step-up: where web is required, use active challenges and fraud signals, and step up to a native app or attended video session on any integrity doubt.
• Kiosks and controlled hardware: supervised or provider-controlled capture devices largely remove the injection route; the residual risk moves to presentation attacks.
• Small organisations: you will usually buy identity verification as a service. Your job is evidence: obtain separate PAD and IAD reports for the version you run, configure the provider's integrity checks to block rather than score only, and keep your own outcome data.
• Large organisations: run your own authorised testing, keep an internal IAI catalogue, combine provider signals with your own device and fraud data, and require re-testing on every major provider release.

Evidence to demand from providers

• Separate reports: an ISO/IEC 30107-3 PAD report and an injection attack detection report (ideally against CEN/TS 18099), both for the product version and capture channel you deploy.
• Scope statements: which IAIs were tested (virtual camera, emulator, hooking, replay, synthetic media), which platforms and browsers, and which were out of scope.
• Error rates: false negative rates per attack artefact type for media analysis, as SP 800-63A-4 requires them to be available, and bona fide rejection rates so you can judge friction.
• Independence: who tested, their accreditation, and the date. ETSI TS 119 461 expects an accredited laboratory and a two-year cycle.
• Signals you receive: whether integrity, attestation and injection signals are returned to you per session, so you can log and act on them.

The Identity Verification Buyer's Guide covers the wider evaluation.

Implementation: a phased rollout

1. Map journeys and channels: list every flow that captures a face or document (onboarding, recovery, step-up, workforce hiring), its channel (native, web, kiosk) and the loss if an attacker succeeds.
2. Turn on integrity signals in monitor mode: enable attestation, emulator and virtual camera detection and log the results without blocking for two to four weeks to measure the false positive rate on genuine users.
3. Bind sessions: introduce server-issued single-use nonces and signed uploads; reject media not tied to a live session.
4. Enforce by risk: block on hard failures (no attestation, emulator) in high-risk journeys; route soft signals to review. Keep an attended or trusted referee path for genuine users who fail.
5. Test under authorisation: commission an injection test against your deployment, with the provider's written agreement, covering each route in the table and bona fide users on your real device mix.
6. Rollback: if blocking causes unacceptable rejection of genuine users, revert that rule to monitor mode, keep the logging, and fix the cause before re-enabling; never remove session binding.
7. Re-test: after major provider releases, platform OS changes and at least annually.

Detection and measurement

Log per session: attestation result, environment flags (emulator, root, instrumentation, virtual camera), nonce validation, PAD score and decision, media forensics result, fraud signals, reviewer decision and final outcome. Join this to later confirmed fraud so you can see which layer would have caught each case.

• Injection detection rate: injection signals per 10,000 sessions, by channel and platform.
• Attestation coverage: percentage of capture sessions with a verified platform attestation.
• Post-onboarding fraud: confirmed fraudulent accounts per 10,000 approved, with the layer that missed them.
• Genuine-user friction: bona fide rejection and manual review rates after each new rule.
• Review overturn rate: share of automated injection flags that reviewers overturn, a measure of signal quality.

Framework mapping

Common failure patterns

• Accepting a PAD certificate as proof of deepfake resistance: PAD testing never exercised an injected stream, so the certificate is silent on the main deepfake route.
• Client-side checks only: integrity decisions made inside the app can be patched out; verify attestation tokens and nonces on the server.
• Scoring without blocking: providers return integrity flags that nobody acts on, so the attack succeeds while the logs record it.
• Web as an unprotected side door: strong controls in the native app, then a browser journey for the same product with weaker checks, which attackers find quickly.
• No feedback loop: confirmed fraud is closed by the fraud team but never returned to the identity team or provider, so the same route keeps working.
• Silent rejection of genuine users: aggressive emulator or root rules without a referee path push legitimate customers away and hide the true false positive rate.

Practitioner checklist

• Obtain separate PAD and injection attack detection reports for the exact product version and channel you deploy.
• Require server-verified platform attestation and environment checks for every capture session.
• Bind every capture to a server-issued, single-use, signed session and reject unbound media.
• Run media manipulation and generative AI analysis on all submitted images and video, and obtain false negative rates per artefact type.
• Use active challenges in web journeys and step up to native or attended capture on doubt.
• Log integrity, PAD, forensics and fraud signals per session and join them to confirmed fraud.
• Commission authorised injection testing with the provider's agreement, including bona fide users on your device mix.
• Keep a trusted referee or attended path for genuine users who fail integrity checks.
• Track the ETSI TS 119 461 accredited testing cycle and the ISO/IEC 25456 draft for changes to evidence requirements.

Standards and references

• CEN: CEN/TS 18099:2024 Biometric data injection attack detection
• ISO/IEC: WD 25456 Biometric data injection attack detection
• NIST: SP 800-63A-4 Identity Proofing and Enrollment
• ETSI: TS 119 461 V2.1.1 Policy and security requirements for trust service components providing identity proofing
• FIDO Alliance: Biometrics Requirements v5.0 (review draft)
• FIDO Alliance: Face Verification certification
• MITRE ATLAS: Generate Deepfakes
• OWASP: Mobile Application Security Verification Standard

Related NHI Mgmt Group resources: Biometric Liveness and Presentation Attack Detection Guide · Deepfake-Resistant Identity Verification Guide · Deepfake Detection Buyer's Guide · Biometrics Guide