What happens when phishing resistant authentication is only rolled out to some employees?

Why Partial Rollout Creates Enterprise Risk

Phishing-resistant authentication only protects the people who actually use it. When deployment is uneven, attackers simply move to the weakest path: users still on passwords, legacy MFA, helpdesk reset flows, or unmanaged devices. That turns an authentication upgrade into a segmentation problem, because compromise of one weak account can still support email takeover, internal pivoting, and privilege escalation. NHI Mgmt Group’s research shows how often identity weaknesses become systemic, with 80% of identity breaches involving compromised non-human identities such as service accounts and API keys.

The same logic applies to human authentication: security control coverage matters as much as control strength. Guidance in NIST SP 800-63 Digital Identity Guidelines and NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that identity assurance and authentication controls need to be applied consistently to reduce adversary opportunity. In practice, many security teams discover the real weakness only after a single non-upgraded account is used to bypass a much stronger control elsewhere.

How Attackers Exploit Mixed Authentication States

Partial deployment creates a predictable decision tree for attackers. If they cannot phish a hardware-key user, they target someone who can still be tricked with a password reset or approval prompt. If the user cannot be phished directly, they may call the helpdesk, abuse recovery procedures, or compromise a device enrolled with weaker assurance. Once inside, they look for mail rules, token theft opportunities, or lateral movement into higher-value systems.

That is why rollout strategy must treat authentication as an enterprise policy, not an opt-in feature. A practical deployment usually includes:

• Prioritising high-risk groups first, such as administrators, finance, HR, and executives.
• Closing fallback paths, including SMS, weak recovery questions, and loosely governed helpdesk resets.
• Standardising device trust and session handling so upgraded users are not bypassed through lower-assurance channels.
• Monitoring for mixed-state abuse, especially account recovery spikes and anomalous authentication from legacy paths.

For organisations that also rely on secrets and delegated access, the risk is compounded by identity sprawl. NHI Mgmt Group’s Ultimate Guide to Non-Human Identities notes that 97% of NHIs carry excessive privileges, which is a useful reminder that identity controls fail most often when coverage is incomplete. Attack patterns such as CoPhish OAuth Token Theft via Copilot Studio and the Twitter Source Code Breach show how a single account or credential path can be enough to expose much larger assets. These controls tend to break down when legacy authentication is retained for service desks, contractors, or regional business units because attackers concentrate on the weakest exception path.

Where Rollout Plans Usually Go Wrong

Tighter authentication usually increases rollout friction, requiring organisations to balance security gain against user support load, device readiness, and legacy application constraints. That tradeoff is real, but it does not justify indefinite mixed-state deployment.

Best practice is evolving, and there is no universal standard for exactly how fast every organisation must complete migration. Still, the common failure modes are consistent: exempting “temporary” populations that never migrate, keeping old recovery methods alive for convenience, or assuming that pilot success proves enterprise readiness. Those choices create long-lived gaps that are easy to exploit and hard to explain after an incident.

The cleaner approach is to define a firm end state, publish a migration schedule, and retire weaker paths on a date certain. If some employees remain on legacy authentication, the organisation should treat that as an active residual risk, not as an acceptable steady state. The practical lesson is simple: attackers do not need to break the strongest login when the weakest one is still available.

Related resources from NHI Mgmt Group

• Why do phishable recovery methods weaken phishing-resistant authentication after a key is lost?
• What is the difference between defending a SaaS account with MFA and defending it with phishing-resistant identity controls?
• What happens when authentication is easy for users but weak on fraud controls?
• What happens when employees use generative AI on broadly shared company files without proper access controls?