Assume Breach Must Now Mean Assume Impersonation

‘Assume breach’ (opens in new tab) is a useful operating principle for enterprise security: Build as if an attacker will eventually get past the perimeter. That mindset led teams to adopt Zero Trust (opens in new tab), stronger endpoint controls, network segmentation, and tighter identity and access management.

The premise still holds in 2026, but the gap is that many of today's most effective attacks don't begin with an intruder forcing their way into a system. They begin with someone borrowing a trusted identity and persuading a legitimate employee to act.

An attacker can imitate an executive's voice, recreate a familiar face on video, register a nearly identical domain, or write in a colleague's style. Nothing has to look technically compromised. The request only has to feel credible long enough for someone to approve a payment, share credentials, reset an account, or bypass a control.

That's why ‘assume breach’ needs a companion principle: ‘assume impersonation.’

This $25 million attack exposed the gap

The Arup deepfake fraud case (opens in new tab) is a useful example. In 2024, an employee in Hong Kong received a message that appeared to come from the company's CFO and joined a video conference with people who appeared to be senior colleagues. The participants were deepfakes. The employee ultimately authorized 15 transfers totaling HK$200 million, or roughly US$25.6 million.

The case wasn't a story about malware slipping past endpoint detection. It was a story about a real employee using legitimate access, responding to a request engineered to look and sound authentic.

That distinction matters. Authentication can confirm that the employee is allowed to initiate a transaction. It can't confirm that the person instructing them is really the CFO. Network segmentation can limit lateral movement, but it can't evaluate the legitimacy of a face on a video call. An email gateway may inspect a message, but it can't protect a process that treats a familiar voice as proof.

The attacker didn't need to defeat every control. They found the point where technical trust became human trust and built the attack around it.

Why internal controls miss identity-level attacks

Most internal security controls answer technical questions.

• Is this device managed? Did this user authenticate?
• Is this process behaving unusually?
• Did known malicious code execute?
• Impersonation attacks ask a different question: can the attacker make a request feel legitimate?

That request may travel through a sanctioned channel and land on a managed device. It may contain perfect grammar, accurate company context, and a convincing explanation for its urgency. It may even come from a compromised account or a domain that differs from the real one by a single character.

This is how the social engineering attack chain moves through the seams between controls. Attackers establish infrastructure, launch the lure across one or more channels, engage the target, and push toward compromise. A tool that sees only the email, the domain, or the user action gets one fragment of the campaign rather than the whole operation.

Assume impersonation doesn't replace Zero Trust. It extends the same skepticism from network access to identity signals, business context, and high-impact requests.

What 'assume impersonation' means

An assume-impersonation model treats every identity cue as a claim that may need verification. A known display name is a claim. A familiar voice is a claim. A video feed, writing style, caller ID, and corporate logo are all claims. The higher the stakes, the stronger the proof should be.

This isn't a request to make employees suspicious of every ordinary interaction. It's a way to design safer defaults around the moments attackers value most: payment changes, password resets, MFA enrollment, payroll updates, sensitive data transfers, and exceptions to established policy.

The goal is to remove the burden of improvisation. Employees shouldn't have to decide, under pressure, whether a realistic voice clone is real. The process should tell them when a second check is required, which channel to use, and who must approve the action.

Turning the mindset into operations

The principle becomes useful when it changes day-to-day controls. Four practices matter most:

• Define the actions that always trigger additional verification. Document the thresholds and exceptions for wire transfers, vendor-bank changes, account recovery, credential resets, and sensitive-data requests so urgency can't rewrite policy in the moment.
• Verify through a trusted second channel. If a request arrives by email or video, confirm it through a known phone number, an approved workflow, or another pre-established channel. Don't use contact information supplied in the suspicious request.
• Watch for impersonation infrastructure before contact.Digital risk protection can surface lookalike domains, fake profiles, deceptive ads, and other infrastructure attackers build before they approach an employee, customer, or partner. Doppel’s executive protection extends that visibility to threats aimed at leaders and other high-profile employees.
• Rehearse the attacks people will actually face.Human risk management (HRM) should test behavior across email, voice, SMS, video, and collaboration tools, then reinforce the verification and escalation steps employees need under pressure. Doppel’s simulations turn current attacker tactics into realistic, controlled practice.

These controls work best as a system. External monitoring can reveal what attackers are preparing. Email and phishing defenses can catch the lure when it arrives. Reporting, simulation, and training can strengthen the human response when an attacker reaches a person.

The missing half of ‘assume breach’

The original ‘assume breach’ model concentrated on what happens inside the environment. Impersonation often begins outside it, where attackers register domains, build fake profiles, gather public content, stage ads, and prepare synthetic identities.

Security teams need visibility across both sides of that boundary. They also need signals that connect them. A lookalike domain shouldn't sit in one dashboard while a related phishing email, employee report, and fake executive profile appear as unrelated events elsewhere.

Doppel’s platform is built around that connection. It links digital risk protection, human risk management, and email security through shared intelligence, while the threat graph maps domains, profiles, messages, and other artifacts into the campaigns behind them.

That changes what the organization can do with a signal. A threat discovered externally can inform simulation and training. An employee-reported message can sharpen detection and remediation. Email evidence can reveal infrastructure to disrupt before the campaign reaches more people.

Instead of asking each tool to win a separate fight, social engineering defense coordinates the response across the attack chain.

Evolving the trust model

Attackers have learned that imitating trust can be cheaper and faster than breaking a technical control. Security architecture has to account for both paths.

Continue to assume that credentials can be stolen, devices can be compromised, and an adversary can gain access. Also assume a voice, face, account, domain, or message can be fabricated well enough to influence a legitimate user.

The practical answer isn't permanent distrust. It's better verification at high-risk moments, earlier visibility into attacker infrastructure, and connected defenses that can follow a campaign across channels. ‘Assume breach’ protects the environment after access is challenged. ‘Assume impersonation’ helps stop the attacker from borrowing trust in the first place.

See how Doppel helps security teams detect, disrupt, and defend against impersonation across the attack chain.