Independent analysis by NHI Mgmt GroupSource article: Daon, “Deepfake Defense Starts Before Detection: Here’s What to Take Away from the Latest Gartner Report” (July 2, 2026)

TL;DR: Deepfake risk in identity verification is driven less by whether a fake can be spotted than by whether presentation and injection attacks can be stopped at the point of introduction, according to Daon. NHI Mgmt Group’s view is that detection-only procurement leaves the real trust failure unaddressed.


At a glance

What this is: NHI Mgmt Group's analysis, drawing on Daon's blog post: Deepfake risk in identity verification is better addressed by stopping presentation and injection attacks early than by relying on detection alone.

Why it matters: This matters because identity verification, hiring, and customer onboarding controls can fail even when deepfake detection appears strong, leaving KYC, account access, and workforce trust decisions exposed.


Context

Deepfake-enabled identity fraud is a governance problem before it is a detection problem. Biometric and remote verification programmes fail when they treat the fake image as the main threat, rather than the route used to deliver it. That shifts the control question from spotting synthetic content to verifying capture integrity and surrounding context.

In practice, the weak point is often the verification workflow itself: presentation attacks exploit the camera-facing moment, while injection attacks exploit the data path between sensor and application. For identity teams, that means assurance has to extend beyond liveness claims into workflow design, control testing, and evidence that the channel itself is trustworthy. Deepfake-resistant identity verification is the natural baseline for that discussion.


Key questions

Q: How should identity teams reduce deepfake and injection risk in remote onboarding and step-up verification flows?

A: Use multi-layer detection that evaluates face, device, camera, and behavior signals together, rather than relying on a single liveness check. That approach helps catch injected video, virtual cameras, emulated devices, and synthetic identity attacks before approval. Teams should also watch for low-friction controls that preserve user experience while tightening fraud screening across high-risk verification steps.

Q: How should identity teams design a face biometric defence against both presentation attacks and injection attacks?

A: Teams should treat face biometric defence as a two layer problem. Presentation attack detection should address spoofs shown to the camera, such as masks, printed photos, and screen replays. Injection attack detection should protect the data pipeline itself, where fabricated media can bypass the camera entirely. Contextual signals from device and location intelligence can add resilience, but they should complement, not replace, independently tested controls.

Q: What should teams do first when deepfake fraud is targeting identity verification?

A: Start with the highest-risk recovery and escalation paths, because those flows often accept weaker proof than initial login. Remove knowledge-based prompts, review call-centre scripts, and require stronger step-up checks wherever an attacker could socially engineer a support agent into resetting access.


Technical breakdown

Presentation attacks and injection attacks

A presentation attack occurs when an attacker puts a fake face, photo, mask, or other artefact directly in front of the sensor. An injection attack bypasses the sensor path entirely and inserts manipulated media into the stream before the application processes it. Both attacks defeat narrow detection logic if controls focus only on image content. The important distinction is that one attack abuses the capture moment while the other abuses the transport and ingestion path. That is why verification assurance has to include both physical capture controls and software-path integrity checks. See the Deepfake-Resistant Identity Verification Guide.

Practical implication: Test identity verification controls separately for sensor-facing fraud and for stream-injection bypasses.

Why presentation attack detection is not enough

Presentation attack detection, or PAD, evaluates whether a biometric system can recognise fraudulent artefacts presented to the camera. It is useful, but it is only one layer because a system may still be fooled upstream, downstream, or through orchestration gaps. A solution that only scores well on PAD can still fail if the attacker never has to present anything to the camera at all. That is why assurance should be built around the full verification workflow, not around a single test result or a narrow vendor claim.

Practical implication: Require evidence that the verification workflow is protected at the capture, transport, and decision layers.

Contextual signals create the second line of defence

Contextual signals are the surrounding risk indicators that help an identity system spot anomalies even when the biometric event itself looks plausible. Device reuse, location mismatch, abnormal velocity, repeated identity attributes, and unusual interaction patterns can all indicate fraud that image-only controls miss. This approach does not replace biometric verification. It strengthens the decision by checking whether the event makes sense in context. In identity governance terms, the system is not just asking whether a face is real. It is asking whether the whole transaction is consistent with expected behaviour. Read Identity detection rule pack.

Practical implication: Combine biometric checks with contextual risk signals so one failed layer does not become a successful onboarding or login event.


Threat narrative

Attacker objective: The attacker aims to be accepted as a legitimate person so they can obtain account access, bypass onboarding controls, or enter a trusted workforce or customer flow.

  1. Entry occurs when the attacker uses a presentation attack or an injection attack to reach the identity verification workflow.
  2. Credential_harvested or escalation follows when the fraudulent identity passes the control point and is accepted as genuine by the programme.
  3. Impact occurs when the false enrolment, account access, or hiring decision opens access to KYC processes, customer accounts, or sensitive internal systems.
  • United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.

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

Deepfake defence is a verification governance problem, not a detection race. The control failure is usually not that the organisation lacks an AI model capable of spotting synthetic content. The failure is that it has not governed the identity path well enough to stop fraudulent media from entering the process in the first place. That means assurance belongs in capture integrity, channel integrity, and contextual decisioning, not only in model scoring. The practitioner conclusion is to treat deepfake resistance as an identity workflow control, not a standalone security feature.

