How should organisations verify requests when deepfakes can imitate trusted people?

Why This Matters for Security Teams

Deepfake audio and video have changed the trust model for approvals, payroll changes, wire transfers, account recovery, and emergency access. The problem is not only that a fake voice can sound convincing. It is that the request itself may be optimized to trigger urgency, confusion, or social pressure while bypassing normal review. A believable impersonation can succeed if teams treat identity as something verified once, rather than something that must be confirmed at the point of action. NIST’s NIST SP 800-207 Zero Trust Architecture reinforces the idea that trust should be re-established for each request, not assumed from prior context. For organisations managing digital identities and secrets, the same principle applies to human approvals and non-human workflows alike, as described in Ultimate Guide to NHIs. The operational risk is simple: a single convincing call can override controls that were never designed to validate high-impact instructions in real time. In practice, many security teams encounter impersonation only after an emergency transfer, password reset, or privilege exception has already been approved.

How It Works in Practice

The safest verification pattern is to separate confirmation from the channel being attacked. If the request arrives by voice note, video call, or message, the approver should validate it through a second, pre-registered method that the attacker is unlikely to control. That may be a known mobile number, a corporate ticketing workflow, a signed approval in an identity system, or an independent manager review. Current guidance suggests that the second channel should be routine, fast, and documented before an incident happens, because ad hoc checks are easy to bypass under pressure. A practical response model usually includes:

• Pre-approved callback contacts for executives, finance, and IT administrators.
• Step-up verification for any request involving money, access, policy exceptions, or recovery actions.
• Out-of-band approval in a separate system, ideally with audit logging.
• Clear refusal rules for urgent requests that cannot be independently validated.
• Playbooks that treat emotional urgency as a risk signal, not a reason to accelerate.

This is not only a human-problem control. Organisations also need strong identity hygiene around the systems that receive or act on approvals, because a deepfake often becomes the front end to a larger compromise. NHIMG notes in the Ultimate Guide to NHIs that 97% of NHIs carry excessive privileges, which is why request verification must be paired with least-privilege enforcement and reviewable change paths. Verification is strongest when it is routine, separate from the request channel, and supported by a policy engine rather than a person making a snap judgment. These controls tend to break down in decentralised organisations where approvers are dispersed, callbacks are informal, and emergency exceptions are treated as normal operating procedure.

Common Variations and Edge Cases

Tighter verification often increases friction, so organisations must balance speed against the risk of impersonation. That tradeoff is most visible in payroll, treasury, incident response, and executive support, where delays can be operationally expensive. Best practice is evolving on how much friction is acceptable, but there is no universal standard for this yet. What is clear is that high-impact requests should never rely on voice familiarity alone, even when the caller sounds authentic. Some edge cases deserve special handling:

• Ultimate Guide to NHIs is especially relevant where human approval flows trigger automated actions, because a compromised approver can indirectly release secrets or privileges.
• Emergency scenarios may justify accelerated approval, but they still need a second channel and a post-event review.
• Remote-first and global teams often need region-aware callback lists to avoid time-zone and caller-ID spoofing issues.
• Executives and senior leaders are common impersonation targets, so their approval paths should be more restrictive, not less.

The main failure mode is assuming that a familiar person cannot be convincingly imitated. Organisations should instead design for the possibility that the first channel is compromised and the second channel is the real control.

Related resources from NHI Mgmt Group

• How should security teams reduce fraud risk when attackers can imitate trusted people and processes?
• How should security teams verify high-risk requests when deepfakes and voice cloning are in play?
• How can organisations tell whether stolen credentials are being reused?
• How can organisations reduce the identity impact of email compromise?