An injection attack in facial biometrics replaces the camera feed with a synthetic stream before the SDK (the vendor’s software development kit) receives any frame. Liveness (biometric liveness detection) analyzes frame content, not its origin. A sufficiently high-quality fabricated face can therefore pass: the module evaluates what arrives, not how it arrived.
This guide describes the three technical vectors of an injection attack, explains why liveness does not cover them, and details what dedicated anti-injection controls must verify to close this perimeter. The certification and production data come from real environments, with the laboratory and reference identified.
What distinguishes an injection attack from a presentation attack?
A presentation attack places a physical artifact in front of the camera, such as a printed photo or a silicone mask. Liveness detects this type of fraud by analyzing frames for signs of an artifact, such as incompatible texture, lack of depth, anomalous reflections, artificial edges, and inconsistent motion patterns, among other indicators the analysis can identify.
An injection attack bypasses the camera. The synthetic stream enters the data channel before the SDK. Liveness never sees the real camera—only fabricated frames, which may have been generated from the account holder’s legitimate face, at controlled resolution and lighting.
The standard that certifies resistance to presentation attacks is ISO/IEC 30107-3 (PAD, Presentation Attack Detection). The standard that certifies resistance to injection attacks is CEN/TS 18099:2024. A vendor may obtain certification under one standard and not the other, since each is an evaluation process. The injection perimeter remains open.
What are the three vectors of an injection attack?
The vectors enter through different layers of the technical stack. Each one exploits a distinct point before the SDK.
Virtual camera
The attacker installs a virtual camera driver on the device. The operating system registers this driver as a legitimate physical sensor, with the same hardware identifier as a real camera. The SDK is called, receives the synthetic feed, and processes it normally.
Live-streaming and recording tools used in virtual studios are available free of charge and can be used for this vector. The injected content may be a prerecorded deepfake video or a real-time stream generated by an AI model fed with public photos of the target.
The vector is detectable because software drivers communicate with the operating system differently from hardware sensors. Anti-injection modules verify this signature before processing the frame.
Hook in the capture channel
No virtual camera is installed. Code intercepts the camera call at the operating-system level before it reaches the SDK. The stream is replaced in transit. From the application’s perspective, the camera is working normally.
This vector is more sophisticated: it installs no visible driver, does not appear in the device list, and leaves no trace that a static scan can identify. Detection requires runtime verification of channel integrity.
Device emulation
There is no physical hardware. An emulator simulates the complete device and feeds the camera synthetic content. The backend receives requests from a device that does not exist as a physical object. Emulation may include the target’s face generated with real-time deepfake tools.
The vector can be identified through the environment fingerprint: emulators have battery-consumption patterns and inertial-sensor behavior that differ from real devices. Detection does not require camera analysis.
Why does liveness not detect injection attacks?
Liveness evaluates whether the frames are live: whether the presented face has texture and depth compatible with a real person, among other indicators the analysis can identify. The frames arrive at the SDK already constructed. Liveness analyzes what it receives.
In an injection attack, the frame was fabricated before entering the channel. With modern video-generation tools, it is possible to produce a real-time deepfake with facial micromovements and adaptive lighting. Liveness sees a live face because it received a face built to look live.
Liveness covers the physical artifact. Anti-injection covers the signal’s origin. They are control layers for distinct vectors. Buying only liveness and declaring the system protected against injection is a perimeter gap, not an architectural choice.
How do anti-injection controls verify the channel?
Anti-injection acts before the SDK processes the frame. The verification takes place in the channel.
The SDK verifies whether the responding device is a real physical sensor. Virtual camera drivers communicate with the operating system differently from hardware sensors. The difference is structural and detectable.
Channel verification occurs at runtime. RASP (Runtime Application Self-Protection) techniques identify tampering during the active session. SDK obfuscation prevents the code from being analyzed to map attack vectors through reverse engineering.
Emulators have a different fingerprint from physical hardware. Battery cycles and inertial-sensor behavior distinguish the two environments without requiring camera analysis.
None of these checks appears in the legitimate user interface. The control operates entirely at the infrastructure layer.
What does CEN/TS 18099:2024 certification test?
CEN/TS 18099:2024 is the first technical standard specifically focused on anti-injection controls in biometrics. Published by the European Committee for Standardization, it defines the testing methodology for attacks conducted with IAI (Injection Attack Instrument): any synthetic content injected into the capture channel before the SDK.
The standard has three levels; High is the highest. To reach it, the system must resist at least 15 distinct IAI species, with a maximum BPCER (Bona fide Presentation Classification Error Rate, the rate at which the anti-injection module rejects legitimate users) of 15%.
Certification is not self-declared. The recognized laboratory defines the attacks, runs the protocol, and signs the report. The vendor does not control which IAI species are tested within the set required by the standard.
Antisec laboratory conducted Fortface’s anti-injection module certification from July 30 to August 18, 2026. Result: 18 attacks executed, 15 distinct IAI species, 0 bypasses. BPCER: 2%, within the standard’s acceptable limit of 15%.
For contract managers: a BPCER of 2% means that 98 out of every 100 legitimate users pass the control without additional friction. The 15% limit accepted by the standard shows how far the result is below the minimum threshold required.
What is the operational risk of injection attacks in production?
Attack sophistication has increased with the spread of video-generation tools. An attack that required specialized infrastructure in 2022 now runs on a laptop with a consumer GPU, with deepfakes generated in real time from public photos of the target.
These attempts use the account holder’s real face. The attack is silent: the camera appears to work and liveness passes. There is no anomaly in the session log and no visible alert.
“An injection attack does not trigger an alarm. It convinces the system that it is working normally. That is why the control must be certified by a recognized laboratory: a vendor statement does not cover this vector.” Ricardo Fritsche, CTO, Payface
To go deeper
To understand how choosing a second biometrics vendor affects the control perimeter and vector coverage, the post What to ask before adding a second biometrics provider covers the criteria for evaluating approval rates by segment and traffic-splitting structures.
