How should security teams reduce phishing risk without frustrating users?

Why This Matters for Security Teams

Phishing reduction often fails when teams add friction everywhere instead of removing the specific opportunities attackers exploit. Users then respond with risky workarounds, while defenders get a false sense of coverage from generic awareness training. Current guidance from NIST Cybersecurity Framework 2.0 favors outcome-based protection, but the practical challenge is balancing assurance with usability on the highest-risk accounts and actions.

This is especially important for NHI-heavy environments because phishing rarely stops at the inbox. Attackers target credentials, tokens, and recovery paths, then pivot into OAuth apps, admin portals, and shared automation systems. NHIMG research on Top 10 NHI Issues shows how credential weakness, visibility gaps, and over-privilege combine into broader identity risk. For human users, the same pattern appears when MFA is hard to use, recovery is weak, or sign-in prompts are unpredictable.

The security team’s job is not to make authentication harsher. It is to remove replayable factors, reduce the value of stolen credentials, and reserve stronger checks for privileged activity. In practice, many security teams encounter risky sign-in behaviour only after a support flood, an OAuth abuse incident, or a helpdesk reset has already occurred, rather than through intentional design.

How It Works in Practice

The most effective anti-phishing programs treat authentication as a layered control, not a single product choice. Start by eliminating replayable factors for privileged and high-impact accounts. Phishing-resistant MFA, such as FIDO2/WebAuthn, is the strongest fit where users can support it, because the credential is bound to the legitimate origin and cannot be trivially relayed. For lower-risk or legacy populations, current guidance suggests pairing simpler sign-in with tighter session controls, stronger recovery, and step-up authentication for sensitive actions.

In parallel, make the secure path the easiest path. That means reducing repeated prompts, shortening enrollment, and clarifying recovery so users do not route around policy. Ultimate Guide to NHIs — Why NHI Security Matters Now is a useful reminder that identity security succeeds when controls match the real attack surface, not when they simply add more checkpoints. For identity architecture, NIST CSF 2.0 supports this by tying access assurance to risk treatment rather than blanket inconvenience.

A practical rollout usually includes:

• Phishing-resistant MFA for administrators, finance, helpdesk, and remote access.
• Device-bound or passkey-based sign-in where supported.
• Strong account recovery with human verification and restricted reset workflows.
• Risk-based step-up checks for high-value transactions and privilege elevation.
• Targeted training that explains what a real prompt, link, or recovery request should look like.

Done well, this approach lowers attack success without creating daily friction for everyone. These controls tend to break down in highly distributed environments with legacy SSO, unmanaged devices, and shared admin access because the trust signals are too inconsistent to drive clean risk-based decisions.

Common Variations and Edge Cases

Tighter authentication often increases support burden, so organisations have to balance user convenience against the cost of account takeover and recovery abuse. That tradeoff is real, and current guidance suggests avoiding a one-size-fits-all rollout. A call centre, a developer platform, and a privileged admin console should not all use the same sign-in policy.

One common exception is frontline and contractor populations that cannot reliably use hardware keys or passkeys. In those cases, security teams may need a phased approach: stronger recovery, limited session duration, and stricter device checks first, then phishing-resistant MFA where enrollment is practical. Another edge case is service accounts and automation. Those should not be “protected” with human-style MFA at all; they need workload identity, short-lived secrets, and clear separation from user sign-in.

For organisations modernising identity at scale, NHIMG’s State of Non-Human Identity Security highlights how quickly identity gaps widen when visibility and governance lag. The same lesson applies to humans: controls must be visible, explainable, and proportional, or users will bypass them. Best practice is evolving toward continuous, context-aware authentication rather than static rules that apply the same burden to every account and every login.

Related resources from NHI Mgmt Group

• How should security teams reduce phishing risk in MFA without creating more user friction?
• How should teams reduce the risk of exposed AI credentials being abused?
• How should teams reduce risk from malicious npm package installs?
• How should NHS security teams reduce privileged access risk without disrupting clinical operations?