Use layered assurance rather than relying on any single signal. Biometric verification, liveness detection, device binding, and risk-based step-up checks should all support one another, especially for onboarding, recovery, and high-value transactions. The goal is to prove that a live person is present and authorised, not just that a facial or vocal pattern matches.
Why This Matters for Security Teams
Deepfake-enabled fraud changes human identity from a static verification problem into a live adversarial contest. Attackers no longer need to steal a password if they can convincingly impersonate a person during onboarding, account recovery, or payment approval. That shifts the control objective from “match the face or voice” to “prove a real, authorised person is present and acting under expected conditions.” Current guidance from the NIST Cybersecurity Framework 2.0 supports layered, risk-based controls rather than single-factor trust.
This is also where identity operations and fraud operations overlap. Weak recovery flows, over-trusted call centres, and overly permissive step-up exceptions create a path around strong primary authentication. The broader NHI lesson is relevant here: when identity evidence is treated as durable truth instead of context that can be forged, compromised, or replayed, attackers look for the weakest adjacent control. NHIMG research shows that identity failures often persist because organisations do not see the full attack surface early enough, especially when credentials and approval paths are scattered across systems in ways that are easy to exploit. For deeper context, see Ultimate Guide to NHIs and 52 NHI Breaches Analysis.
In practice, many security teams encounter deepfake fraud only after a recovery workflow, onboarding exception, or executive payment approval has already been abused.
How It Works in Practice
Protection works best when organisations stack independent signals and evaluate them at the moment of the request. Biometric checks can still be useful, but they should be paired with liveness detection, device binding, session continuity, and behavioural risk scoring. If a face scan is perfect but the device is new, the network path is unusual, and the request is asking for a privileged change, the system should not trust the biometric alone.
For high-risk journeys, the strongest pattern is layered assurance with step-up controls. That usually means:
- Binding the identity session to a known device or cryptographic possession factor.
- Using liveness checks that look for active interaction, not just photo or video replay.
- Applying out-of-band verification for recovery, payout changes, and admin resets.
- Requiring human review when the transaction is high impact or the risk score is elevated.
- Logging the full decision path so fraud and security teams can reconstruct why access was approved.
This approach aligns with identity assurance guidance in NIST Cybersecurity Framework 2.0, but current practice is still evolving on how much weight to give each signal. The important point is that deepfakes exploit trust in appearance, voice, and familiarity, so authorisation has to move from one-time verification to real-time risk evaluation. That is especially important in the same kinds of identity paths discussed in Top 10 NHI Issues, where hidden trust assumptions routinely outlive the controls meant to enforce them.
These controls tend to break down in high-volume contact centres and outsourced recovery environments because staff are under pressure to minimise friction and override weak signals.
Common Variations and Edge Cases
Tighter identity assurance often increases user friction and operational overhead, so organisations must balance fraud prevention against abandonment and support load. That tradeoff is real, especially when the same controls are used for low-risk logins and high-risk transactions. Best practice is evolving, but there is no universal standard for how aggressively to challenge every user journey.
Some journeys justify stronger proofing than others. Account recovery, password reset, payment beneficiary changes, and executive communications should usually receive more scrutiny than routine login. In regulated environments, policy should define when a step-up is mandatory and when exceptions are allowed, with those exceptions tightly monitored. For example, organisations may accept a lower-friction path for low-value activity while requiring stronger proof of possession, device reputation, and live challenge-response for sensitive actions.
Another edge case is accessibility. Voice, face, and mobile-device signals can all be affected by disability, injury, travel, or device loss, so fraud controls should include an alternate path that is equally rigorous but not dependent on a single modality. Deepfake resistance is not just about refusing suspicious input; it is about designing recovery and exception handling so attackers cannot exploit the very process meant to help legitimate users. The Ultimate Guide to NHIs is useful here as a reminder that identity systems fail when trust is too static and visibility is too narrow.
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 | PR.AA-1 | Identity proofing and authentication should be risk-based and layered. |
| NIST AI RMF | Fraud controls should address trustworthy AI-driven identity decisions. | |
| OWASP Agentic AI Top 10 | A2 | Deepfake fraud often exploits manipulated inputs and trust assumptions. |
Govern deepfake exposure by documenting, testing, and monitoring identity decision points.
Related resources from NHI Mgmt Group
- How can organisations prepare identity programmes for AI-enabled access?
- When should organisations retire or rotate a non-human identity?
- When should organisations treat an admin account as a high-risk non-human identity?
- How should organisations govern API partner onboarding as a non-human identity process?