This guide focuses on the single deepfake threat most KYC contracts don't cover: injection attacks, the class of attack that bypasses the camera entirely rather than trying to fool it. It is where the largest gap between vendor marketing and vendor capability currently sits, and it is where the right set of procurement questions separates serious providers from the rest.

Most KYC vendor contracts signed before 2024 are designed for a threat landscape that has already moved on.

They emphasize liveness checks, reference ISO/IEC 30107-3, and promise accuracy rates above 99%. While those claims may still be technically valid, they’re becoming less relevant to the risks we face today.

The attacks that broke through in 2025 did not try to fool liveness. They bypassed the camera entirely. iProov's 2026 Threat Intelligence Report recorded a 741% year-on-year increase in injection attacks against iOS devices. Gartner Research had already flagged a 200% rise in injection attacks back in 2023. The trajectory has not reversed, it has accelerated.

If you are responsible for signing, renewing, or managing a KYC vendor contract at an SMB in 2026, the single most valuable question is no longer "how accurate is your liveness detection?" It is: "Can you prove, with independent evidence, that your system detects injection attacks?"

Most vendors cannot. This issue walks through what the right answer looks like, what evidence to demand, and the specific mistakes to avoid in the procurement conversation.

Injection attacks are a separate control category and most KYC contracts don't cover them.

A presentation attack asks: can I fool the camera?

An injection attack asks: why use the camera at all?

That distinction is not academic. It is the reason your current vendor's certifications may be irrelevant to your actual threat.

ISO/IEC 30107-3, the standard most Identity Verification vendors point to, is explicitly scoped to Presentation Attack Detection (PAD). It measures how well a system rejects spoofs shown to the camera: printed photos, phone screens, masks.

Injection attacks operate at a completely different layer. Instead of manipulating what’s in front of the camera, the attacker replaces the camera feed itself - using a virtual camera driver, an emulator, intercepted API calls, or even browser-side JavaScript hijacking. As a result, the synthetic video enters the verification pipeline appearing as a legitimate capture. The PAD system never really gets a chance, it’s analyzing a feed that was already fabricated upstream of the controls it relies on.

The common attack tooling include virtual camera software like ManyCam, OBS studio, Decart AI, hardware video sticks, JavaScript injection, smartphone emulators, and direct network interception. All of these tools are widely available and most of these does not require sophisticated skills.

The regulatory response is now emerging in two distinct stages.

First, CEN Technical Specification CEN/TS 18099:2025 marks the first formal European effort focused specifically on biometric injection attacks. Published in 2025, it introduces Injection Attack Detection (IAD) as a dedicated control layer, designed to complement, not replace, existing presentation attack standards like ISO/IEC 30107-3. The specification defines injection attacks, outlines attack methods and tools, and provides guidance for building and testing IAD systems.

Second, at the global level, ISO/IEC 25456 is currently under development as the international standard for biometric data injection attack detection. It builds directly on the European work and aims to standardize definitions, threat models, and evaluation methods for detecting and mitigating these attacks across biometric systems.

The standards are taking shape. Testing methodologies and frameworks are being defined. What’s still missing, especially in many SMB procurement processes, is not technology, but awareness: someone at the table who knows these standards exist and understands what to ask for.

These are not gotcha questions. A vendor with genuine injection-attack coverage will answer each of these questions.

CEN/TS 18099 defines two evaluation tiers: Substantial and High. The difference is the breadth of attack methods and instruments tested. Independent testing labs such as CLR Labs and Ingenium Biometrics perform the assessments.

Expect one of three answers:

As of late 2025, a small number of vendors have achieved certification : Unissey was the first to reach High-Level IAD certification for web-based liveness, and iProov has published its CEN/TS 18099 evaluation. The list will grow, but the point is that certification is verifiable. Vague claims are not.

This is the device-attestation question. The answer should mention specific technical mechanisms, not marketing language.

Look for references to:

If the vendor cannot describe at least three of these without reaching for a slide deck, they are doing server-side analysis only, which fails against virtual camera injection.

Public red-team validation is the strongest single indicator of a serious vendor.

The gold standard reference is the MITRE ATLAS case study from December 2025 titled "Deepfake Injection Evades Mobile KYC Liveness Verification." iProov's red team used Faceswap, OBS, and a non-rooted Android virtual-camera app, all publicly available, to fully bypass a commercial KYC flow. The case study is public precisely so vendors can be measured against it.

Ask your vendor directly:

A vendor offering red-team testing as part of the procurement process is signalling confidence. A vendor declining is signalling the opposite.

Ask for a live demonstration. Specifically:

If any of these four produce a "pass" verdict without human review, the system is not injection-resistant, regardless of what the contract says.

NIST SP 800-63-4 : the updated US Digital Identity Guidelines, explicitly requires organisations to prove resistance to both presentation attacks and deepfake injection attacks. iProov was the first vendor to demonstrate Deepfake Resilience under the updated guidelines, which tells you the bar has shifted.

FinCEN's FIN-2024-Alert004 requires US financial institutions to file SARs referencing "FIN-2024-DEEPFAKEFRAUD" when deepfake media is suspected at onboarding, which implicitly requires detection in the first place.

