Subscribe to the Non-Human & AI Identity Journal

Who should own deepfake defence across the identity programme?

Ownership should sit across IAM, fraud, and security operations because deepfake risk crosses authentication, proofing, and transaction approval. A single team can manage controls, but only a shared policy can keep identity confidence consistent across the full user journey.

Why This Matters for Security Teams

Deepfake defence is not a narrow anti-fraud problem and it is not just another IAM control. It sits where identity proofing, authentication, help desk recovery, payment approval, and account take-over risk collide. That is why ownership has to span IAM, fraud, and security operations rather than sit inside a single technical tower. Current guidance suggests that identity confidence must be measured across the whole user journey, not only at sign-in, because attackers now use synthetic voices, video, and text to bypass human judgement as often as they bypass systems. The operational challenge is visible in the broader NHI picture as well: NHI Mgmt Group notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys in the Ultimate Guide to NHIs, which shows how identity abuse often starts well before the final fraudulent action. NIST’s NIST Cybersecurity Framework 2.0 reinforces the same point by treating identity as an enterprise governance issue, not a point product issue. In practice, many security teams encounter deepfake fraud only after a convincing social-engineering chain has already reached a payment, password reset, or executive approval step, rather than through intentional detection design.

How It Works in Practice

Effective ownership is usually a shared operating model with one accountable lead and multiple control owners. IAM typically owns authentication, proofing standards, session assurance, and recovery workflows. Fraud teams own anomalous transaction detection, mule-account patterns, and impersonation signals that affect business decisions. Security operations owns alerting, incident response, and threat intelligence correlation. The point is to align policy, telemetry, and escalation paths so a synthetic-identity event can be stopped whether it appears at enrollment, login, support, or approval.

In practice, the strongest programmes combine four layers:

  • Proofing and step-up checks for high-risk onboarding or recovery events.
  • Authentication controls that can challenge voice, image, or behavioural anomalies without blocking low-risk flows.
  • Transaction guardrails that require independent verification for payment, bank detail, or privilege changes.
  • Incident playbooks that define when fraud signals become an identity incident and when IAM must revoke, reset, or re-proof.

This is where identity governance overlaps with the broader non-human identity problem. The same discipline that reduces exposure from leaked secrets and over-privileged service accounts in the Top 10 NHI Issues also helps teams manage trust decisions under pressure: know what is authorised, know who can approve it, and know how to revoke it quickly. NIST’s identity and risk guidance, including the NIST Cybersecurity Framework 2.0, supports this kind of cross-functional control mapping because no single team can see all the signals. These controls tend to break down when recovery channels are fragmented across business units because inconsistent approval rules create the easiest path for a convincing impostor.

Common Variations and Edge Cases

Tighter deepfake controls often increase friction in customer service, executive workflows, and high-value transactions, requiring organisations to balance assurance against user experience and operational speed. That tradeoff is real, and best practice is evolving rather than universally settled. Some environments will use stronger controls only for high-risk events such as wire transfers, privileged account changes, and password resets, while leaving routine interactions on lighter checks. Others may add liveness detection, callback verification, or out-of-band approval, but none of these is sufficient on its own.

The main edge case is decentralised ownership. If IAM owns the tooling but fraud owns the business loss threshold, and security operations owns the incident workflow, the programme can still fail unless there is one policy standard for escalation. This is especially true in organisations with outsourced support desks, multiple brands, or regional compliance requirements, where local exception handling can silently weaken identity assurance. The most defensible model is a shared policy with clear executive sponsorship and documented RACI, not a loose committee. NHI Mgmt Group’s 52 NHI Breaches Analysis shows how identity failures often spread when ownership is fragmented and response actions are inconsistent. In environments with heavy call-centre dependence or high-touch concierge recovery, that fragmentation becomes the weak point because attackers can target the least standardised human handoff.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 GV.OC-1 Deepfake defence needs cross-functional ownership and business context.
OWASP Agentic AI Top 10 A3 Identity trust failures are exploited through impersonation and social engineering.
NIST AI RMF GOVERN AI-generated impersonation is a governance and accountability issue.

Treat synthetic identity attacks as an identity assurance problem across authentication, recovery, and approvals.