Injection Attacks and the Next Phase of Remote Identity Verification
Presentation attacks put something fake in front of the camera. Injection attacks skip the camera entirely. This paper explains the difference and the layered defenses onboarding teams need.
For most of the last decade, liveness detection was a contest between a camera and whatever an attacker held up to it: a printed photo, a replayed video on a second screen, a silicone mask. Standards such as ISO/IEC 30107-3 gave the industry a vocabulary and test methodology for these presentation attacks, and detection rates improved dramatically.
What changed
Attackers noticed that the weakest link was no longer the camera but the pipe behind it. In an injection attack, the fraudster feeds synthetic or pre-recorded media directly into the verification app or browser session using virtual camera drivers, emulators, or hooked device APIs. The liveness model may be analyzing a perfect-looking face that never existed in front of any lens. Cheap, high-quality generative video has made this attack far more accessible than it was even two years ago.
Layered defense
Defending against injection requires signals from outside the image. On mobile, device integrity checks can reveal emulators, rooted operating systems or instrumentation frameworks. On the web, the session can be tested for virtual camera software and inconsistencies between claimed and observed hardware. Challenge-response techniques, such as randomized lighting sequences projected from the screen that must appear on the subject's face with the right timing, are hard to reproduce in pre-rendered media.
The document side matters too. Reading the cryptographically signed chip in an ePassport or modern national ID card over NFC gives a trusted reference photo and data that cannot be convincingly altered, which reduces dependence on analyzing images of the document's printed page.
Operating the program
No single control is sufficient, so onboarding teams should measure the pipeline as a whole: attack attempts detected by each layer, false rejections by device type, and time to adapt when a new tool appears on fraud forums. Reason codes that explain each decision make it possible to tune without guesswork and to explain outcomes to customers who were wrongly declined. The organizations that will fare best are those that treat identity verification as an adversarial system under continuous change, not a vendor checkbox.
More from the library
Running Every Rail at Once: An Architecture Guide to ISO 20022 Payments Hubs
Why banks are collapsing separate wire, ACH, instant and cross-border engines into one message-native hub, and the design decisions that make or break the migration.
The Seconds Before Send: Designing Scam Interventions That Work
A conversation on why generic warnings fail, what behavioral signals reveal a coached payment, and how banks are tuning friction as reimbursement rules shift liability.
Beyond the PAN: Network Tokens, 3DS2 and the Authorization-Rate Playbook
A practical session on moving card-not-present volume onto network tokens, using SCA exemptions responsibly, and reading authorization data by issuer.