Blog · Email-security
Why Phishing Simulations Are Mostly Security Theater (And What Actually Works)
The Simulation Paradox
Your last phishing simulation probably looked like this: an email that kind of looked like a SharePoint notification, a link that took you to a branded login page, a click recorded, a polite "you failed" message. You ran it, some people clicked, most didn't, and you sent the results to management with a recommended training push.
Now consider what an actual attacker does. They spin up a convincing sign-in page on infrastructure that passes reputation checks. They steal a valid session token via an adversary-in-the-middle attack. They sit in your tenant reading mail for six days before anyone notices. Your simulation never tested any of that.
The problem isn't that simulations are useless. It's that they measure something very different from what matters.
Why Simulations Keep Failing
Phishing simulation vendors build their exercises around what they can safely deploy in a corporate environment. That constraint creates a systematic gap between what simulations test and what attackers actually do.
Predictable timing and format. Most simulation platforms rotate through a known library of templates. After a few runs, employees start recognizing the telltale signs - unusual urgency, slightly off branding, a generic greeting. Real attackers adapt per target and per campaign. Simulations can't replicate the first-time freshness of a genuine targeted attack.
Known sender infrastructure. Simulations run from ranges the email gateway recognizes as internal or approved. Real phishing comes from newly registered domains, compromised third-party senders, and legitimate services the recipient actually uses. A vendor email compromise that uses the real SendGrid account your company uses every week looks identical to your gateway whether the sender is an attacker or your actual marketing platform.
No credential theft infrastructure. Most simulation tools capture the click, not the credential. Clicking a simulated phishing link and entering "testpassword123" into a form is not the same as an attacker harvesting a real OAuth token via an adversary-in-the-middle proxy. The actual compromise path - token theft, session replay, lateral movement - never appears in your simulation results.
This last one matters most. AiTM (adversary-in-the-middle) attacks intercept authentication sessions rather than passwords. If your simulation checks whether users enter their password, it never touches the attack method that bypasses everything your simulation platform tests.
The Metrics That Don't Translate
A 5% click rate after six months of training sounds like progress. But here's the better question: what attacks can your simulation actually replicate? If the answer is "mostly credential-harvest links from known sender infrastructure," then you're measuring one narrow behavior while real attackers use techniques your tool never tests.
Report rates are similarly misleading. Teaching users to report suspicious email is good - but a reported email that your SOC ignores or can't triage is a metric that looks good and changes nothing operationally. Your simulation measured user behavior, not your detection and response capability.
The honest framing: a low simulation click rate means your users have learned to recognize your simulation templates. It does not mean they can identify novel targeted attacks. It does not mean your email authentication is working. It does not mean your conditional access policies stop credential theft.
What Actually Works
Email security that stops real attacks operates at a different layer than user awareness. It works even when users click.
SPF, DKIM, and DMARC as structural defense. Email authentication protocols verify that a message actually came from the domain it claims. SPF checks sending server authorization. DKIM cryptographically signs message content. DMARC ties both together with a policy layer that tells receivers what to do with failures. An email that fails all three can be rejected at the gateway before it reaches any inbox. This is not training - it is enforcement. It works whether the recipient is paying attention or not.
DMARC monitoring for unauthorized domain use. Attackers can spoof your domain even when your own email is properly protected - sending from infrastructure the receiver doesn't recognize, using your brand in the From address. Your aggregate DMARC reports show exactly when this happens: which sources are sending mail that fails alignment against your domain, which receivers are handling those messages, and what the failure patterns look like across time. This is intelligence a simulation can never generate. Tools like DMARCFlow monitor these reports continuously and alert you when your domain appears in unauthorized email - before users forward you a suspicious sample.
Conditional access with phish-resistant authentication. FIDO2 hardware keys, certificate-based authentication in Entra ID, and session risk policies make stolen tokens useless to attackers. This is the most effective defense against AiTM attacks, and no simulation tool tests whether your conditional access policies actually enforce it.
Segmentation and least privilege. If an attacker gets a user's mailbox, what can they actually reach? Limiting access scope means a compromised account does not become a domain-wide incident.
The Honest Assessment
Phishing simulations have a role, but it is narrower than the industry position implies. They are useful for baseline awareness and for demonstrating due diligence to auditors. They are not a meaningful metric for security program effectiveness.
A good simulation program uses real infrastructure for credential harvest, contextual scenarios, variable senders and timing, and tests against the authentication flows your organization actually runs. If your current vendor can't explain how their platform tests for AiTM credential theft, ask them directly - and treat the silence as information.
What you should actually track: how many unauthorized domain use incidents appeared in your DMARC aggregate reports this month. What percentage of your conditional access policies are enforced with phish-resistant factors. How long your SOC takes to triage a reported suspicious email from the moment a user hits "report." Those numbers tell you something real.
A Practical Starting Point
If you're running phishing simulations and calling it your email security program, here is what to add this week:
Structural email defense stops attacks before they reach users. Training makes users slightly more cautious. Both belong in a security program, but one of them actually changes outcomes when the attacker is skilled and motivated.