If you are a product owner or compliance lead at a QTSP, the face side of your proofing flow has probably had the most attention. Selfie liveness and presentation attack detection get tested hard, and injection attacks on the camera are where recent security investment has gone. The document capture path, where the applicant photographs a passport or ID, tends to get less scrutiny, even though the same injection technique works on both. A stack that catches an injected face does not automatically catch an injected document. You have injection protection for faces. What about documents, and is it certified?

In a Nutshell

• Injection attacks do not only target the face. The document capture path is a second entry point, and attackers are already using it.
• Many teams that solved face injection leave the document route thinner on testing and evidence.
• ETSI TS 119 461 puts the whole capture process in scope. Its definition of an injection attack is about content injected into data capture, not the selfie alone.
• Detecting document injection is not the same as being certified to detect it, and the level that counts for high-assurance proofing is CEN/TS 18099 at High.
• The same detection technology can defend both surfaces, so covering the document is an evidence and certification question more than a build-from-scratch one.

What is an injection attack on document capture?

An injection attack skips the camera. Instead of showing something to the sensor, presentation attack style, the attacker feeds prepared data straight into the capture pipeline, so the system receives an image that never passed through a real lens. ETSI TS 119 461 defines it plainly, an injection attack injects content controlled by the attacker into the data capture process.

On the document path, that means the image your flow believes it captured of a passport or national ID was never captured at all. It was generated, edited, or replayed, then injected through a virtual camera, a tampered SDK, or a manipulated API call. The forgery never has to survive being shown to a real camera, which is what makes it dangerous. A fake that would fail a physical presentation check can still pass as a clean, pixel-perfect file dropped straight into the pipeline. If your document checks assume the image came from a genuine capture, an injected image walks straight past that assumption.

How is it different from injecting a face?

The technique is the same, the target is not. Injecting a face aims to defeat the biometric, to make the system accept a person who is not there, with a deepfake or a replayed video stream. Injecting a document aims to defeat the evidence, to make the system accept an identity credential that was never presented, with a forged or altered image of an ID.

That difference in target changes how you defend each one. Face injection detection is tuned to the signals of a live human capture, the texture, motion, and depth cues an injected stream tends to lack. Document injection detection looks for different tells, the artifacts of a manipulated or synthetic document image and the signature of a capture that bypassed the camera. A model trained to spot an injected face is not automatically trained to spot an injected document. They share a pipeline and a class of attack, so the approach carries over, but the two surfaces have to be defended, tested, and evidenced on their own terms.

Why do teams that solved face injection miss the document?

Attention followed the headlines. Deepfakes made the face the visible threat, so budget, testing, and certification effort concentrated there. The document step, by contrast, has long been treated as an authenticity problem, is this passport genuine, are the security features present, does the data page validate. Those checks are necessary. They also answer a different question than injection detection does.

Authenticity checks ask whether the document is real. Injection detection asks whether the image of it was really captured. A flow can validate a passport as genuine and still have accepted an injected photograph of that passport, because the injected image can be a clean copy of a real page. So a team can honestly say the document is verified, and mean that its features checked out, while the capture path that delivered the image sits untested against injection. The gap is rarely a decision to ignore the document. It is a blind spot, the result of testing the face hard and assuming the authenticity stack covered the rest.

What does ETSI TS 119 461 require on document capture?

ETSI TS 119 461 is the standard that sets out how a QTSP meets the identity proofing requirements of Article 24 of eIDAS 2.0, and it does not confine injection to the biometric. Its consideration of threats, in clause 4.5, defines an injection attack as content injected into the data capture process, which is the process that captures the identity document as much as the one that captures the face. The example the standard gives, bypassing the camera to inject a stream that purports to come from it, describes the document capture path exactly.

The standard also expects the captured evidence to be defended on the way in, not only inspected once it arrives. Clause 8.3 calls for the authenticity and integrity of evidence to be protected from capture through to the component that validates it, and treats the capture and transmission of the applicant's appearance the same way. Read together, the threat definition and the evidence requirement put the document capture path in scope for injection, alongside the face.

How strong that defense has to be follows from the level of identity proofing you claim. For a Baseline level, the risk assessment has to consider at least moderate attack potential, and for an Extended level, at least high. ETSI TS 119 461 names CEN/TS 18099 as the reference for injection attack detection, so for high-assurance proofing the reading is that your injection detection, on the document as well as the face, should stand up to high attack potential, which lines up with CEN/TS 18099 at High. The standard also requires injection and presentation attack detection to be independently tested by an accredited laboratory every second year, with the first test due before the end of 2026.

Detecting it is not the same as being certified to detect it

