For the last decade, most compliance and security teams have evaluated biometric risk through the lens of presentation attacks: masks, printed photos, screen replays. That model is no longer sufficient.

Today’s highest-impact fraud doesn’t always happen in front of the camera. It happens inside the pipeline: where attackers replace or modify the biometric sample before feature extraction. CEN/TS 18099 was created precisely to standardize how we define, detect, and test those attacks.

What CEN/TS 18099 actually standardizes

CEN/TS 18099 focuses on biometric data injection attacks: interfering with the biometric system by replacing the original captured sample with an injected instrument before feature extraction.

The specification provides:

• Definitions and terminology for injection attacks and their components
• Guidance for building Injection Attack Detection (IAD) systems and mitigation strategies
• Guidance for creating a test plan to evaluate IAD, including bona fide presentation testing to ensure legitimate users aren’t harmed

It also draws a clean boundary:

• Presentation attack testing is out of scope (handled via ISO/IEC 30107)
• Cryptographic mechanisms like secure elements are not covered (important, but separate)

That boundary is a feature, not a bug: it forces teams to stop conflating camera-facing spoofing with data-path compromise.

Why injection attacks are a compliance problem, not just a security problem

Injection attacks create a governance nightmare because they can produce audit-friendly artifacts while being entirely fraudulent:

• The video looks live.
• The face matches.
• The session metadata appears valid.
• The outcome is reproducible at scale.

Compliance impact typically shows up in three places:

1. Procurement defensibility: We tested liveness is not the same as We are resilient to injection.
2. Operational risk: Injection attacks scale like software, not like masks. One toolchain can target multiple institutions.
3. Regulatory alignment: Remote identity proofing requirements increasingly tie assurance to demonstrable controls and third-party evaluation.

The part most people miss: this is as much about testing methodology as it is about tech

A good standard doesn’t just name a threat: it forces repeatable evaluation.

In practice, TS 18099-aligned thinking means you can buy an assurance outcome, not a marketing claim. Organizations are starting to specify explicit assurance expectations (often described as Basic, Substantial, or High) and require independent evaluation evidence to match.

This structure matters for compliance teams because it enables procurement language like:

• IAD must be evaluated by an independent lab against TS 18099 at Substantial (or High) level.
• Evaluation must include bona fide presentation testing to measure false rejects in real operations.

Case study 1: The perfect selfie that never touched the camera (Tier-1 retail bank)

Scenario (anonymized, representative):
A large retail bank rolled out fully remote onboarding. Their PAD/liveness stack performed well against replays and masks. Fraud still spiked: especially on high-limit accounts.

What happened:
Attackers used a virtual camera / injected media stream so the KYC session received a synthetic live video. Liveness challenges passed because the attacker controlled the pixels feeding the pipeline.

What changed after adopting injection-focused controls:

• Moved from challenge-response liveness only to pipeline integrity signals
• Capture-source indicators (device plus OS camera stack integrity signals)
• Detection of media-hooking patterns (abnormal capture API behavior)
• Transport and session binding so biometric samples can’t be replayed across sessions
• Policy: high-risk journeys require IAD evidence, not just PAD

Outcome:
Fraud loss reduced materially, but the bigger win was governance: audit reporting could distinguish presentation-attack resilience vs injection-attack resilience.

Case study 2: Government digital ID enrollment at scale: when device diversity becomes an attack surface

Scenario (anonymized, representative):
A government program expanded remote enrollment across a fragmented device ecosystem, including older Android builds and unmanaged consumer devices.

What happened:
Attackers targeted the weakest segment: devices where app hardening and OS integrity signals were limited. Injection toolchains worked once and then scaled across regions.

What worked in practice:

• Risk-tiered assurance: High-value or high-abuse enrollment paths required stronger integrity evidence and tighter IAD thresholds.
• Decentralized matching (privacy plus security): Keeping matching and decisioning decentralized reduces the blast radius of centralized compromise.
• Independent evaluation: Procurement shifted to third-party test evidence rather than internal spot checks.

Case study 3: An integrator’s dilemma: your customer’s regulator is now your product manager

System integrators and IDV providers are in the hottest seat. Banks and governments increasingly require remote identity proofing stacks that align with recognized standards and certification schemes.

The practical implication is straightforward:

• If your stack includes face biometrics or remote onboarding, you will be asked: Where is your TS 18099 evidence?
• And the follow-up will be: At what level?

How to operationalize CEN/TS 18099 in procurement and architecture

Here’s a pragmatic way compliance and security officers can translate TS 18099 into requirements without becoming biometric specialists:

1) Separate PAD and IAD as distinct control families

• PAD: ISO/IEC 30107 testing and reporting
• IAD: TS 18099 evaluation and reporting

If a vendor collapses them into liveness, treat that as a governance red flag.

2) Require evaluation that includes bona fide presentation testing

Bona fide testing is essential for banks and governments because the compliance failure mode isn’t only fraud: it’s also exclusion, complaints, and unequal access.

3) Ask where can injection occur? and force a data-flow answer

Injection can happen:

• At the capture interface (virtual camera / API hooking)
• At the OS/media pipeline
• At the app boundary
• In transit (session swapping / replay)
• At the server ingest boundary

Vendors should provide a threat model and architecture narrative that explicitly accounts for these points.

4) Make assurance level explicit and journey-specific

Not every workflow needs the same bar. But some workflows absolutely do:

• High-value account opening
• Benefit disbursement
• eID issuance / credential recovery
• Remote notarization / qualified certificate issuance

Specify Basic/Substantial/High expectations per journey and justify them in your risk assessment.

Why decentralization matters in an injection world

Injection attacks exploit the fact that biometric systems often trust their own internal inputs too much.

A decentralized approach: where matching and decisioning can be performed closer to the user or within hardened enclaves, with strong session binding and minimal centralized exposure: adds two advantages:

• Reduces centralized choke points where injected samples can be mass-exploited
• Improves privacy posture by limiting raw biometric movement and storage

The strategic takeaway: CEN/TS 18099 turns "trust me" into "test me"

Deepfakes and synthetic identity are not slowing down. The winning strategy for regulated institutions isn’t to chase every new attack demo: it’s to procure solutions that can prove resilience under standardized, repeatable evaluation.

CEN/TS 18099 draws a bright line around injection attack detection and gives the ecosystem a common language for testing and assurance. For compliance and security leaders, that means you can finally write requirements that survive audit scrutiny, vendor disputes, and incident postmortems.