The EU AI Act classifies remote biometric verification as high-risk, mandating documented safety testing under Article 93, with potential fines up to €35 million or 7% of global turnover.

A competent vendor maps their controls directly to the framework relevant to your jurisdiction. A weak vendor talks about "compliance" in the abstract. The difference tells you everything.

After the questions, you need to evaluate the answer against a reference architecture. A vendor whose stack covers these six layers is credible. A vendor missing any two of them has a gap large enough to drive an attack campaign through.

Layer 1 - Device integrity: Play Integrity on Android, DeviceCheck or App Attest on iOS, plus detection of rooted/jailbroken devices, emulators, and known virtual camera drivers.

Layer 2 - Client-side camera binding: A mobile SDK (not a browser-only capture) that binds the camera feed on-device before it can be substituted by a virtual driver or emulator.

Layer 3 - Presentation Attack Detection (PAD): ISO/IEC 30107-3 certified. This remains necessary, presentation attacks have not gone away, they have just stopped being sufficient on their own.

Layer 4 - Injection Attack Detection (IAD): CEN/TS 18099 aligned, with a defined certification level and independent lab report.

Layer 5 - Deepfake forensic analysis: Frame-level and temporal analysis for GAN artifacts, compression inconsistencies, and blending signatures at facial edges. Runs during the session, not after.

Layer 6 - Behavioural and session signals: Device fingerprint stability, IP/geolocation consistency with the ID document, typing cadence, session duration patterns, and velocity checks across the onboarding funnel.

No single layer closes the problem. A vendor selling any individual layer as a complete solution is either confused about the threat model or hoping you are.

Mistake 1: Accepting "99% accuracy" as a meaningful number. Accuracy against what test set? A 99% detection rate against 2023-era deepfakes is a failing grade against 2026 tooling. Always ask for the composition of the evaluation set and when it was last refreshed.

Mistake 2: Assuming certification transfers across products. Vendors with multiple SKUs - web SDK, mobile SDK, server-side API, often hold certification on only one. Confirm which specific product you are buying carries the certification, in writing.

Mistake 3: Treating the SDK as optional. Several vendors offer a "lighter" integration via browser capture, sold on ease of integration. Browser-only flows are structurally more vulnerable to injection because they run in an environment the vendor cannot attest. For any use case above low-value sign-ups, the native SDK is the control, skipping it is buying a weaker product for convenience.

Mistake 4: Signing without a red-team clause. Every contract should include (a) the right to commission an independent red-team test annually, (b) a defined remediation SLA if the test reveals a bypass, and (c) the obligation on the vendor to notify you within a defined window if they discover a successful bypass in the wild.

Mistake 5: Outsourcing the threat model. The vendor's job is to detect attacks. The threat model, what you are actually trying to protect, at what volume, against which attacker profile- is your job. Arrive at the vendor conversation with a documented threat model already drafted. Vendors who push back on specifics are the ones you want. Vendors who accept a vague brief will deliver a vague product.

Weeks 1–2 - Document your threat model: Write down your onboarding volume, fraud loss baseline, the regulatory regime you operate under (FinCEN, EU AI Act, eIDAS 2.0, or equivalent), and your acceptable false-rejection rate. Two pages, maximum.

Weeks 3–4 - Issue an RFP with the five questions above: Score vendors on the specificity of their answers, not the polish. Eliminate anyone who cannot produce a CEN/TS 18099 certification report, a named testing lab, or a red-team methodology.

Weeks 5–6 - Live proof-of-concept: Run the four live test scenarios from Question 4 on each shortlisted vendor's sandbox. Record the results. This is the single highest-signal step in the entire process.

Weeks 7–8 - Independent red-team assessment: Commission a third-party test against the shortlisted vendor's production integration. Ingenium Biometrics, CLR Labs, and a small number of specialist firms offer this. Budget for it - the cost is a small fraction of a single successful synthetic-identity loss.

Weeks 9–10 - Contract with the clauses that matter: Right to annual red-team testing. Vendor notification SLA for in-the-wild bypasses. Minimum certification level maintained for the contract duration. Named product covered, not just "the platform."

Weeks 11–12 - Baseline metrics before go-live: Instrument your funnel to track injection-attempt detection, emulator-session rejection, and velocity anomalies from day one. Without a baseline, you cannot measure whether the vendor is earning their fee.

The quiet truth about KYC procurement in 2026 is that most SMBs buy on the basis of integration speed, pricing, and whichever vendor has the best-looking dashboard. These are rational criteria for a commodity product. Injection-resistant biometric verification is not a commodity product yet, the market is still divided between vendors who have done the engineering work and vendors who have not.

The checklist above really comes down to one simple shift in perspective:

“ Stop asking vendors whether they can detect fakes. Start asking them to prove it - with a named standard, a certified lab, a published report, and a live test you can actually observe.”

That shift changes the entire dynamic. It moves the burden of proof away from the buyer, who would otherwise have to evaluate opaque AI systems and places it on the vendor, who either has independent validation or doesn’t.

For SMBs, with limited budgets and resources, this is one of the only practical ways to distinguish between vendors genuinely keeping up with evolving threats and those repackaging outdated capabilities with modern marketing.

Attackers aren’t slowing down. Regulation isn’t either. The procurement process is where this gap either gets addressed or quietly locked into a long-term contract.