If phishing simulations work, why do they need a mandate?

Most security programs can’t answer that question without admitting the truth: phishing simulations aren’t in your stack because they protect users. They’re there because an insurer, a framework, or a client checkbox requires them.

That’s not protection. That’s user-blame security.

Mailprotector sells in the same channel as every sim vendor—same conferences, same insurance forms, same client requests. I first made this argument out loud at RejectionCon, a virtual conference for the talks too spicy for the mainstream stages, at an event sponsored in part by companies that sell phishing sims. So when I say the model is broken, I’m not saying it from outside the market; I argued it on a stage those vendors helped pay for. A partner once told me the sim renewal was easy to justify because the insurance form asked for it. That sentence explains the whole category better than most marketing does.

This is the technical version of the argument: what the simulation actually assumes, why that assumption was always fragile, why AI broke it, and what a defensible model looks like at the system level.

A simulation is a test of the user#

That only makes sense if you’ve already decided the user is the control. And that decision is the foundation underneath the entire awareness-and-training category: malicious messages will reach people, so people have to catch them.

For that to work, three conditions have to hold on every dangerous message, under load, while the user does the job they were actually hired to do:

The message carries an observable tell—bad grammar, an off sender, a malformed link.
The user perceives the tell.
The user acts correctly on it.

This is a detection pipeline with a human as the final classifier. Each stage has a false-negative rate above zero. The stages are serially dependent, so the per-message miss rate is the product of three imperfect steps, evaluated thousands of times a year, against an adversary who only needs one pass. The expected number of successful attacks over any realistic time horizon converges on one. The math was never in the defender’s favor; it just looked survivable while attacks were cheap and crude.

Detection is adversarial classification, and the attacker owns the inputs#

Strip away the human and the same problem shows up in the filter. Content-based email security—the deny-list posture every traditional gateway shares—is a classifier trying to separate malicious from benign on features extracted from the message: language patterns, known-bad URLs, sender reputation, structural heuristics.

In adversarial classification the attacker controls the input distribution. They can sample your decision boundary as many times as they like and ship only the variants that land on the benign side. Your false-negative rate isn’t a fixed property of the model; it’s whatever the attacker drives it to. Defense that operates on message content scales with attacker volume and attacker iteration speed. You don’t win that race. You stay in it.

Both the human and the filter were leaning on the same crutch: phishing used to be expensive to produce well, so most of it was produced badly. Broken grammar, generic framing, obvious bait. Those weren’t fundamental properties of an attack. They were artifacts of cost.

AI removed the cost#

Producing a custom, well-written, context-aware phishing message used to require research, writing skill, and patience. That didn’t scale, so attackers ran volume instead—spray-and-pray against weak filters and weaker training. AI collapsed the marginal cost of a tailored attack to roughly zero.

The right mental model is a JIT compiler. Instead of precompiling a generic payload ahead of time, you generate the exact artifact at the moment it’s needed, specialized for the conditions in front of it. Phishing is now generated per-target, per-context, on demand.

Before writing this, I gave an off-the-shelf model a public LinkedIn excerpt, our company bio, and one public podcast quote, and asked it to write a phishing message targeting our CEO. 38 words of prompt. A few seconds to generate. The output had clean grammar, no manufactured urgency, and context pulled straight from public material: a recent conference appearance, the right vendor relationships, the right tone. No payload in the first message—just bait for a reply. The reply would carry a legitimate Calendly link, with the actual payload deferred to the booking confirmation.

Run that against the three-stage human pipeline. Stage one fails at the source: there is no tell. The grammar is correct, the tone is right, the context is accurate, the first message is benign by construction. Stages two and three never get a signal to act on. “Look closely” assumes there is something to look at.

Authentication is not trust#

The one tell in that generated message was a homograph in the from address—a Unicode character visually identical to a Latin one, swapped into a look-alike domain.

That message can pass SPF, DKIM, and DMARC cleanly. Those protocols authenticate that a domain authorized the mail and that it wasn’t tampered with in transit. They say nothing about whether the domain is one the recipient should trust. An attacker who registers a look-alike domain and configures it correctly is fully authenticated. The green checkmarks are real. They’re just answering a different question than the one the user has.

This is the gap the whole industry papered over. We deployed authentication and treated it as a proxy for trust. It was never that. Authentication answers “did this domain really send this?” Trust answers “should this sender reach this person at all?” A model built on the first question can’t defend against an attacker who simply satisfies it.

Default-deny is the only posture that survives#

If the user can’t be the control and content filtering is a race you stay in rather than win, the system has to make the trust decision, and it has to make it on something the attacker doesn’t control.

Network engineers already accepted this tradeoff decades ago. Default-allow firewalls (permit everything, enumerate badness) lost to default-deny: permit nothing, enumerate the known-good. Email security never made that move. The mailbox still defaults to delivering anything that reaches it and trying to scan out the bad afterward.

Zero trust inverts it. Nothing earns implicit access by arriving. A new sender is held at the boundary and resolved by an explicit decision before it ever competes for the user’s attention. Once a sender is trusted, that state persists, so the decision is made once and carried forward rather than re-litigated by a human on every message at 4:55 on a Friday.

The substitution is the whole point. Traditional filtering asks, on every message, whether the message looks malicious enough to block—a content question the attacker can tune against. Zero trust asks, once per sender: should this sender get direct access to this user?—a relationship question the attacker can’t satisfy by writing a better email. The trust boundary moves the decision off the feature space the attacker controls and onto one they don’t.

This is what Shield is built around. Most email security chases the malicious set, which is unbounded and adversarial. Shield models the wanted set—the senders and patterns a user actually transacts with, which is small, stable, and not attacker-controlled—and lets everything outside it fall away by default.

Awareness belongs at the decision, not in a quarterly module#

This doesn’t kill awareness. It moves it to the only place it’s useful: the moment of the actual decision, with the actual evidence.

When a borderline message does surface, the system should show its work—why this sender is unusual, why the relationship doesn’t fit, what the homograph in the from address actually is. The CEO message above passed every authentication check; a tool that can flag the homograph and explain it is doing the teaching that the annual module pretended to do. One of our partners, Zachary Kinder at Net-Tech Consulting, called this “organic security awareness training.” Education bound to a real decision, instead of punishment after a manufactured failure.

Why the broken model persists#

None of this is hard to see, which raises the obvious question: if user-detection was always fragile and AI has now broken it, why is the simulation category still growing?

Because the simulation produces artifacts and protection doesn’t. A click-rate trend, a completion record, a failure email—all documentable, all screenshot-able, all exactly what the questionnaire wants. A trust boundary that prevented an attack from reaching a user generates no comparable artifact. So the industry optimized for what’s measurable: a program that manufactures evidence of activity and, when the activity fails, routes blame to the user. A falling click rate mostly proves users are learning to recognize the tests.

What I’d ask you to do#

You probably can’t drop sims tomorrow. The renewal still asks, the auditors still check. If a client requires the artifact, produce it.

But treat it as an artifact, not an architecture. Build the stack so protection happens at the trust boundary, upstream of the user, on inputs the attacker doesn’t control—and let the report be a byproduct you generate for compliance, not the thing your security actually rests on.

Before you send the next failure email, pull up the report that produced it and answer one honest question: what changed for that client because this report exists? If the answer is “nothing,” you already know what this post was for.

Don’t let the insurance questionnaire become the architecture. Give users fewer impossible decisions instead of more trick questions.