Ask any age-assurance vendor how they stop a fake face, and within a sentence you will hear the same three letters: PAD. Presentation attack detection, independently certified, ISO/IEC 30107-3, iBeta Level 1 or Level 2, zero attacks accepted across hundreds of test artefacts. It is a real credential, earned in a real lab, and it is the single most cited proof point in the entire biometric verification market.
It is also answering a question that the fastest-growing attacks of 2026 no longer ask.
iProov’s 2026 Threat Intelligence Report, published in April, found that injection attacks targeting iOS rose 741% year over year in 2025, with second-half activity up 1,151% against the same period a year earlier. Southeast Asia recorded a 720% spike in a single quarter as attackers tested virtual-camera techniques and stolen KYC packages before scaling them into Latin America and beyond (Biometric Update; iProov). None of that surge is a presentation attack. None of it is what your vendor’s iBeta letter tested. And age assurance — because of who is doing the attacking — sits closer to the blast radius than almost any other use of the technology.
This post is about the gap between the certificate on the slide and the threat in the wild: what PAD actually certifies, why injection is a categorically different problem, why a motivated fifteen-year-old is a worse adversary for age gates than a fraud ring is for a bank, and what you have to add to a liveness stack before “we’re iBeta certified” means what your compliance team thinks it means.
Presentation versus injection: the distinction that decides everything
A presentation attack is something shown to a real camera. A printed photo held up to the lens, a face on a second screen, a video replayed from a phone, a resin or silicone mask. The genuine capture pipeline runs end to end — real lens, real sensor, real frames — and the attacker’s job is to fool the algorithm into scoring an artefact as a live human. This is exactly what ISO/IEC 30107-3 was written to measure. In an iBeta conformance test, a lab throws a defined battery of these artefacts at the system: Level 1 covers cheap, accessible attacks like printouts and screen replays; Level 2 covers higher-effort artefacts like 3D and silicone masks. Pass, and you get a letter stating the system accepted zero of them (iBeta).
An injection attack never touches the lens. The attacker replaces the video stream between the camera and the application — a virtual camera that impersonates a real device, a hooked SDK or OS-level driver, an intercepted transport-layer feed — and injects pre-rendered deepfake frames or a live puppeteered face directly into the pipeline. As Biometric Update put it, in an injection attack it does not matter whether the face in front of the camera is real, because somewhere between input and output the signal has been swapped for synthetic frames (Biometric Update).
Here is the part that gets glossed over in sales decks: there is no equivalent third-party certification standard for injection attacks. ISO/IEC 30107-3 governs presentation attack detection. There is no iBeta-style, universally recognised conformance letter for injection attack detection — the field is only now producing market reports and buyer’s guides for the category (Biometric Update IAD Market Report, June 2026). So when a vendor’s headline assurance is a PAD certificate, the honest reading is not “this system resists deepfakes.” It is “this system resists a class of attack that is declining in relative importance, and we have shown you no independent evidence about the class that is growing 741% a year.”
That is the certification gap. It is not that PAD is worthless — it is necessary. It is that PAD is being marketed as sufficient, against a threat model that has already moved.
Why age assurance is the softest target on the board
The instinct is to assume injection attacks are a problem for banks and crypto exchanges, where the payoff justifies the effort. For identity fraud, that is broadly true. For age assurance, the economics invert, and they invert against the defender.
A bank’s attacker wants to open an account under a stolen or synthetic identity — high value, high stakes, a fraud operation with real cost. An age gate’s attacker is frequently a digitally literate minor who wants into a game, a stream, an adult site, or a betting app tonight. The payoff per attempt is trivial, which sounds reassuring until you notice what it does to the tooling. Low-stakes, high-volume goals are exactly what commodity attack tools are built for. There is no need for a bespoke fraud ring when a free virtual-camera app and a face swap you can run on a mid-range laptop will do.
The evidence is already embarrassing. A May 2026 study by Internet Matters reported that a large share of minors could defeat online age verification within minutes of trying, using a mix of borrowed faces, VPNs, edited selfies, and generated imagery. In one widely repeated finding, children discovered that holding up a high-resolution video-game avatar — a face from FIFA or Call of Duty — was enough to get some facial age-estimation systems to return an adult-compatible result. That is not a sophisticated injection attack. It is a presentation attack that a well-certified system should have caught, which tells you how far the deployed reality lags the lab result. Now layer the injection vector on top: the same teenager, one tutorial later, feeding a generated adult face straight into the stream through a virtual camera, bypassing the lens the PAD test assumed was there.
Two structural facts make this worse for age assurance specifically. First, the modality is usually a single selfie or a short liveness capture, because friction kills conversion and nobody wants a document scan to watch a stream — which means the entire decision often rests on the one channel injection attacks are built to poison. Second, the failure is asymmetric and quiet: a bank notices a fraudulent account when the money moves; a platform that let a minor through notices when a regulator, a journalist, or a coroner’s inquest tells it. The enforcement record of the last year is built on exactly that kind of after-the-fact discovery.
How injection actually gets in
You cannot defend a vector you cannot picture, so concretely, the common injection paths in 2026 are:
- Virtual cameras. Software that registers itself as a webcam and feeds the verification app a pre-rendered or live-manipulated stream. The app “sees a camera,” because from its perspective it does. This is the volume driver behind the iProov numbers.
- SDK and OS-level hooks. On rooted Android or jailbroken iOS — and increasingly through emulators and cloud-phone farms — the attacker intercepts the capture API and substitutes frames below the level the app can see.
- Transport-layer interception. In flows that ship the video to a server for analysis, the stream is manipulated in transit, so the server scores frames the device never captured.
- Emulated and instrumented devices. A farm of emulated handsets, each presenting a plausible device fingerprint, running the same injected face at scale.
Notice what every one of these shares: the deception happens outside the frame content that a PAD algorithm inspects. You can score the pixels perfectly and still be looking at a lie, because the pixels were never in doubt — the provenance of the pixels was.
What actually closes the gap
Defending age assurance against injection is not a matter of a bigger PAD score. It is a different control set, layered on top of the one you already have.
Injection attack detection as a distinct capability. IAD asks a question PAD never does: was this stream produced by a genuine sensor on a genuine device, in real time, or was it manufactured somewhere in the pipeline? Signals include virtual-camera and emulator detection, device and OS integrity checks, capture metadata and frame-timing analysis, and detection of the tell-tale artefacts of synthetic or re-encoded video. The European Association for Biometrics has spent 2026 trying to standardise even the vocabulary here, because the market keeps conflating IAD with PAD and buying one while believing it bought both (Biometric Update; EAB Council of Wisdom).
Secure capture and device attestation. The strongest architectural answer is to bind the capture to a hardware-attested application, so the stream carries cryptographic evidence that it originated on a real device from a real sensor — not a virtual camera, not an emulator, not an intercepted transport. This is the same instinct behind moving intelligence to the edge and treating the device as a root of trust, which we argued in the case for on-device age verification and in why the deepfake era needs a new verification architecture. If the app can prove where the frames came from, injection has to defeat the attestation, not just the pixel classifier.
Server-side liveness with one-time challenges. A liveness check that issues a fresh, unpredictable challenge per session — and evaluates the response on the server, not the device — raises the cost of injection sharply, because a pre-rendered deepfake cannot answer a challenge it did not know was coming, and a replayed stream fails the freshness test. This is precisely why server-side liveness sits above client-side liveness in a serious stack rather than beside it.
Do not stake the decision on a single selfie. The most important design move is to stop treating one biometric channel as the whole verification. A layered orchestration or waterfall routes returning users to a reusable credential, sends the broad middle through estimation, and escalates anyone near the age threshold or on a hard-restricted surface to a stronger method — a chip-verified document, a bank- or wallet-backed attribute — that an injected face alone cannot satisfy. Injection is devastating against a monoculture and merely expensive against a portfolio. The same waterfall also protects you from the opposite failure mode, the false-positive adult lockout that a single conservative estimator produces.
Cut repeated biometric exposure with reusable credentials. Every time you re-run a live capture, you re-open the injection surface. Verify-once, prove-everywhere credentials and zero-knowledge age proofs let a returning user present a signed, privacy-preserving attestation instead of submitting a fresh face to be poisoned — fewer captures, fewer chances to inject, and less biometric data sitting in a honeypot for the next breach.
The buyer’s checklist: questions past the badge
If you are evaluating an age-assurance vendor in 2026, the iBeta letter is table stakes, not the answer. Add these to your security-first evaluation:
- Beyond PAD, what is your injection attack detection? Ask for the mechanism, not a marketing word. Virtual-camera detection, emulator and root/jailbreak detection, capture metadata and frame-timing analysis, synthetic-video artefact detection — which of these do you actually run, and where?
- Is capture bound to a hardware-attested app? Can the stream prove it came from a genuine sensor on a genuine device? If the answer is “we analyse whatever frames arrive,” you are buying a pixel classifier, not injection resistance.
- Is liveness challenge-response and server-evaluated? One-time, unpredictable challenges scored server-side, or a replayable client-side check that an injected stream sails through?
- What happens on detection? Silent pass with a risk score, hard fail, or step-up to a stronger method? A vendor with no step-up path has no answer for the cases that matter most.
- Show me red-team results against injection, not just PAD. Independent injection testing is immature, but a serious vendor is already commissioning it and will show you methodology and outcomes rather than hiding behind the one certificate that does exist.
- How much biometric data do you retain, and for how long? Every retained capture is both a breach liability and future training data for the next deepfake. Minimisation is a security control, not just a privacy one — the argument we make throughout the ISO 27566 vendor benchmark.
A vendor that answers all six well may still show you an iBeta badge — but the badge will be the floor of the conversation, not the whole of it.
Where this leaves operators
The uncomfortable summary: the credential the market has trained you to ask for measures the attack that is shrinking in relative terms, and is silent on the one growing fastest. That is not a reason to distrust PAD; it is a reason to stop treating a PAD certificate as a synonym for “deepfake-proof.” Presentation attack detection keeps a printout out. Injection attack detection, secure attested capture, challenge-response liveness, and a layered decision that never rests on a single selfie are what keep an injected deepfake out — and age assurance, facing motivated minors armed with commodity tools, needs all of them.
Xident is built for that threat model rather than retrofitted to it: server-side liveness detection and face match on the Growth and Scale tiers, age-threshold classification tuned for the accuracy-and-robustness bar regulators now expect, layered orchestration so a near-threshold decision escalates instead of trusting one channel, and token-based reusable verification and privacy-preserving age signals that shrink how often a live capture — and therefore an injection surface — is exposed at all. Verify the fact hard; keep a signed attestation, not the stream.
If you want to pressure-test your current age-assurance stack against the injection vector specifically — where a virtual camera or an emulated device could walk a synthetic adult face past your gate — that is the conversation to have now.
This article is for general information and does not constitute legal or security-assurance advice. The right control set depends on your platform’s risk profile, regulatory obligations, and threat model; validate any vendor’s claims with independent testing against your own requirements.
