TL;DR: Identity verification vendors are converging on similar deepfake claims, but adversarial testing exposes whether fraud controls actually hold under injection attacks, synthetic identities, and edge-case policy gaps, according to Incode. In a market where 75% of enterprise buying decisions happen outside IT, buyer diligence now has to include how the system behaves under realistic fraud pressure.
At a glance
What this is: This is an analysis of why adversarial testing, not marketing claims or isolated certifications, is becoming the practical trust test for identity verification controls.
Why it matters: It matters because identity verification decisions increasingly sit outside security teams, yet the fraud paths being tested can expose weaknesses in KYC, liveness, and exception handling that directly affect identity governance.
Context
Identity verification programmes often fail at the edges, not in the core matching engine. Exception handling, inconsistent policy enforcement, and buying decisions made outside security review create openings that fraudsters can exploit even when the underlying product appears strong on paper.
In this topic, adversarial testing is a governance control as much as a technical one. It forces buyers to ask whether an IDV system has been tested against realistic fraud techniques, including deepfakes, injection attacks, and synthetic identity combinations, rather than only against controlled benchmark conditions.
Key questions
Q: What breaks when IDV vendors are only tested against benchmark conditions?
A: Benchmark-only assurance usually misses the conditions where fraud actually succeeds: policy exceptions, channel-specific thresholds, and software-based manipulation of the capture stream. A control can score well in a lab and still fail in production if it is never challenged across the full journey. The failure is not just technical. It is governance consistency across the operating model.
Q: Why do deepfake-resistant controls still leave fraud exposure?
A: Because deepfakes are only one attack path. Fraudsters can combine synthetic identities, replay, injection, and inconsistent policy enforcement to find the weakest route through the identity journey. If the control only proves resilience in one mode, the residual risk shifts to the untested channels, especially where exception handling or re-verification rules differ by business context.
Q: How do security teams evaluate whether IDV controls are actually working?
A: They should look for evidence from adversarial testing that mirrors current attack behaviour, then confirm that findings were remediated across policy, workflow, and ownership layers. Strong controls are visible in repeatable resistance to realistic abuse, not in isolated certification badges. If the testing never touches edge cases, the result is assurance theatre rather than control validation.
Q: Should identity governance review sit inside business-led procurement for IDV?
A: No. Business-led speed is useful, but delegated procurement often creates inconsistent assurance levels across departments. Identity governance should review risk acceptance, control thresholds, and exception handling before adoption. Otherwise the organisation ends up with multiple trust standards, which is exactly the condition fraudsters exploit most effectively.
Technical breakdown
Why certifications do not cover injection attacks
Controlled certifications and benchmark tests usually measure performance against known, bounded threats such as presentation attacks in front of a camera. Injection attacks are different because the fake signal enters the verification stack through software, not through the physical capture path. That means a system can appear resilient in a lab while still being exposed to video-stream manipulation, replay tooling, or manipulated inputs that bypass the conditions the benchmark was designed to test. For IDV governance, the gap matters because liveness and face-matching scores do not tell the whole story when the attacker never uses the camera path the test assumed.
Practical implication: require testing that covers software injection paths, not only camera-presented spoof attempts.
How fraud red teams probe the full verification flow
A fraud red team tests the end-to-end identity journey the way an actual attacker would, including onboarding, exception handling, re-verification, and policy thresholds. That is materially different from a standard penetration test, which tends to focus on code flaws and infrastructure weaknesses. In IDV, the most useful adversarial work often targets the policy layer, where different rules apply by channel, region, transaction size, or risk score. Those inconsistent controls can become the real bypass surface even when the core engine is sound. Adversarial testing therefore checks both technical detection and operational consistency across the full workflow.
Practical implication: test the whole identity journey, especially exception paths and conditional policy branches.
Why edge cases matter more than headline controls
The highest-risk failures often sit in edge cases that ordinary assurance reviews miss. Synthetic identity combinations, AI-generated documents, and deepfake-assisted attempts do not always break the main model first. They often exploit inconsistent enforcement between teams, channels, or regions, which makes the governance problem more important than the logo on the verification screen. For identity and fraud leaders, that means the key question is not whether a control exists in principle, but whether it holds under realistic attacker behaviour across the exact routes users and fraudsters share.
Practical implication: audit policy consistency across teams and routes before you assume the control surface is uniform.
Threat narrative
Attacker objective: The attacker aims to pass identity verification with a fraudulent identity or manipulated session so they can open accounts, bypass re-verification, or commit fraud at scale.
- Entry occurs through realistic fraud techniques such as deepfakes, video injection, or synthetic identity combinations that interact with the IDV workflow.
- Credential or identity trust is harvested when the attacker exploits exception handling or mismatched liveness thresholds across onboarding and re-verification paths.
- Impact follows when the fraudulent identity is accepted into a customer, account, or transaction flow despite controls that looked effective in benchmark conditions.
Breaches seen in the wild
- Arup deepfake fraud 2024: Deepfakes of Arup's CFO and colleagues on a video call led a Hong Kong employee to transfer HK$200 million (about US$25.6m) to fraudsters.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Adversarial testing is becoming the only meaningful trust signal in IDV procurement. Certification, analyst recognition, and feature claims each answer a different question, but none alone proves a control will survive active abuse. The market now has to distinguish between verified capability and verified resilience. For identity programmes, the practitioner conclusion is simple: trust should be earned under attack conditions, not assumed from product documentation.
Identity governance has moved beyond account proofing into policy consistency. The article shows that the exploitable surface often sits in exception handling, threshold variation, and department-specific buying paths. That makes IDV a governance discipline, not just a fraud-scoring discipline. When HR, finance, operations, and revenue each procure separately, the organisation can end up with multiple trust standards. Practitioners should treat that fragmentation as a control failure, not a procurement detail.
Deepfake risk is only part of the problem; injection is the harder test. A system that resists presentation attacks can still fail when the attacker manipulates the signal after capture. That distinction matters for the identity stack because liveness, document verification, and model confidence are not the same as end-to-end trust. The practitioner takeaway is to evaluate the full verification channel, not just the biometric checkpoint.
Named concept: verification trust gap. This is the gap between a vendor's claimed fraud resistance and the evidence produced when real attackers probe edge cases, policy branches, and operational exceptions. It is where IDV programmes discover that the strongest control is not the feature set but the consistency of enforcement. The practical answer is to measure trust where attackers actually operate.
From our research library:
- Gartner predicts that by 2026, 30% of enterprises will consider identity verification solutions unreliable in isolation because of AI-driven attacks.
What this signals
The practical lesson for identity programmes is that assurance has to move closer to adversarial reality. If teams only validate the happy path, they will continue to miss the policy gaps and exception routes that attackers actively search for.
Verification trust gap: the distance between declared fraud resistance and proven resistance under realistic abuse. Practitioners should close that gap by testing the full identity journey, not just the biometric checkpoint.
For buyers, the governance question is no longer whether an IDV vendor has a deepfake feature. It is whether the organisation can show, in writing, who owns exceptions, who reviews red-team findings, and how inconsistent policy is corrected across business units.
For practitioners
- Test IDV against attacker behaviour, not vendor claims Require adversarial testing that includes deepfakes, injection attacks, synthetic identities, replay attempts, and manipulated onboarding flows. Ask for evidence from realistic attack paths, not just benchmark scores or feature checklists.
- Map exception handling across every identity journey Inventory where the policy differs by transaction type, geography, channel, or business unit, then compare those branches to the controls used in the primary flow. The goal is to find where a fraudster can choose the weakest path.
- Bring security into delegated buying decisions Require security or identity governance review before business units commit to an IDV tool. Fragmented purchasing creates inconsistent assurance levels that attackers can exploit across departments and regions.
- Demand post-test remediation ownership Make sure every red-team finding has an owner, a due date, and a tracked remediation path back into product, policy, or operations. External testing has limited value if the results stop at the report.
Key takeaways
- The core risk is not lack of IDV controls, but lack of proof that those controls survive realistic adversarial pressure across the full identity journey.
- Adversarial testing matters because it exposes the policy and workflow gaps that benchmark tests, certifications, and brochure claims do not cover.
- Identity teams should treat exception handling, delegated buying, and remediation ownership as part of the trust model, not as secondary operational details.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST CSF 2.0 set the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63B — Authentication | The article centres on identity verification and authentication assurance under fraud pressure. |
| SP 800-63A — Enrollment and Identity Proofing | IDV onboarding and proofing flows are a primary focus of the article. | |
| Recommendation — Validate authentication paths against adversarial abuse, not only against controlled benchmark conditions. Review proofing exceptions and onboarding thresholds against adversarial testing results. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article highlights governance gaps in who can gain trusted access through identity flows. |
| Recommendation — Tie identity assurance decisions to explicit authorization thresholds and governance review. | ||
| GDPR | Art.32 — Security of Processing | Identity verification systems processing personal data must be assessed for resilience and security. |
| Recommendation — Assess IDV controls as part of security of processing when personal data and biometrics are involved. | ||
Key terms
- Adversarial Testing: A testing approach that tries to break a policy by using hostile or unexpected inputs. For PBAC and AI access controls, that means probing for prompt injection, role crossover, leakage, and connector drift so the organisation can see whether the policy still holds under pressure.
- Fraud Red Team: A fraud red team is an external or internal testing function that simulates real attacker behaviour against identity and fraud controls. It evaluates the full workflow, including policy exceptions, manual review, liveness checks, and onboarding logic, to see whether an organisation can still make correct trust decisions under pressure.
- Injection attack: An attack that inserts synthetic or manipulated data directly into the verification flow rather than fooling the sensor itself. For identity programmes, this is a control-path problem, because the attacker may bypass the visible presentation layer and exploit the software decision point.
- Activation Trust Gap: The activation trust gap is the difference between trusting data because it is protected and governing it because it is being reused. It appears when organisations move data from backup or archival systems into AI pipelines without reapplying access, sensitivity, and consumer controls.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on July 10, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org