UNE CEN/TS 18099:2024

Biometric Injection Attack Evaluation

A deepfake injected through a virtual camera walks straight past your liveness check. Antisec evaluates your biometric SDK against CEN/TS 18099:2024 and issues a Letter of Confirmation.

The vector

The attack your defense was never built to see

The fraudster is never in front of the camera. They install a virtual camera on their own machine, feed that fake device an AI-generated video, and your SDK receives a stream that — from the application's point of view — is indistinguishable from a real webcam.

The biometric sample is replaced after capture and before analysis — there was no presentation to detect in the first place.
No screen artifact, no paper edge, no mask texture: the detector sees exactly what it expects to see in a legitimate capture.
It is scriptable. It runs server-side, in parallel, thousands of times per hour, at near-zero marginal cost per fraudulent identity.

Presentation and injection are different standards

A product can hold a high-level PAD evaluation and fail the first virtual camera test. That is not a failure of the PAD lab: it is a question that evaluation never set out to answer.

	Presentation Attack	Injection Attack
How it happens	Physically, in front of the sensor	In the data flow, after capture
Examples	Printed photo, mask, video on a screen	Virtual camera, interception, replay
Standard that measures it	ISO/IEC 30107 (PAD)	CEN/TS 18099:2024 (IAD)
Attack scale	Low — one at a time, in person	High — automatable

If your biometrics vendor answers “we have liveness certification” when you ask about injection, they have just answered a different question.

Three levels. Pick the one your market demands.

The standard scales the evaluation by instrument coverage, attack methods and adversary profile.

	Basic (Level 1)	Substantial (Level 2)	High (Level 3)
Attack instrument species	reduced coverage	10	15
Distinct attack methods	1+	2	3
Adversary profile covered	opportunistic	organized	specialized and funded
Suited for	product in validation	product at scale	financial services, government, high value

A cycle sized for the High level automatically covers the floors of the levels below it — the verdict for all three levels is recorded in a single evaluation, instead of three independent engagements. That is how we structure projects by default.

What has to be true for your product to pass

Resist the attacks of the evaluated level

Not every conceivable attack: the attacks rated at that level or below, according to the standard's own rating methodology. A bypass requiring three weeks of specialized work and internal product knowledge does not fail a Basic evaluation — it is recorded as residual risk. A payload replay anyone reproduces in fifteen minutes fails every level.

Not punish the legitimate user

The standard requires the genuine-user rejection rate (BPCER) to stay within target — recommended at 15% maximum — measured over at least 300 legitimate transactions collected during the evaluation. It closes the lazy exit: a paranoid system that blocks half of your real customers does not pass.

What you get at the end

Public

Letter of Confirmation

A summary document attesting the conformity level reached, the product and version evaluated and the methodology applied. It is the commercial asset of the evaluation.

RFP and public tender responses
Your enterprise customer's due diligence
Sales material and website
Investor and M&A diligence

Confidential

Technical Report

The nine-section structure required by the standard. In practice it becomes your product security roadmap — prioritized, evidenced, with each attack's cost estimated by the standard's own rating.

Full matrix of executed attacks
Rating of every finding under the standard
Bona fide metrics (BPCER)
Component version analysis and recommendations

One honest point other vendors leave out

CEN/TS 18099:2024 does not yet have a formal certification scheme run by an accredited body — there is no accreditor-issued seal today. What does exist, and what international labs practice for equivalent standards, is exactly the model above: Technical Report plus Letter of Confirmation attesting methodological conformity. That distinction is written into the document we deliver, because that is how an attestation survives the audit of whoever reads it.

How the project runs

Six stages, with your team involved only where it is indispensable.

Security Target

Formal document of assets, threats and security functions, signed by both parties.

What it takes from you A few hours from the product team

Mapping

Attack methods and instruments applicable to your product.

What it takes from you Nothing

Execution

The full matrix, with evidence for every attack — including the blocked ones.

What it takes from you A stable test environment

Rating

Every finding rated under the standard's methodology.

What it takes from you Nothing

Legitimate user metrics

The 300+ legitimate transactions behind the BPCER.

What it takes from you Volunteers (start on day 1)

Issuance

Technical Report + Letter of Confirmation.

What it takes from you Nothing

The real bottleneck is not us. The Antisec-controlled part closes in a counted number of business days; what determines the issuance date is the collection of legitimate transactions, which depends on your volunteer schedule. That track starts on day 1, in parallel — not after the technical testing ends.

Why Antisec

An IAD evaluation is only worth the real capability to build the attack. Building the virtual camera pipeline, intercepting the JavaScript–WebAssembly boundary, defeating integrity watchdogs and producing the attack instruments — deepfake, morphing, face reenactment, synthetic faces — is red team work. It is what we have done for over ten years.

400+ projects delivered

10+ years of offensive operations

100% satisfaction

0 undetected incidents

Tooling already built

The attack pipelines — virtual camera, client-side hooking, channel interception, replay — are built and documented. That does not shorten the rigor; it shortens the calendar. You pay for execution, not lab setup.

Declared scope, including what we do not test

PAD and secure element evaluation are out of scope for this standard, and that is written in the document. It is what makes the report survive your customer's audit.

Remediation window

If a test fails you do not get a failure stamp: you get the formal communication, you fix it, we re-run, and the matrix resumes where it stopped.

Who should already be in this conversation

Biometric SDK, liveness and KYC vendors — the Letter of Confirmation is a sales asset, not a compliance cost.
Banks, fintechs and acquirers integrating third-party biometrics.
Insurers, healthcare and the public sector with remote proof of life — where a successful injection becomes an improper payment, not just improper access.
Product teams about to launch facial authentication — a Security Target written before launch costs a fraction of the redesign after.

Has your biometrics been tested against injection — or only against presentation?

CEN/TS 18099:2024 evaluations across all three levels, for Web and mobile platforms. Fixed scope, defined timeline, no hidden cost.

Request an evaluation

Reply within 24h. No commitment. Scope and investment defined in the first conversation.

Frequently asked questions

I already have liveness/PAD certification. Do I need this?

PAD certification answers for in-person attacks and makes no claim about injection. If you present it as injection coverage in an RFP and the technical evaluator on the other side knows the difference, the effect is the opposite of what you intended.

Is CEN/TS 18099 a regulatory requirement?

Not yet. While it is not, having it is a competitive differentiator in RFPs. When it becomes one, whoever already has it simply renews; whoever does not joins the queue with the product on hold.

Do you issue an accredited certificate?

No, and nobody does: CEN/TS 18099:2024 has no formal certification scheme run by an accredited body yet. We deliver a Technical Report and a Letter of Confirmation attesting methodological conformity, with that distinction written into the document itself.

Will it stall my team's roadmap?

The demand on your team is concentrated in two fronts: a few hours for the Security Target and recruiting volunteers for the legitimate transactions. The technical execution is ours, against a test environment.

What if my product does not pass?

Then you found out, in a controlled environment and under NDA, what a fraudster would have found out in production — and you have the remediation window to fix it before any verdict is consolidated. The expensive scenario is passing your own internal test and failing real onboarding.