What breaks when users are the main defence against phishing?

Why phishing defense breaks when people are the control

Training helps, but it is not a durable control when the message itself is convincing enough to bypass the cues people were taught to look for. The failure is not just “someone clicked”, it is that judgment becomes an unreliable security dependency, so the attacker can turn a mistaken trust decision into account takeover, token theft, or unauthorized action.

Phishing works best when it narrows the time to decide and increases the cost of careful verification. At that point, the control is no longer preventing malicious access, it is asking the target to perform adversary screening under pressure, which is a weak assumption once messages are personalized, well branded, or embedded in familiar workflows.

When that assumption fails, the downstream problem is not limited to email. A successful lure can expose credentials, approve OAuth consent, trigger password resets, or redirect the user into a fake login flow. That is why user-centred defence should be treated as one layer, not the boundary that everything else depends on.

What changes after the lure succeeds

The important shift is from deception to control failure. Once a user supplies credentials, approves a prompt, or opens a malicious path, access controls inherit the decision and the attacker can act through a legitimate identity with legitimate permissions.

That matters because many phishing outcomes are not dramatic at first. An attacker may only need mailbox access, a session token, or a one-time approval to move into privilege escalation, lateral access, or data theft. The visible mistake and the actual security impact are often separated by only one step.

This is also why phishing often exposes hidden trust in adjacent systems. If email, SSO, help desks, or collaboration tools trust the user’s judgment too much, then the attacker is no longer fighting a human awareness campaign, they are exploiting a trust chain that lacks stronger verification at the point of action.

For a practical example of how social engineering can move from deception to real access, see NHIMG’s Mailchimp breach 2022, where staff were socially engineered and attackers used that trust to reach export capability and customer keys.

Another useful pattern is Dropbox GitHub breach 2022, which shows how phishing can convert into repository access and secret exposure once identity checks are the only barrier.

When the lure targets developer or build ecosystems, the same failure can produce supply-chain impact. NHIMG’s Ledger Connect Kit npm compromise 2023 shows how phished access combined with weak offboarding became a release-path compromise.

Why this is a control-design problem, not just a training problem

Anti-phishing awareness is still useful, but it cannot be the only line of defence because people do not scale like controls do. As attackers automate message generation, personalization, and timing, the environment changes faster than most training programmes can adapt.

The better question is whether the environment forces a second, stronger check before a user action can cause material impact. If the answer is no, then the organisation has made human recognition carry too much of the security burden. That is a design weakness, not a user failure.

Controls that reduce reliance on judgment are more reliable than controls that merely ask for better judgment. Examples include phishing-resistant authentication, approval steps that are tied to device or origin assurance, and privilege boundaries that limit what a mistaken click can actually expose.

This is why NIST SP 800-63 Digital Identity Guidelines matter here: the more the organisation depends on identity proofing and phishing-resistant authenticators, the less a forged message can translate directly into account control.

For defensive mapping, MITRE D3FEND is useful because it frames countermeasures around the attacker technique, not around hoping users spot every lure.

Where phishing is used to obtain credentials or bypass authentication, the threat path aligns with MITRE ATT&CK Enterprise Matrix, especially credential access and follow-on privilege abuse.

Risk and Threat Considerations

When users are the main defence, the organisation concentrates exposure in the least predictable control layer. Attackers exploit that by making the message look routine, urgent, or contextually familiar, then converting a single mistaken trust decision into session theft, account takeover, or unauthorized privilege use.

Failure mechanism: The defence fails when the lure is convincing enough that the user’s judgment overrides normal caution, and the resulting action is trusted by downstream systems as if it were legitimate.

Impact: The attacker gains a path from deception into real access, which can lead to mailbox compromise, fraudulent approvals, data exfiltration, privileged action, or broader lateral movement.

Practitioner Guidance

What to prioritise: Reduce the amount of damage a successful lure can do. The first objective is not better message recognition, it is smaller blast radius when recognition fails.

What to verify: Check whether your high-risk user actions still depend on a single human decision. If a password reset, consent grant, payment approval, or admin action can proceed after one convincing prompt, the control design is too thin.

Decision rule: If the action can create material impact, require phishing-resistant authentication or an out-of-band verification step before the request can be trusted.

Practitioner takeaway: User awareness is a useful layer, but it is never a sufficient boundary for high-impact access. The more valuable the action, the less your security posture should depend on someone spotting a well-written lie in real time.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on OTP codes as the main defence against phishing?
• What breaks when organisations rely on patching as the main defence against AI-driven attacks?
• What breaks when patching is the main defence against fast-moving vulnerability discovery?
• What is the main risk when automation systems store ServiceNow credentials?