5 MIN READ
A mid sized company ran a phishing simulation last quarter. The email was a fake package delivery notification, the link pointed at a fake login page, and the AppSec team captured the credentials for the post-test debrief. The click rate came in at 17 percent. The credential submission rate was 11 percent. The interesting part was not the numbers. It was who clicked.
The clickers were not the new hires. They 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 is the reason phishing works in 2026: the email was good.
Why the senior engineers fell for it
The lure looked like a real package delivery notification. The sender domain was close enough to the real one to pass the casual check. The link resolved to a page that mirrored the real login page. The engineers were in the middle of a delivery problem that day, which is the specific contextual reason the phishing worked. They were not careless. They were busy, the bait was good, and the bait beat the training.
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 the reader is busy enough to skip the second look. All three were in place on the day of the test, and the result is the result.
What the click rate actually tells you
The click rate from a phishing simulation tells you two things and only two. How good the email was. How distracted the user was on the day of the test. It does not tell you how secure the user is, which makes the click rate the wrong number to use as a security metric.
The AppSec teams that have stopped reporting the rate to the executive team as a security metric are the ones getting the most out of the budget. The ones still spending the budget on the simulation platform, the security awareness training, and the post-test debrief that does not change the next rate are the ones still optimising for the wrong number.
What to do about phishing in 2026
This is no longer a user problem. It is a detection and response problem. The user will click. The credential will get captured. The question is whether the AppSec team catches the click before the credential is used, and whether the identity layer catches the credential use before the breach.
Defence goes to the email gateway. The gateway should be stripping the phishing email before it reaches the user, with URL rewriting, sender reputation, DMARC enforcement, and attachment sandboxing that catches the modern phishing kit. The user sits as the last line of defence, and the user should not be the only line.
Detection goes to the identity layer. It should flag the suspicious login (new device, new geography, unusual time) and require step-up authentication before the session is granted. The stolen credential should fail, even if the user clicked.
Response goes from manual to automated. The automation detects the credential submission (the form fill on the phishing page, the POST to the attacker’s server), invalidates the session, and forces a password reset before the adversary can use the credential. The window is measured in minutes, not in days.
What to do about the senior engineers who clicked
Do not blame the senior engineers. They are also the people most likely to be targeted, because they hold the credentials the adversary wants, and they are the people most likely to be busy enough to click. A phishing simulation that catches a senior engineer is doing its job. It is not shaming a user.
Use the simulation as a probe. The data point is the gap in the email gateway, the identity layer, or the response automation. The senior engineer who clicked is a sensor reading, not a failure, and the reading is more useful than the lecture.
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 it is not a function of the security of the organisation. The numbers worth reporting to the executive team are 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 are the metrics that tell the executive team something useful.
The phishing simulation is a tool, and a tool should be used for what it is good for. It is good for finding the gaps in the detection and the response. It is not good for measuring the security of the user, and it is not good for justifying the security budget. Use it for the gap finding, and stop using it for the rest.
The bottom line
The senior engineer is the canary. Treat the click rate as an email quality metric, not a security score. Phishing will keep landing, so the gateway, the identity layer, and the response automation are where the work matters. The org that still treats the click rate as a security score pays for the next breach in headlines.
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.
