Injection Attack Detection: The Certificate You Have Covers the Wrong Attack

One word, two completely different attacks

Search injection attack detection and most of the first page is about databases. CrowdStrike and SentinelOne both rank well for it. Both are writing about SQL injection, command injection, cross-site scripting. Real attacks. Wrong ones for anybody running remote onboarding.

Code injection targets a query. The attacker sends input that the application executes instead of storing.

Biometric injection targets a camera. The attacker sends frames that the verification pipeline treats as a live capture instead of a file.

The defences share nothing. Parameterised queries do not help. Input sanitisation does not help either, because the input is a completely valid video stream. It simply did not come from a lens.

This vocabulary collision has an operational cost. Fraud teams inherit the word "injection" from their application security colleagues, assume AppSec owns it, and never put a single question about it to their identity vendor.

The certificate that covers the wrong attack

Ask a verification vendor whether their liveness is certified and the answer comes back fast: ISO/IEC 30107-3, tested by iBeta, Level 1 and Level 2, sometimes Level 3.

That certificate is real. It is also about a different attack.

ISO/IEC 30107-3 governs presentation attack detection. Presentation means something is presented to the sensor. A printed photo. A phone screen playing a video. A silicone mask. The camera genuinely captures light bouncing off a physical object, and the test measures whether the system notices.

An injection attack never puts anything in front of the lens. There is no artefact to catch. No moiré pattern, no screen glare, no flat 2D geometry, no missing depth. The frames arrive already digital.

Europe treated this as a separate problem and published a separate document. CEN/TS 18099, titled "Biometric data injection attack detection," was approved by CEN in October 2024. It is the first specification written for this attack class, covering injection attack instruments, detection systems, and test methodology. ISO opened a matching project, ISO/IEC 25456. It is still not published.

The consequence is uncomfortable. Until iBeta launched injection attack detection testing against CEN/TS 18099 in 2026, there was no third-party proof to ask for. So a PAD certificate became the default answer to an injection question, and buyers accepted it, because the words look adjacent.

They are not adjacent. A system can hold ISO/IEC 30107-3 Level 3 certification and have no defence at all against a virtual camera.

The feed blinks on cue

This is not a lab curiosity. MITRE ATLAS carries it as a formal case study, AML.CS0033, "Live Deepfake Image Injection to Evade Mobile KYC Verification." It came from an iProov red team exercise dated October 2024 and was published in December 2025.

The chain is short and cheap.

A face-swap model runs on consumer hardware and renders the target face in real time. Its output is routed into streaming software, then exposed to the operating system as a webcam device. Attackers rename that device so it looks like a physical camera and set it as the default. The onboarding app opens "the camera" and receives the deepfake.

On mobile, the same result arrives three other ways. The app runs inside an emulator, which maps the host machine's virtual camera as the phone's camera. Or the device is rooted, and a hooking module intercepts the camera API and returns frames from a local video file instead of the sensor. Or nothing touches the camera at all, and the image payload is swapped in transit between client and backend.

Every one of those paths defeats a liveness prompt, because the injected stream answers the prompt. Ask for a head turn and the model turns. Ask for a blink and the model blinks. Volume follows: iProov recorded native virtual camera attacks rising 2,665% across 2024, after face-swap injection attacks rose 704% between the first and second half of 2023.

Then there is the number that ends the "is this really happening to us" conversation. Group-IB's Weaponized AI report, published in January 2026, documented 8,065 biometric injection attempts against the digital KYC loan onboarding of a single financial institution between January and August 2025. That is roughly thirty-three attempts a day, every day, for eight months, at one institution.

Detection is a provenance problem, not an image problem

Here is the shift that matters, and it is the reason so many teams buy the wrong thing.

Most anti-deepfake work asks: does this face look real? That is an image question, and it is an arms race against generative models that improve every quarter. You will sometimes win it. You will not reliably win it.

Injection attack detection asks a different question: did these frames originate from a real sensor, on this device, in this session?

That question is answerable, because it is not about pixels. It is about the path the pixels travelled. The signal families that actually work sit before the biometric engine, not after it:

• Camera device enumeration and driver inspection, to spot virtual camera software and devices that do not match known hardware.
• Camera API behaviour, including frame timing, resolution negotiation, and buffer patterns that differ from a physical sensor.
• Emulator, root, and jailbreak detection on the client.
• Frame and sensor metadata consistency, including compression history and entropy that reveals a re-encoded file rather than a live capture.
• Cryptographic binding of the capture to the session, so a payload cannot be lifted and replayed elsewhere.
• Transport integrity, so an intercepted request cannot have its media swapped without breaking a signature.
• Cross-session correlation, which catches the same background, the same device artefacts, and the same rig reused across dozens of applicants.

