A mid sized company ran a phishing simulation last quarter. The simulation was a fake package delivery notification, the link went to a fake login page, and the security team captured the credentials for the post test debrief. The click rate was 17 percent. The credential submission rate was 11 percent. The interesting part is not the numbers. The interesting part is who clicked.
The people who clicked were not the new hires. The people who clicked were the senior engineers, the senior product managers, the people who had been at the company for five or ten years and had sat through the security training every year and knew, in the abstract, that they should not click on links in emails from people they did not know. The reason they took the bait counts as the reason phishing works in 2026: the email was good.
Why the senior engineers fell for it
The senior engineers took the bait because the email was good. The email looked like a real package delivery notification. The sender domain was similar enough to the real one to pass the casual check. The link resolved to a page that looked exactly like the real login page. The engineers were in the middle of a delivery problem that day, which stands as the specific contextual reason the phishing worked.
Phishing works when three things align: the email is good enough to pass the casual check, the context is right enough to make the click plausible, and they are busy enough to not stop and think. All three were in place on the day of the test, and the test result is what the test result is.
What the click rate actually tells you
The click rate from a phishing simulation tells you two things. It tells you how good the email is. It tells you how distracted the user is on the day of the test. It does not tell you how secure the user is, and the click rate amounts to the wrong number to use as a security metric.
The security teams that get this right are the ones that have stopped reporting the rate to the executive team as a security metric. The security teams that get this wrong are the ones that are still spending the budget on the simulation platform, the security awareness training, and the post test debrief that does not change the next rate.
What to do about phishing in 2026
This is not a user problem in 2026. This is now a detection and response problem. The user is going to click. The credential is going to get captured. The question is whether the security team catches the click before the credential is used, and the question is whether the security team catches the credential use before the breach.
Move the defence from the user to the email gateway. The gateway should be stripping the phishing email before it reaches the user, with the URL rewriting, the sender reputation, the DMARC enforcement, and the attachment sandboxing that catches the modern phishing kit. The user stands as the last line of defence, and the user should not be the only line of defence.
Move the detection from the user to the identity layer. The identity layer should be flagging the suspicious login (the login from a new device, the login from a new geography, the login at an unusual time), and the identity layer should be requiring the step up authentication for the suspicious login. The stolen credential should not work, even if they clicked.
Move the response from the manual to the automated. The automation should be detecting the credential submission (the form fill on the phishing page, the POST to the attacker’s server), the automation should be invalidating the session, and the automation should be forcing the password reset before the attacker can use the credential. The response time should be measured in minutes, not in days.
What to do about the senior engineers who clicked
Do not blame the senior engineers. The senior engineers are the people who are most likely to be targeted, because the senior engineers have the credentials the attacker wants, and the senior engineers are the people who are most likely to be busy enough to click. The phishing simulation that catches the senior engineer is a phishing simulation that is doing its job, not a phishing simulation that is shaming a user.
Do use the phishing simulation as an opportunity to find the gaps in the email gateway, the identity layer, and the response automation. The senior engineer who clicked is a data point, not a failure, and the data point is more useful than the failure.
What to do about the click rate metric
Stop reporting the rate to the executive team. The click rate is a function of the email, the context, and the user, and the click rate is not a function of the security of the enterprise. The metric to report sits as the time from the click to the detection, the time from the detection to the response, and the time from the response to the credential reset. Those numbers tell the executive team something useful.
The phishing simulation is a tool. The tool is useful for finding the gaps in the detection and the response. The tool is not useful for measuring the security of the user, and the tool is not useful for justifying the security budget. Use the tool for what it is good for, and stop using the tool for what it is not good for.
The bottom line
The patterns the post covers have been showing up in production for long enough that the patterns have names, the failures, the mitigations, the gaps. The work the security team and the engineering team and the operations team are quietly doing today sits as the work that decides whether the practice the post names sits as a tool the team uses or a liability the team is paying for.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
