What are the signs that an organisation is falling behind on phishing resistant authentication?

Why This Matters for Security Teams

When phishing resistant authentication is lagging, the problem is rarely just a missing feature. It usually shows up as inconsistent enrollment, fallback to weaker methods, and a login experience that only the most security-aware users can complete reliably. That creates uneven protection across the workforce, which is especially dangerous for admin, finance, support, and incident response accounts. Guidance in NIST SP 800-63 Digital Identity Guidelines and NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that authentication strength is part of a broader access governance problem, not a standalone technology choice.

The warning signs become more serious when phishing resistance is treated as optional or only applied to a subset of users. That usually means the organisation has not aligned identity policy, device posture, and help desk processes well enough to support modern factors such as passkeys, device-bound credentials, or hardware-backed authentication. NHI Management Group research also shows how often identity weaknesses extend beyond humans: only 5.7% of organisations have full visibility into their service accounts, and 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation. In practice, many security teams notice the gap only after a phish succeeds or a high-value account is recovered from misuse, rather than through any planned control test.

How It Works in Practice

A mature phishing resistant programme makes it hard for an attacker to reuse stolen credentials, intercept one-time codes, or coerce users into handing over a login secret. That means the organisation must support strong factors end to end: enrollment, device binding, recovery, and exception handling. If any one of those steps falls back to passwords or SMS, the control is weaker than the policy suggests.

Operationally, the most common signs of delay are visible in the rollout pattern. Security teams often see:

• Different login requirements by department, with executives or technical staff protected first and everyone else left behind.
• Users who can sign in with phishing resistant methods only on managed devices, while contractors or frontline workers are pushed to weaker alternatives.
• Recovery paths that rely on email links, help desk overrides, or knowledge-based checks, which become the soft spot in the programme.
• Confusion about whether MFA is mandatory, recommended, or only enforced for certain applications.

This is where real-world behaviour matters. A workforce that still relies on username and password for critical accounts is not just behind on authentication tooling, it is behind on operational readiness. The same pattern appears in identity incidents that start with credential capture and end with privilege abuse, including cases such as CoPhish OAuth Token Theft via Copilot Studio and the Twitter Source Code Breach, where access paths and account protections were part of the broader failure chain. For identity and access programmes, phishing resistance should be measured by who can enroll, who can recover, and who can still be phished through a fallback path. These controls tend to break down in hybrid environments where BYOD, legacy apps, and fragmented help desk workflows force exceptions back into the process.

Common Variations and Edge Cases

Tighter authentication often increases rollout friction, requiring organisations to balance security gains against user support load and application compatibility. That tradeoff is real, especially in environments with legacy systems, outsourced operations, or geographically distributed workforces. Best practice is evolving, and there is no universal standard for how fast every user group must be moved at once.

Some organisations look advanced because they have MFA turned on, but still fall behind because the factor is not phishing resistant. Push prompts, one-time codes, and email-based recovery can all be abused if the attacker has the right timing or social engineering playbook. For that reason, current guidance suggests focusing less on the label MFA and more on whether the method resists adversary-in-the-middle attacks and credential replay.

Edge cases matter. Shared kiosks, call centres, third parties, and emergency access accounts often need tailored treatment, but tailoring should not become permanent exception sprawl. The same applies where strong auth is available but users are not trained to recognise when a login is weaker than it should be. NHI Management Group’s broader research on identity risk shows how fast control gaps widen when governance and visibility lag behind implementation. That is why phishing resistance should be monitored as a lifecycle issue, not a one-time deployment project. Organisations that rely heavily on legacy federation or unmanaged recovery flows often discover the gap only after a phishing campaign has already bypassed their “MFA” layer.

Related resources from NHI Mgmt Group

• What are the signs that an organisation’s identity controls are failing against attacker-in-the-middle phishing?
• Why do phishable recovery methods weaken phishing-resistant authentication after a key is lost?
• What are the signs that a mobile penetration testing program is falling behind development velocity?
• What is the difference between defending a SaaS account with MFA and defending it with phishing-resistant identity controls?