Security teams keep blowing their own cover: the simulated phishing email gets flagged by the SOC, quarantined by EDR, or escalated to an incident ticket before a single click is logged. Running a stealth phishing simulation means the campaign lands, gets clicked (or not), and generates clean data — without the SOC, the help desk, or the CISO's inbox lighting up over a drill.
TL;DR
- Whitelist simulation sending domains in the email gateway and SIEM before launch, not after the first false alert.
- Brief the SOC and help desk 24-48 hours ahead so a stealth phishing simulation doesn't trigger a real incident response.
- Segment by department risk instead of blasting the whole org at once — fewer simultaneous alerts, cleaner click data.
- Rotate sending infrastructure every quarter in 2026; reused domains get blocklisted by spam filters within weeks.
- Cyber Aware customers running quiet pilots first catch alert-routing issues before a full rollout, not during one.
Why this matters
A phishing simulation that trips an EDR quarantine or a SOC escalation doesn't just waste a cycle — it teaches staff the wrong lesson. Employees learn to trust that IT will catch the fake before they need to, which defeats the training. Worse, a mislabeled simulation that reaches an MSP's incident queue burns analyst hours on a threat that was never real.
The fix isn't a fancier phishing template. It's infrastructure and timing. Get the security awareness platform configured correctly once, and every future stealth phishing simulation runs quiet by default.
What you'll need
- Admin access to the email security gateway (Microsoft Defender, Proofpoint, Mimecast, or equivalent)
- SIEM or EDR console access to add exclusion rules for simulation traffic
- A list of sending domains and IPs the simulation platform uses, refreshed for 2026
- A short internal memo template for briefing the SOC or help desk lead
- Department-level risk segmentation data (who's clicked before, who handles finance or payroll)
- 30-45 minutes of setup time before the first campaign, less for repeat runs
The steps
1. Pull the sending infrastructure list before you build anything
Every phishing simulation platform sends from a defined set of domains and IP ranges. Get that list first — building templates before whitelisting is the single most common reason a stealth phishing simulation gets caught by a spam filter on day one.
Request the current domain list from your platform vendor, not last year's list. Mail gateways update reputation databases weekly in 2026, and a domain that was clean in January can be flagged by March.
Common mistake: copying a domain list from a blog post or forum instead of the vendor's live dashboard. Stale lists cause the exact alert storms you're trying to avoid.
2. Whitelist at the gateway and the SIEM, not just one or the other
Whitelisting the email gateway stops the message from landing in quarantine. Whitelisting the SIEM stops the click and credential-entry event from generating a security alert downstream. Skip either one and half your stealth phishing simulation still trips a wire.
Add exclusion rules by domain and sender IP, not by subject line — subject lines change per campaign, infrastructure doesn't. Confirm the rule is active with a single test send to an internal mailbox before scheduling the real campaign.
Expected outcome: the test email arrives in the inbox, no quarantine notice, no SIEM alert fires in the console.
3. Brief the SOC and help desk lead — quietly
This is the step teams skip and regret. One person on the SOC or help desk needs to know a stealth phishing simulation is running this week, even if the rest of staff don't. That one person stops a real incident ticket from being opened over a fake click.
Send a short internal note: campaign window, sending domain, and a line saying "do not escalate, do not alert staff." Keep the distribution list to two or three people maximum — wider briefing defeats the purpose of "stealth."
4. Segment the send by department risk, not the whole org at once
Blasting 400 staff simultaneously creates a spike that's easy for a SOC dashboard to notice, even with whitelisting in place. Segmenting by department — finance first, then operations, then general staff — spreads the signal and gives you cleaner per-group click data.
This also lets you target higher-risk groups specifically. Payroll and finance teams handling supplier payments warrant a different simulation than general staff; the guide on training payroll teams to stop CEO fraud emails covers why that group needs its own campaign entirely.
5. Schedule outside compliance and audit windows
Running a stealth phishing simulation during an active audit period risks the click data getting pulled into scope for reasons that have nothing to do with training. Check the compliance calendar before locking a send date in 2026 — APRA, ISO, or internal audit windows are the most common collision points.
Common mistake: scheduling a campaign the same week as a real vendor security review. Two unrelated "incidents" landing simultaneously makes both harder to explain later.
6. Route the "report phishing" button to a controlled inbox
If your default report-phishing button escalates straight to the SOC's incident queue, every employee who correctly spots the simulation generates a false escalation. Route simulation-flagged domains to a separate, monitored mailbox instead, so genuine catches get logged as training wins, not incidents.
This single change removes most of the noise a stealth phishing simulation generates on the SOC side, and it's worth revisiting the escalation path in full — see how to design an escalation path for repeat phishing clickers for the structure that scales past a one-off drill.
7. Run a small pilot group before the full rollout
Ten to twenty staff, one department, one send. This catches gateway misconfigurations, SIEM rule gaps, and template issues before they hit the whole organisation. A pilot that runs clean gives you confidence the full campaign won't generate alerts either.
Expected outcome: zero help desk tickets, zero SIEM alerts, and click/report data that matches what the platform dashboard shows.
8. Debrief and refresh templates quarterly
Stale templates get recognised by staff and flagged faster by filters. Refresh scam scenarios every quarter to match current tactics — invoice fraud, MFA fatigue prompts, and deepfake-adjacent lures are the dominant patterns going into 2026. The detail on keeping phishing simulations current with new scam tactics covers the refresh cadence in more depth.
Troubleshooting
- EDR quarantines the simulation email mid-campaign. The sending IP changed without an update to the exclusion rule. Pull the current IP range from the vendor dashboard and re-add it — don't reuse last quarter's rule.
- Help desk gets flooded with "is this real" calls. The briefed contact wasn't specific enough. Add a one-line FAQ for the help desk team covering exactly what to say without confirming it's a drill.
- Executives get a breach alert from the SIEM. The SIEM exclusion rule only covered the gateway, not the click-tracking domain. Whitelist both endpoints, not just the initial send.
- Click rates look artificially low. Staff may have recognised the sending domain from a prior campaign. Rotate domains and vary the sender name each quarter.
- A department reports the campaign to a regulator or client by mistake. This happens most in MSP contexts running simulations across client tenants — the fix is a clearer internal-only labelling convention before the send, not after.
Tools and resources
- Security awareness platform for building and scheduling the simulation campaign
- How to run a phishing simulation pilot before full rollout for the pilot-group methodology
- How to run phishing simulations during a company merger for high-sensitivity timing scenarios
- How to benchmark phishing click rates against industry averages for reading the results once the campaign runs clean
- Email gateway admin console and SIEM exclusion-rule documentation from your existing security stack
Set up your first stealth campaign
Get whitelisting and segmentation configured before your next send.
What to do next
Once a stealth phishing simulation runs clean through one pilot group, extend the segmentation model organisation-wide and start briefing executives on outcomes rather than incident counts — the approach in how to brief executives on security awareness outcomes covers how to frame that reporting so it lands as a training metric, not a security event.
FAQ
What is a stealth phishing simulation?
A stealth phishing simulation is a simulated phishing campaign configured to avoid triggering email security alerts, SOC escalations, or EDR quarantines while it runs. The goal is clean click and report data without the SOC treating the test as a real incident.
How do you stop a phishing simulation from triggering EDR?
Whitelist the simulation platform's sending domains and IP ranges directly in the EDR console before launch, and refresh that list quarterly in 2026 since infrastructure rotates. Skipping the SIEM-side rule and only whitelisting the email gateway is the most common cause of a mid-campaign quarantine.
Should the whole company get the simulation at once?
No — segmenting by department risk spreads the send over days instead of hours, which avoids the alert spike a full-org blast creates on SOC dashboards. It also produces cleaner per-department click data for reporting.
Who needs to know a phishing simulation is running?
One SOC or help desk contact, briefed 24-48 hours ahead, is enough to prevent a false incident ticket. Briefing more than two or three people defeats the stealth element of the campaign.
How often should simulation templates change?
Refresh templates quarterly at minimum going into 2026, since staff recognise repeated scenarios and spam filters flag reused domains faster over time. New scam patterns like MFA fatigue prompts and deepfake-adjacent lures should rotate in each cycle.
What happens if a real incident ticket gets opened by mistake?
Close it immediately with a note confirming it was a scheduled simulation, and review why the SIEM or gateway exclusion rule failed to catch it. This usually traces back to an outdated IP range or a missing click-tracking domain in the whitelist.
Can MSPs run stealth phishing simulations across multiple client tenants?
Yes, with per-tenant whitelisting and a clear internal labelling convention so one client's staff don't mistakenly report the drill to another client or a regulator. Segmenting by tenant and department risk keeps campaigns isolated and easy to troubleshoot individually.
Does a pilot group really matter for a small business?
Yes — even a ten-person pilot catches gateway misconfigurations before they hit the whole staff list, and it takes under a day to run. Skipping the pilot is the fastest way to discover a whitelisting gap during the full campaign instead of before it.
One last thing
The alert that actually damages a stealth phishing simulation isn't usually the SOC ticket — it's the executive Slack message asking "are we being hacked?" that goes out before anyone checks the SIEM. Brief one executive contact alongside the SOC lead, and that message never gets sent.