What do security teams get wrong about anti-phishing programmes?

Many teams overinvest in warning users and underinvest in the access paths that a phished user can reach. If a compromised account can approve payments, reset passwords, or reveal API keys, the programme has not reduced risk enough. The question is not whether users click, but whether the click can still become meaningful access.

Why This Matters for Security Teams

Anti-phishing programmes often fail when they are treated as awareness campaigns instead of access-risk controls. The real issue is not simply whether a person recognises a suspicious message, but whether a successful phish can be converted into privilege, money movement, mailbox takeover, or secrets exposure. That is why mature programmes have to connect user behaviour, identity controls, and downstream authorisation paths.

Security teams also tend to measure the wrong thing. Click rates and report rates are useful signals, but they do not prove that phishing no longer leads to harm. Current guidance from the NIST Cybersecurity Framework 2.0 pushes organisations to look at governance, protection, detection, and response as a system, not as separate checkboxes. That matters because phishing is usually an entry point into identity abuse, session theft, and business process abuse, not a standalone event.

For NHI Management Group, the key question is whether the programme limits what a phished user, a stolen token, or a spoofed help-desk request can do. If those paths remain open, the organisation has reduced awareness risk but not operational risk. In practice, many security teams discover this only after a mailbox takeover, fraudulent payment, or token replay has already occurred, rather than through intentional testing.

How It Works in Practice

Effective anti-phishing work starts by mapping the attacker path from initial lure to business impact. That means identifying which identities, apps, and service accounts can approve high-risk actions, which sessions can be reused, and where secrets are exposed in mailboxes, chat tools, ticketing systems, or developer workflows. The control objective is to make a successful phish low-value even when it lands.

At the operational level, this usually combines several measures:

• Phishing-resistant authentication for high-value users and workflows, especially where account recovery or admin approval is possible.
• Conditional access and step-up checks for risky locations, devices, or impossible-travel patterns.
• Strong help-desk verification so an attacker cannot reset credentials or enroll a new factor through social engineering.
• Least privilege on payment approval, inbox delegation, secrets access, and admin portals.
• Detection for anomalous OAuth consent, mailbox forwarding rules, token replay, and unusual session creation.

The incident response side matters just as much. Teams should rehearse what happens when a user reports a phish after clicking, because early containment depends on revoking sessions, resetting factors, checking inbox rules, and reviewing downstream authorisations quickly. For AI-enabled triage or detection, use output validation and human review, because model-driven summaries can miss identity abuse chains or overstate confidence. The MITRE ATT&CK knowledge base is useful for linking phish-driven initial access to later techniques such as valid accounts and credential access, while OWASP guidance helps security teams test control weakness in real application paths.

These controls tend to break down when legacy authentication, shared admin accounts, or loosely governed service desks are still allowed to bypass modern access checks because the phishing path then becomes a straight line to privileged action.

Common Variations and Edge Cases

Tighter anti-phishing controls often increase friction for users and service desks, so organisations have to balance security gain against operational delay and support load. That tradeoff becomes sharper in businesses that depend on frequent external collaboration, fast payment approvals, or distributed support teams.

There is no universal standard for this yet, but current guidance suggests phishing defence should be tiered by risk rather than applied uniformly. High-value identities need stronger controls than low-impact accounts, and recovery paths need more scrutiny than ordinary sign-in paths. Where attackers target executives, finance teams, developers, or support staff, the most important question is not who clicked but what privilege that account held after the click.

Identity bridges matter here. A phish that leads to inbox access can expose API keys, cloud console sessions, password reset links, and NHI secrets, turning a human compromise into machine compromise. That is especially important in environments with automation, SaaS sprawl, or shared operational tooling. The Zero Trust Architecture model is useful when thinking about continuous verification of access paths, but it should not be treated as a slogan. It works best when paired with real privilege reduction and monitored recovery processes.

For organisations handling regulated payments or sensitive personal data, the OWASP resources and the NIST identity guidance can help separate awareness training from measurable control objectives. The practical lesson is simple: if a phished identity can still approve, reset, delegate, or export, the programme is only partially effective.

Related resources from NHI Mgmt Group

• What do security teams get wrong about consent phishing?
• What do security teams get wrong about kit-based phishing detection?
• What do security teams get wrong about risk assessment in identity programmes?
• What do security teams get wrong about device code phishing?