Presentation attack and injection attack are different failure modes, so they need different tests. A camera-facing artefact attack and a stream-bypass attack both target the same business process, but they exploit different layers of the stack. Conflating them leads teams to over-trust a single validation method and under-invest in transport-path integrity. The practical result is a brittle assurance model that looks complete on paper but leaves a blind spot in production. The practitioner conclusion is to test the full path, not just the image.

Deepfake-resistant identity verification is now a trust architecture issue. The real governance question is whether identity proofing can survive synthetic media without creating false confidence in the result. That connects identity verification to fraud controls, workforce onboarding, and access governance in one decision chain. Where organisations rely on remote verification for hiring, account recovery, or regulated onboarding, the boundary between identity and fraud has already collapsed. The practitioner conclusion is to align verification design with the business risk of false acceptance.

Contextual identity signals are the named concept practitioners should operationalise. A verification event should be judged against device, location, velocity, and interaction context, because image-based controls alone cannot establish trust. This is especially important where deepfake attacks target remote onboarding or high-value account recovery flows. The broader implication is that identity teams need orchestration across biometric, document, and behavioural signals, with decision logic that can reject a plausible-looking event when the surrounding evidence does not fit. The practitioner conclusion is to make contextual signal quality a procurement and tuning requirement.

Procurement criteria must shift from vendor promises to evidential assurance. Claims about detection accuracy are not enough when the market lacks a standardised way to compare those claims. Organisations should insist on test evidence, independent validation, and a clear view of how the vendor handles both presentation and injection attacks. That is the difference between buying a reassurance statement and buying a defensible control. The practitioner conclusion is to evaluate proof, not prose.

What this signals

Remote identity proofing is moving from a capture problem to a governance problem. The organisations most exposed are the ones that still treat the biometric event as the control rather than the start of the control chain. As deepfake tooling improves, the assurance gap will increasingly sit in workflow integrity, contextual scoring, and evidence quality rather than in whether a single model can spot a fake.

Contextual signal orchestration will become the differentiator in identity verification programmes. Device, geography, behaviour, and velocity checks are no longer optional add-ons if the organisation relies on remote onboarding or account recovery. The practical signal is clear: teams that cannot combine those inputs into a decision model will keep overestimating the trustworthiness of successful verifications.


For practitioners

  • Define separate test cases for presentation and injection attacks Assess whether the verification stack can withstand camera-facing artefacts and stream-bypass manipulation as distinct control failures.
  • Require independent PAD and IAD evidence before procurement Make ISO/IEC 30107-3 testing and injection attack validation part of acceptance criteria, with no contract award on unverified accuracy claims.
  • Add contextual risk signals to every remote verification flow Use device, location, velocity, and interaction signals to challenge suspicious enrolment or login events even when the biometric check appears clean.
  • Review onboarding and account recovery for false-acceptance risk Map where a synthetic identity could gain approved status and then reach regulated KYC steps, customer accounts, or internal systems.
  • Document a defensible verification control standard Set minimum assurance requirements for sensors, transport paths, orchestration logic, and fallback reviews so teams can prove the process is controlled.

Key takeaways

  • Deepfake defence fails when teams focus on content recognition instead of the full identity workflow that admits the content.
  • The main exposure is false acceptance in onboarding, account recovery, and other trust decisions that depend on remote verification.
  • Presentation and injection paths need separate control testing, and contextual signals are what keep a plausible fake from becoming a trusted identity.

Related NHI Mgmt Group resources: Deepfake-Resistant Identity Verification Guide · Identity detection rule pack · Detection Engineering for Non-Human Identities Guide · Poland ArcGIS password leak 2023


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, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while GDPR defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST SP 800-63SP 800-63A — Enrollment and Identity ProofingRemote identity verification and onboarding are the core subject of this analysis.
Recommendation — Strengthen identity proofing workflows so remote onboarding resists false acceptance and synthetic identity abuse.
GDPRArt.32 — Security of ProcessingBiometric verification programmes process personal data and need appropriate security controls.
Recommendation — Apply security-of-processing controls to biometric verification data and supporting signals.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsFalse acceptance can lead directly to unauthorized access decisions in identity-driven workflows.
Recommendation — Treat remote verification failures as authorization exposure and tighten decision controls accordingly.
CIS Controls v8CIS-5 — Account ManagementAccount recovery and onboarding flows are where synthetic identities can become active accounts.
Recommendation — Review account-creation and recovery paths for weak identity proofing and tighten approval gates.

Key terms

  • Presentation Attack Detection (PAD): Presentation Attack Detection (PAD) is the set of checks used by biometric systems to tell a live person from a fake or replayed presentation, such as a photo, mask, video, or synthetic sample. Defenders assess PAD strength, failure handling, and bypass resistance, because weak PAD lets impersonation succeed.
  • Injection Attack Detection: Injection Attack Detection, or IAD, is the ability to identify when a biometric capture stream has been intercepted, replaced, or manipulated before it reaches the verifier. It extends assurance beyond the face or voice itself and tests whether the endpoint, sensor path, and media pipeline can be trusted.
  • Contextual Risk Signal: A contextual risk signal is a behavior event that becomes meaningful only after it is combined with surrounding data such as identity, permissions, and threat activity. In phishing programs, a click is not equally risky for every user. Context determines whether the event is minor noise or a meaningful security concern.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle thinking that supports stronger verification programmes. It helps security and identity practitioners connect governance, assurance, and operational control across the wider identity stack.
NHIMG Editorial Note
Published by the NHIMG editorial team on November 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org