sean cassidy : Phishing simulations considered harmful

Phishing awareness training done via simulated phishing emails that your Security team sends does more harm than good.

These simulations are often unrealistic, bypass real phishing controls, and raise more resentment than awareness.

The way a typical phishing simulation works is this:

  1. Someone on Security makes a new phishing email, optionally using insider info that few attackers would have (like knowing when or where a company holiday party is).
  2. They send it out to some segment of their employee base. Often, this bypasses the organization's anti-phishing controls via an allowlist.
  3. Most employees ignore it, a few report it, and a few fall for it.
  4. The few that fall for it get signed up for additional phishing awareness training, or, worse, get negative performance feedback.
  5. Security reports the number to their steering committees or board of directors to argue for more investment in security

I think that this is, at best, not useful, and at worst, harmful to your employees.

Why is this harmful?

It puts the onus on the employee, rather than the Security team to stop phishing attacks. Your employees have work to do and you are interrupting them. You are adding to their cognitive load for every single email they read. You are increasing their anxiety of doing their job. The Security team should focus on stopping phishing emails and making it easy to report, investigate, and remediate them.

It breeds resentment of the Security team that tricks them. Most organizations want a Security team that is open, friendly, and approachable. People will tend to avoid the Security team after they realized they failed a phishing email test. This is the opposite of what you want.

Bypassing your controls is not an accurate simulation. If you are using a tool that bypasses G-Suite's (or Office 365 or whatever) phishing detection, this is not an accurate simulation no matter what the email says. You are likely training your users to spot your phishing emails, rather than what's actually hitting your users, even if you are attempting to base them on real phishing emails.

We already know that people fall for phishing emails. Gitlab recently found that 34% of its employees fell for a phishing simulation. This is not a surprise. Even at companies that don't use email much, a consistent proportion of people will fall for phishing attempts.

Repeated phishing awareness training is not effective. Most employees nowadays have been through at least one phishing training, and are aware of the basics. Getting re-trained every three months is not a useful exercise for anyone.

What should you do instead?

Focus on overall security awareness, and offer an easy-to-use way to report phishing emails. Measure number of true and false positive reports and give awards to the best reporters in your company. Offer opt-in phishing training and let your employees decide what they need.

Reduce the impact of phishing emails, by implementing a single-sign on solution with phishing-resistant 2FA (like WebAuthn), and require non-email approvals for financial transactions like wire transfers. Flag replies to new email domains and encrypted attachments for review by the Security team.

To measure phishing susceptibility, defang real phishing emails and leave them in inboxes. This means rewriting URLs and email addresses and replacing attachments with duds. One advanced strategy is to deliver real but defanged phishing emails to more employees than originally received it. This is not a simulation: it's the real thing! It bypassed your phishing prevention controls. Another alternative is to run red team exercises that mimic real phishing attacks, but crucially they should have to go through your anti-phishing controls rather than bypassing them.

Avoid in-line user shaming. If a user clicks on a real but defanged phishing email, it should not scold them or automatically sign them up for training. The best practice here is to silently do nothing, or give them a gentle reminder to report phishing emails and attend opt-in phishing training if they want help.

Your users are not the problem

If I were to summarize this, it's that often Security treats the users as the problem or the weak link. This is not the case and creates an adversarial us-versus-them attitude. Instead, treat your users as an important asset that can be coached to be better, but not if you train them to spot unrealistic emails or scold them.


  1. What's the length of shortest bit sequence that's never been sent over the Internet?
  2. Browser Extension Password Managers Should Not Be Used
  3. How to Implement Crypto Poorly
  4. Meditations Redux
  5. Genius Blocker
  6. LostPass
  7. Privilege
  8. Your Own Verifiable Hardware RNG with bladeRF SDR
  9. We, the Weapons
  10. The Practice Startup
  11. Code as Risk
  12. Sherlock Holmes Debugging
  13. Plural gTLDs are evil
  14. Your Interface is what Matters
  15. Write in the Margins
  16. Meditations
  17. Better Java
  18. When names outlive their usefulness
  19. Diagnosis of the OpenSSL Heartbleed Bug
  20. The Intuition Trap
  21. Ambition
  22. The Story of the GnuTLS Bug
  23. Wrong Solutions
  24. Host an infodump session
  25. So, you want to crypto
  26. Hackers and Engineering School
  27. Strings are untyped
  28. Don't Pipe to your Shell
  29. How to Organize Your Brain with Bookmark Tags
  30. You are not a 10x Developer
  31. Windows ruins everything
  32. Don't Give Up and Die
  33. On Being Nice
  34. Bus Factors and Walk Score
  35. Wiggle the mouse to fix the test
  36. A Difficult Bug
  37. The Origins of the Diluvian Network
  38. Zipf your variable names
  39. H.264 and VP8, compared
  40. On Accepting Interview Question Answers
  41. Rate Limiting per User
  42. Write your own Data Structures