Both, but the governance owner needs to be identity because the control failure happens at verification time. Fraud teams can tune detection, yet identity leaders must define the assurance threshold, the escalation path, and the evidence required before trust is granted.
Why the Control Owner Is Identity Even When Fraud Detects the Pattern
Deepfake fraud is a fraud pattern, but the business failure usually occurs when an organisation accepts an impersonated person, approves an exception, or lets a high-impact action proceed without enough assurance. That makes the control question an identity governance question first: who is trusted, at what assurance level, and what evidence is required before a request becomes action.
Fraud teams still matter because they can tune signals, watch for anomaly patterns, and coordinate response once suspicious activity appears. The governance owner, however, has to define the trust boundary, because the decision to believe a caller, video, voice note, or message is an identity assurance decision, not just a detection decision.
The practical distinction is that fraud reduces loss after suspicious behaviour is visible, while identity governance sets the minimum bar for trust before a sensitive workflow can continue. If those are split too loosely, teams end up detecting ever more convincing impersonation after the organisation has already granted access, approved a transfer, or changed account state.
Where Deepfake Fraud Sits in the Identity Lifecycle
Deepfake attacks exploit verification moments: onboarding, account recovery, payment approval, executive override, help desk reset, supplier change, and any other step where a human or system accepts a claimed identity as sufficient. That is why the issue belongs in lifecycle and access governance, because the real control is deciding when identity evidence is strong enough to create, modify, or authorise trust.
In practice, organisations need to treat deepfake-resistant verification as a policy decision, not an ad hoc judgment by the analyst on duty. A Identity Proofing and KYC Guide is useful where the workflow depends on assurance levels, liveness checks, and escalation paths before trust is granted.
For internal operations, the same logic applies to privileged requests and sensitive changes. IAM and IGA Basics helps frame the difference between authentication, authorisation, provisioning, and access review so teams do not confuse a convincing interaction with a valid trust decision.
When the process involves service desk resets, executive approvals, or supplier banking changes, the organisation should also think in terms of high-risk identity lifecycle events. That is where Access Reviews and Certification Guide is relevant, because recurring review and closed-loop remediation reduce the chance that weak trust decisions persist.
How to Divide Fraud Detection, Governance, and Escalation
The cleanest operating model is to let fraud own behavioural detection and case analysis, while identity governance owns the assurance policy, verification controls, and approval thresholds. Fraud should answer “does this look synthetic or deceptive?”, but identity should answer “is this sufficient evidence to trust, delegate, or authorise action?”
This becomes especially important where impersonation can bypass privileged workflows. Deepfakes, Social Engineering and AI Impersonation Guide is relevant because it centres the verification methods that should precede payment, reset, or override decisions.
Organisations should also align escalation with the value of the action, not the novelty of the attack. A routine request can be handled by standard checks, but a high-value transfer, a credential reset, or a change to trusted contact details should trigger stronger proof, independent confirmation, and an explicit exception path if the evidence is incomplete.
Where there are role conflicts or separation-of-duties risks, governance should be even stricter. Segregation of Duties (SoD) Guide supports the idea that some requests should not succeed just because one channel looks legitimate.
Risk and Threat Considerations
Deepfake fraud is dangerous because it attacks the trust assumption at the exact moment a process is willing to grant access, release funds, or change authority. The main risk is not only that the fake looks convincing, but that organisations often lack a defined assurance threshold for when additional proof is required.
Failure mechanism: An attacker uses synthetic voice, video, or chat to satisfy a human verifier, then pushes the target process through a trusted channel before scepticism or secondary review can intervene.
Impact: The result can be fraudulent payments, account takeovers, unauthorized resets, policy bypass, or a long-lived trust error that persists until the organisation notices the mismatch.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Deepfake fraud often exploits weak verification and credential recovery paths. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | External callers and customers may be the verification subject in deepfake-driven fraud. | |
| AC-6 — Least Privilege | Fraud impact grows when impersonation can trigger excessive authority or approvals. | |
| Recommendation — Tighten authenticator lifecycle controls before allowing high-risk resets or overrides. Apply stronger identity proofing for externally initiated high-risk requests. Restrict approval and override power to the minimum necessary roles. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | The question is about who owns trust decisions and assurance thresholds. |
| A.5.17 — Authentication information | Deepfake fraud often targets secrets, recovery steps, and trust signals. | |
| A.5.18 — Access rights | Impersonation becomes damaging when it can change access or authorise sensitive actions. | |
| Recommendation — Define ownership for identity verification and exception handling. Protect authentication and recovery information used in verification workflows. Review and limit access paths that deepfake abuse could trigger. | ||
Practitioner Guidance
What to prioritise: Set one owner for the verification standard, and make that owner accountable for the assurance threshold on high-risk requests. Fraud teams can feed evidence into the process, but they should not be left to decide whether a request is trusted enough to proceed.
What to verify: Require the verifier to check whether the requested action is reversible, whether the channel is independent of the claimed identity, and whether the evidence would still hold if the voice or video were synthetic. If not, the workflow needs stronger out-of-band proof.
Decision rule: If the request can move money, reset credentials, change beneficiary data, or override controls, treat it as an identity assurance event and not as a simple fraud alert.
Practitioner takeaway: Deepfake fraud becomes manageable when identity governance defines the trust bar and fraud detection supports it, rather than when fraud is expected to compensate for weak verification after the fact.
Related resources from NHI Mgmt Group
- Should organisations treat mobile malware as an identity governance issue?
- When should organisations treat a data breach as a customer identity and fraud issue rather than only a technical incident?
- When should organisations treat a SaaS platform as an identity governance issue?
- Should organisations treat AI-driven exposure as a data governance issue or an identity issue?