Join our Newsletter — 33% off our NHI Course

What should organisations do when a deepfake is used during an internal call to gain trust and move laterally?

They should assume the conversation itself may be part of the attack and fall back to prearranged verification procedures. That means stopping any sensitive request, confirming identity out of band, and involving the right responders before privileges or access are changed. If lateral movement is the goal, fast containment and strict approval discipline matter more than trying to outguess the attacker live.

Why a Deepfake Call Should Be Treated as an Active Intrusion, Not a Clever Conversation

A deepfake in an internal call is not just a deception problem, it is a trust-boundary problem. Once an attacker can imitate a voice or face convincingly enough to influence decisions, the call itself can no longer be treated as a reliable source of identity, authority, or intent. The right response is to slow the process, shift to prearranged verification, and stop any access change until the request is independently confirmed.

That matters because the goal is often not the call alone, but the downstream action: approving a transfer, resetting credentials, granting access, or opening a path for later movement. Deepfakes, Social Engineering and AI Impersonation Guide is useful here because it frames out-of-band verification and identity-based checks as the correct control response when human perception is being manipulated.

What Organisations Should Do During the Call

The safest operating assumption is that the live conversation may be part of the intrusion. If the caller asks for urgency, secrecy, credential resets, payment changes, or privilege changes, the response should be to pause and route the request through a known verification path rather than continue improvising on the call. That reduces the chance that social pressure becomes the attacker’s main control surface.

Prearranged verification should be specific and already known to staff. It can include callback to a known number, confirmation through a separate channel, manager approval for high-risk actions, or validation through an established help desk workflow. Arup deepfake fraud 2024 shows why this discipline matters, because the call itself can be convincing enough to trigger a harmful transfer when verification is weak or absent.

If the request touches access, the default should be no change until the identity claim is confirmed independently and the request is logged for review. If the request touches money, data, or privileged systems, the threshold should be even stricter. Organisations should also make sure staff know which requests are never approved in real time, especially when the request is unexpected, urgent, or outside normal duty hours.

Why Lateral Movement Changes the Response

When the objective is lateral movement, the call is no longer just about one false request. It may be a probe for credentials, a way to bypass normal approvals, or a distraction that creates a second path into the environment. At that point, the right response is to contain the event quickly, preserve evidence, and limit what the caller can reach while the trust issue is assessed.

That is why technical containment and approval discipline belong together. A fast reset of affected accounts, a check for recent privilege changes, and a review of related sessions or tool access can matter more than trying to determine in the moment whether the person on the line is “really” the executive. MITRE ATT&CK Enterprise Matrix helps practitioners frame this as credential access and lateral movement activity, while NIST SP 800-207 Zero Trust Architecture reinforces the principle that trust should be continuously verified rather than inferred from a familiar channel.

Organisations should also be careful not to overfit the response to the fake persona. The issue is not only impersonation, it is the possibility that the attacker has already learned enough context to sound legitimate and move to the next stage. That means incident handling should focus on the request, the affected assets, and the trust path, not just the quality of the deepfake itself.

Risk and Threat Considerations

A convincing deepfake can exploit urgency, authority bias, and normal internal trust to bypass controls that would otherwise slow an attacker down. The main risk is not embarrassment, it is accelerated access, changed approvals, or lateral movement before anyone realises the conversation was synthetic.

Failure mechanism: The attacker uses a fabricated voice or face to simulate a trusted colleague, then asks for a privileged action, credential reset, or exception that creates a second foothold.

Impact: The organisation may lose time, access, or containment leverage, and a single successful interaction can become the launch point for broader compromise.

Standards & Framework Alignment

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

OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST SP 800-53 Rev 5 IA-5 — Authenticator Management Deepfake calls often seek credential resets or verifier bypass.
AC-6 — Least Privilege Lateral movement risk rises when callers can trigger broad privilege changes.
AU-6 — Audit Review, Analysis, and Reporting Suspected deepfake incidents need rapid review of access changes and related events.
Recommendation — Require out-of-band verification before issuing or resetting authenticators. Limit who can approve access changes and restrict high-risk actions by default. Review related approvals, sessions, and identity events immediately after containment.
OWASP API Security Top 10 API2 — Broken Authentication The tactic abuses identity confidence to get authentication or access changes.
Recommendation — Reject identity changes unless the request is independently authenticated.
MITRE ATT&CK T1078 — Valid Accounts Deepfake social engineering often aims to obtain or abuse legitimate access.
T1021 — Remote Services Lateral movement is the core follow-on risk after trust is gained.
Recommendation — Hunt for abuse of legitimate accounts after a suspicious trust event. Check for new remote access paths and block unexpected session creation.

Practitioner Guidance

What to prioritise: Train staff to stop the transaction first, then verify identity through a channel the attacker cannot control. For high-risk requests, the best decision is usually to delay rather than debate authenticity live.

What to verify: The requestor, the request type, and the approval path all need independent confirmation before any access, payment, or privilege change is made. If any one of those is uncertain, treat the call as untrusted.

Common mistake: Teams often focus on whether the voice “sounds right” instead of whether the business process can safely absorb a false request. The control should not depend on human detection skill alone.

Practitioner takeaway: In a deepfake-driven internal call, the correct objective is not to win the conversation, it is to prevent the conversation from becoming an authority channel for change.