When should organisations replace legacy MFA with FIDO2 hardware tokens?

Why This Matters for Security Teams

The decision to replace legacy MFA is usually triggered by a gap in threat resistance, not by a preference for new hardware. SMS codes, push approvals, and one-time passwords were designed for a simpler access model, but they are weak against phishing, session hijacking, and approval fatigue. Current guidance in NIST SP 800-63 Digital Identity Guidelines supports stronger authenticators when assurance matters, especially for remote access and privileged workflows.

For NHI and agentic environments, the same logic becomes more urgent because credentials are often shared, duplicated, or left active far longer than intended. NHIMG research on the Guide to the Secret Sprawl Challenge shows how secrets and tokens spread across tickets, chats, repos, and tools, creating exposure paths that legacy MFA does not meaningfully reduce. The issue is not only user login, but the broader trust chain around identities, devices, and sessions. In practice, many security teams discover MFA weakness only after a phishing campaign or token replay incident has already bypassed their control assumptions.

How It Works in Practice

FIDO2 hardware tokens are most effective when organisations need phishing-resistant authentication tied to a physical device and a verifiable public-key credential. Instead of sending a reusable secret over the network, the token signs a challenge from the service, so the private key stays on the device. That changes the attack surface materially: an attacker who steals a password, intercepts a code, or tricks a user into approving a prompt still cannot easily replay the authenticator.

In practice, replacement works best as a staged control change rather than a blanket switch. Security teams usually start by moving high-risk populations first, such as administrators, finance users, help desk operators, and anyone with access to cloud consoles or privileged data. The policy should also be paired with session controls, device posture checks, and recovery procedures, because hardware tokens solve authentication strength but not every account lifecycle problem.

• Require FIDO2 for privileged access before extending it to the full workforce.
• Use it alongside Zero Trust policy and conditional access, not as a standalone control.
• Retire push-based approvals where prompt bombing is a realistic threat.
• Document lost-token recovery, enrolment, and offboarding so the control does not become operationally brittle.

For organisations dealing with both human and non-human access, the lesson is broader: authentication strength must match the value and mobility of the identity. NHIMG research in the 2025 State of NHIs and Secrets in Cybersecurity found that 91% of former employee tokens remain active after offboarding, a reminder that identity controls fail when lifecycle discipline is weak. These controls tend to break down in large federated environments where recovery processes are inconsistent across business units and legacy apps cannot support modern authenticators.

Common Variations and Edge Cases

Tighter authentication often increases rollout friction, help desk load, and recovery complexity, requiring organisations to balance stronger phishing resistance against user support constraints. That tradeoff matters because some applications and user populations cannot move to FIDO2 on the same timeline.

Current guidance suggests prioritising replacement where the risk is highest, but there is no universal standard for a single cutover point. Legacy MFA may remain temporarily acceptable for low-risk, low-impact access, especially where device compatibility, accessibility needs, or shared kiosk workflows make hardware tokens impractical. In those cases, security teams should still reduce exposure by limiting session duration, enforcing step-up authentication for sensitive actions, and removing SMS wherever possible.

The most common failure mode is assuming FIDO2 alone solves identity governance. It does not. The control is strongest when paired with lifecycle enforcement, least privilege, and revocation discipline, especially in environments where secrets, tokens, and agent credentials move quickly across tools. That pattern is visible in NHIMG’s Salesloft OAuth token breach and JetBrains GitHub plugin token exposure, where the problem was not just login weakness but credential propagation after initial compromise. In mixed environments with legacy apps, shared accounts, or service credentials, the migration path is usually partial first, complete later, and never purely technical.

Related resources from NHI Mgmt Group

• What are the implications of using OAuth tokens in third-party integrations?
• What makes OAuth tokens risky in NHI environments?
• What common vulnerabilities do cloud applications face with OAuth tokens?
• Should organisations replace MFA with passwordless authentication?