Notice what none of these do. None of them look at the face. That is the point. The strongest injection signals are collected before anything biometric happens, and once the frames reach the matcher it is already too late to ask where they came from.

At Signzy this is the reason device and stream integrity checks run ahead of biometric analysis rather than alongside it. Ordering is not an implementation detail here. It decides which question you are still able to answer.

The step nobody audits

India runs the most prescriptive remote onboarding regime in the world, and it produced an accident worth studying.

RBI's V-CIP rules require live geotagging that places the customer inside India. Following the January 2024 update, the application must also reject connections from foreign IP addresses and detect spoofed ones. Those requirements were written for jurisdictional control. Nobody drafted them as an anti-deepfake measure.

But look at what an injection rig actually is. A desktop machine running streaming software. An emulator on a hosted server. A rooted handset behind a proxy. These setups routinely fail to produce a mobile GPS fix that agrees with the network path they arrived on, and a meaningful share of them are not in India at all.

So Indian institutions running compliant V-CIP have been getting a partial injection control for years, for free, as a by-product of a geography rule. The same vendor stack deployed in a market without geofencing loses that layer entirely, and most teams never notice, because they never knew they had it.

Two warnings sit inside that observation. It is partial: GPS is spoofable on a rooted device, and residential proxies inside India are purchasable. And it is invisible in the audit. A concurrent auditor replays a stored V-CIP session, sees a coherent recording, and signs it off, because the record contains no field that says which physical device and which camera produced those frames. The audit that the regulator mandates cannot, by construction, catch injection. It was never asked to.

What the regulators already said, and where the wording stops

The obligation exists in substance in several places already.

NIST finalised SP 800-63A-4 in August 2025 with a section on digital injection prevention and forged media detection. Providers shall set requirements for it, and should analyse media for signatures of generative AI tools. In Europe, EU Implementing Regulation 2025/1942 made ETSI TS 119 461 v2.1.1 the reference standard for remote identity proofing conformity assessment. High assurance under that standard requires resistance to both presentation and injection attacks. FinCEN's November 2024 alert, FIN-2024-Alert004, put deepfake media squarely inside customer due diligence. FATF's Horizon Scan on AI and Deepfakes, published 22 December 2025, went further and named liveness checks as an attack surface.

India is the interesting exception, and it deserves accurate reporting rather than vendor enthusiasm. RBI's 14 August 2025 amendment requires V-CIP to run under a documented workflow. It must be operated by specially trained officials. Those officials have to be capable of carrying out a liveness check and of detecting "any other fraudulent manipulation or suspicious conduct." The amendment also adds Aadhaar Face Authentication as a permitted method, and requires that liveness checks not exclude persons with special needs.

It says nothing about synthetic faces. Anybody telling you RBI now mandates deepfake detection has not read the text.

Read it honestly and the position is still clear. A trained official is expected to detect fraudulent manipulation. A perfect injected stream is fraudulent manipulation that a human reviewer cannot see, on a call, in ninety seconds. The obligation lands on the institution either way. Waiting for a circular to name the attack is the wrong read of where the risk already sits.

Four questions that should end a vendor call

Bring these to the next renewal, in this order.

Are you tested for injection attacks, separately from PAD? The acceptable answer names CEN/TS 18099 and a lab. "We are iBeta 30107-3 Level 2 certified" is an answer to a question you did not ask.

What do you detect before the biometric engine runs? Listen for virtual camera enumeration, emulator and root detection, and camera API behaviour. If everything they describe happens after the face is extracted, they are doing deepfake image analysis and calling it injection defence.

Is the capture cryptographically bound to the session? If a payload can be intercepted and substituted without breaking a signature, the camera layer is irrelevant. The attacker will never touch it.

What lands in my audit record about capture provenance? Ask to see the field. If the stored evidence cannot tell an auditor which device and camera produced a session, no amount of detection at runtime survives into your file.

The twenty-session test

Pull twenty sessions that passed in the last month. Not the flagged ones. The clean ones.

Now try to establish, from stored evidence alone, which physical device and which camera produced each capture. Not whether the face matched. Not whether liveness scored well. Whether a sensor was involved.

If you cannot answer that for all twenty, you do not have injection attack detection. You have liveness, and a very tidy audit trail of attacks you cannot see.