Here is where covered and certified part ways, and it works the same for the document as for the face. A supplier can build genuine document injection detection, describe it accurately, and demonstrate it on a call. That is a capability, and it tells you what the product is designed to do. What it does not give a conformity assessment is an independent result, because no accredited laboratory has yet run that product against the standard's attack methodology and issued a certificate.

A certification to CEN/TS 18099, at a stated level, is that independent result. An accredited lab tested the product against the standard, judged it against a defined attack potential, and recorded the outcome in a certificate an auditor can rely on. The level is where document capture is easy to under-serve. A stack can hold a strong result for face injection and a lighter one, or none, for the document. So the useful question is not only whether injection detection is certified, but whether the certificate covers the document capture path and reaches the level your proofing requires. For high-assurance proofing, that level is High, and the reasoning behind it is the same argument we make in why QTSPs need certification against CEN/TS 18099 and ISO/IEC 19989-3.

How the same technology protects the face and the document

The good news for a product owner is that closing the document gap is rarely a second engineering program. A detection approach that secures the capture channel, verifying that an image genuinely came from the device camera and was not injected through a virtual camera, emulator, or tampered SDK, applies whether the frame is a face or a passport. The signals differ, and each surface still has to be trained for what it is looking at, but the architecture is shared.

That is why the document question is more about evidence than invention. A supplier that already secures the channel for the face has most of what it takes to secure it for the document, and the work left is proving it, on the document path, at the right level, with a current test behind it.

What should you ask your supplier?

You do not need to run the lab test yourself. A few direct questions on a call will tell you where a supplier stands, and the way they answer is as informative as the answer.

Ask, does your injection attack detection cover the document capture path, or only the face. Many suppliers cover both, so this is not a trick question, it is a scope question. Ask, is that document coverage certified to CEN/TS 18099, and to what level. A capability and a certificate are different kinds of evidence, and for high-assurance proofing you are listening for High. Ask, which accredited laboratory issued the certificate, and can you show it, because a real result names a lab and produces a document. Ask, when was it last tested, since ETSI TS 119 461 expects the evaluation to be repeated every two years and a stale certificate describes a product two years behind the current attacks. A strong supplier welcomes all four and answers each with a document. General answers, or a pointer to a roadmap, tell you where they are today.

Where Youverse stands

At Youverse, we build injection attack detection across both surfaces, the face and the identity document, because we treat the capture channel as one thing to protect rather than two. Today that detection is a capability aligned with CEN/TS 18099, and we are pursuing CEN/TS 18099 at High for document capture, with certification in progress. On presentation attacks, we are certified to ISO/IEC 30107-3 at Levels 1 and 2, a tested result from an accredited evaluation, and our face matching is NIST-recognized. Because we carry our evaluation across iOS, Android, and web, and re-run it on the two-year cycle the standard sets, a QTSP that builds on Youverse inherits that testing rather than standing it up in-house, and where GDPR, CCPA, and PSD2 apply, the stack is built to support your compliance obligations.

If you want to know whether your document capture would satisfy a conformity assessment, walk your flow through these questions with a team that works to these standards every day. Book a meeting to check your document capture against CEN/TS 18099, and we will walk both capture paths through the questions an auditor will ask. If you want to get certification right first, our post on why certification to High is the bar covers it, and our webinar with an independent evaluation lab works through the threat and the standards live.

FAQ

Can documents be targeted by injection attacks?

Yes. An injection attack feeds prepared data straight into the capture pipeline, bypassing the camera, so it works against any capture step, including the photograph of an identity document. An attacker can inject a forged or altered image of a passport or ID card that was never physically presented. That is a different problem from checking whether the document itself is genuine, because the injected image can be a clean copy of a real page.

Does ETSI TS 119 461 require injection detection on document capture?

ETSI TS 119 461 defines an injection attack as content injected into the data capture process, which covers the document capture path, not only the face. It also requires the authenticity and integrity of captured evidence to be protected from capture through to validation, in clause 8.3. For high-assurance proofing, the required attack potential rises to high, and CEN/TS 18099 is the named reference for injection attack detection.

Is document injection detection certified, or just a capability?

It depends on the supplier, and the distinction is worth pressing on. A capability means the product is built and designed to detect document injection, described by the supplier. A certification means an accredited laboratory tested it against CEN/TS 18099 and issued a certificate at a stated level. Youverse's document injection detection is a capability aligned with CEN/TS 18099 today, with certification to High in progress.

What level of CEN/TS 18099 applies to document capture?

CEN/TS 18099 grades injection attack detection by the attack potential it was shown to resist, referenced through the attack potential scale in ISO/IEC 19989-1 Annex F, which runs up to High. ETSI TS 119 461 ties the level to your level of identity proofing, expecting Extended proofing to consider at least high attack potential. So for high-assurance document capture, High is the level to look for, on the document path specifically, not only the face.