Your onboarding flow asks the user to blink, turn their head, follow a dot on the screen. They do everything right. Liveness approves.
And it approves correctly — because the video is of a live person who blinks, turns their head and follows the dot. That person simply is not the account holder. And, increasingly, that person does not exist.
The fraudster was never in front of the camera. They installed a virtual camera on their own machine, fed that fake device an AI-generated video, and your SDK received a stream that, from the application's point of view, is indistinguishable from a real webcam. No screen artifacts. No paper edges. No mask texture. There was no presentation to detect at all.
The attack your defense was not built to see
This is an injection attack: the biometric sample is replaced after capture and before analysis. And it has a property that should keep any head of fraud awake: it is scriptable.
A presentation attack requires a fraudster physically present, with a physical artifact, in front of one device at a time. It does not scale. A successful injection attack runs on a server, in parallel, thousands of times per hour, at a marginal cost close to zero per fraudulent identity. It is the difference between a mugger and a botnet.
If your biometric product has never been tested against this vector, you do not know whether it holds. And never tested is the situation of the overwhelming majority of systems in production today.
The certificate you already have does not cover this
This is the part that is expensive to learn late. There are two families of attack against biometric systems, governed by different standards:
| 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 |
| What you probably have | A certificate | Nothing |
PAD defenses analyze the image looking for signs that a fake presentation occurred. An injection attack produces none of those signs — because there was no presentation. The detector looks at the frame and sees exactly what it expects to see in a legitimate capture.
A product can hold a high-level PAD evaluation and fall to 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.
If your biometrics vendor answers we have liveness certification when you ask about injection, they have just answered a different question.
The market's new yardstick — and the window of advantage
UNE CEN/TS 18099:2024 — Biometric data injection attack detection is the first European technical specification to address this vector with formal methodology: tiered evaluation levels, objective coverage floors, traceable attack rating and binary pass criteria.
If you sell biometrics. It is the first document with which you can prove injection resistance in a way that is comparable, auditable and accepted by the buyer's legal team. While it remains an exception in the market, it is a direct competitive differentiator in RFPs. When it becomes a standard requirement — and it will — it is the price of entry.
If you buy biometrics. It is the question that separates vendors with engineering from vendors with marketing. Five minutes discussing a vendor's Security Target tells you more about their maturity than an entire sales deck.
The window of advantage exists now and is not permanent. The number of biometrics vendors with a formal IAD evaluation still fits on one hand. Being one of them today is a sentence that sells. In two years, it is the bare minimum.
What you receive at the end
Two documents, with distinct roles.
Letter of Confirmation — the commercial asset
A public, summarized document attesting the conformance level achieved, the product and version evaluated, and the methodology applied. This is the piece that goes to:
- RFP responses and public tenders
- your corporate customer's due diligence
- sales material and website
- discussions with the buyer's risk and compliance teams
- investor diligence and M&A
Technical Report — the engineering asset
A confidential document with the nine-section structure required by the standard: the full matrix of executed attacks, what held and what did not, the rating of each finding, bona fide metrics, component version analysis and recommendations. In practice it becomes a product security roadmap — prioritized, evidence-backed, with the cost of each attack estimated by the standard's own yardstick.
A point of honesty other vendors omit: CEN/TS 18099:2024 does not yet have a formal certification scheme run by an accredited body. There is no accreditor-issued seal today. Anyone promising one is selling something that does not exist — and you find out at the first serious question from your customer's legal team.
What does exist, and what international labs practice for equivalent standards, is exactly the model above: Technical Report + Letter of Confirmation attesting methodological conformance. It is verifiable, it is defensible, and it is what Antisec delivers — with that distinction written into the document itself.
Three levels. Pick the one your market demands.
| 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 detail that saves money: a cycle scoped for the High level automatically covers the floors of the levels below. That allows recording the verdict for all three levels in a single evaluation, instead of contracting three independent engagements. That is how we structure projects by default.
Not sure which level your market will demand? That is a 20-minute conversation, not a proposal. Talk to a specialist.
What has to be true for you to pass
The standard demands two things at once — and this is where most products find out where they actually stand.
1. 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-level evaluation — it is recorded as residual risk. A payload replay that anyone reproduces in fifteen minutes fails every level. The rating is what makes the result fair and comparable.
2. Do not mistreat the legitimate user. The standard requires the real-user rejection rate (BPCER) to stay within target — recommended at 15% maximum — measured over at least 300 legitimate transactions collected during the evaluation.
That second criterion is what blocks the lazy way out: a paranoid system that rejects half of its real customers would sail through the first criterion. The standard closes that door. And that is why a well-run IAD evaluation is not only a security seal — it is also a friction number your product team can take to the board.
Why Antisec
An IAD evaluation is worth exactly as much as the real capability to build the attack. Any consultancy can fill in a form. Building the virtual camera pipeline, intercepting the boundary between JavaScript and WebAssembly, defeating integrity watchdogs, assembling the replay 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 in offensive security
- 10+ years of continuous offensive operation
- 100% satisfaction rate
- 0 undetected incidents after our pentests
- Manual exploitation, run by senior specialists — not automated scanning with a repackaged report
And three things specific to this service line:
The instrumentation is 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 for lab assembly.
Declared scope, including what we do not test. PAD and secure element evaluation are outside the scope of this standard, and that is written in the document. A client receiving our report knows exactly what was covered — and that is what makes the document survive their own customer's audit.
Remediation window. If a test fails, you do not get a rejection stamp. You get the formal communication, you fix it, we re-execute, and the matrix resumes where it stopped. The evaluation exists to make your product defensible — not to produce a bad verdict nobody can act on.
How the project runs
Six stages, with your team involved only where it is indispensable:
| Stage | What it requires from you | |
|---|---|---|
| 0 | Security Target — formal document of assets, threats and security functions, signed by both parties | A few hours of the product team |
| 1 | Mapping of attack methods and instruments against your product | Nothing |
| 2 | Execution of the full matrix, with evidence for every attack — including the blocked ones | A stable test environment |
| 3 | Rating of each finding by the standard's methodology | Nothing |
| 4 | Legitimate user metrics — the 300+ transactions | Volunteers (start on day 1) |
| 5 | Issuance — Technical Report + Letter of Confirmation | Nothing |
The real bottleneck is not us. The part Antisec controls 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 is why the guidance is always the same: that track starts on day 1, in parallel — not after the technical testing is done.
But I am not required to have this yet
Correct. And that is exactly why now is the right moment. Four objections we hear, and the honest answers:
We already have liveness/PAD certification
It answers for in-person attacks. It 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 the one intended.
It is not a regulatory requirement yet
Yet. While it is not, having it is a differentiator. When it becomes one, whoever has it simply renews; whoever does not joins the queue with the product on hold. And the queue formed by an entire market moving at once is not short.
It will block my team's roadmap
The demand on your team concentrates in two places: a few hours for the Security Target and the volunteer collection. The technical execution is ours, against a test environment. No product sprint gets hijacked.
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 not failing the evaluation. It is passing your own internal test and failing real onboarding, with losses, a reportable incident and your corporate customer watching.
Who should already be in this conversation
- Biometric SDK, liveness and KYC vendors — for you, the Letter of Confirmation is a sales asset, not a compliance cost.
- Banks, fintechs and acquirers integrating third-party biometrics — the right question to ask your vendor is three sections above.
- Insurers, healthcare and the public sector running remote proof of life — where a successful injection becomes an improper payment, not merely improper access.
- Product teams about to launch facial authentication — a Security Target written before launch costs a fraction of the redesign afterwards.
What to do today, for free
Three checks your team can run this week without hiring anyone:
- Replay test. Capture the payload of a successful biometric verification. Tomorrow, in a new session, resend the same payload. If the backend accepts it, you have a foundational problem that no deepfake detection model will solve.
- SDK load integrity. If your biometric SDK script comes from a CDN without integrity verification, the attacker does not need to defeat the SDK — they replace the SDK.
- Where the decision lives. If the answer this transaction is legitimate is produced in the user's browser, it is produced on the adversary's machine.
If any of the three made you uncomfortable, the next conversation is with us.
Has your biometrics been tested against injection — or only against presentation?
Antisec runs biometric injection attack detection evaluations under UNE CEN/TS 18099:2024, across all three levels, for web and mobile platforms. Fixed scope, defined timeline, no hidden cost — and with the distinction between methodological conformance and accredited certification written into the document itself, because that is how an attestation survives the audit of whoever reads it.
Deliverables: Security Target · Full attack matrix · Technical Report · Letter of Confirmation · Results presentation for the board.
Request a security evaluation — response within 24h, no commitment. Scope and investment defined in the first conversation.
