Why does MFA remain necessary even when organisations use SSO, passkeys, or other phishing-resistant controls?

MFA still matters because authentication failures often happen at the session, app, or access-path level, not only at login. SSO and passkeys reduce risk, but they do not eliminate credential abuse, token theft, or compromised browser sessions. Strong programmes treat MFA as one layer in a broader identity control stack, not as a standalone fix.

Why This Matters for Security Teams

MFA remains necessary because modern attacks rarely stop at a password prompt. SSO and passkeys reduce phishing exposure, but they do not remove the need to verify access when a browser session is hijacked, a token is replayed, or an authenticated user is forced down a risky access path. NIST’s control baseline for authentication and session protection still expects layered safeguards, not a single control that ends the discussion. Security teams that treat “phishing-resistant” as “risk eliminated” often underinvest in session monitoring, step-up checks, and recovery controls.

This is especially visible in credential theft and token abuse cases documented by NHI Management Group, including the Microsoft Midnight Blizzard breach and the CoPhish OAuth Token Theft via Copilot Studio research. The practical lesson is simple: authentication assurance must extend beyond the initial login event. In practice, many security teams encounter compromise only after an active session has already been abused, rather than through intentional detection at the point of access.

How It Works in Practice

Strong identity programmes treat MFA as one layer in a broader access stack. SSO improves user experience and centralises policy. Passkeys make phishing much harder. MFA still matters because access can be approved, then later abused through the session, the browser, a refresh token, or a delegated app grant. That is why security teams pair MFA with device trust, conditional access, token binding where supported, short session lifetimes, and reauthentication for high-risk actions.

For control design, the question is not whether a user authenticated once, but whether the current request is still trustworthy. A useful operating model is:

• require MFA or step-up verification for privileged actions, new devices, and unusual geo-location or risk signals;
• limit session duration and revoke access on suspicious activity;
• protect recovery flows, since account reset paths are often weaker than primary login;
• review OAuth app consent, delegated scopes, and service-to-service access separately from user login.

NIST SP 800-53 Rev. 5 explicitly frames access control as a combination of identification, authentication, authorisation, and session management, not a single gate. That is why the Ultimate Guide to NHIs — Standards is relevant here too: once identity is used to grant persistent access, the risks extend well beyond human login friction. The same pattern shows up in secrets exposure, such as the DeepSeek breach, where access risk was not confined to a password event. These controls tend to break down when legacy apps cannot enforce session revalidation or when broad token lifetimes make revocation too slow to matter.

Common Variations and Edge Cases

Tighter authentication often increases friction, so organisations must balance usability against the cost of account takeover. That tradeoff is real, especially for executives, developers, and support teams who use high-privilege workflows all day.

Current guidance suggests three common exceptions need special treatment. First, some environments use passkeys and still retain MFA for recovery, administrator actions, and risky reauthentication prompts. Second, SSO can reduce the number of login events, but it can also concentrate blast radius if the IdP, token issuer, or browser session is compromised. Third, phishing-resistant controls are strong for human sign-in, but they do not fully address service accounts, API tokens, or agent-driven access paths.

That is why many programmes keep MFA in place while also adding conditional access and short-lived tokens. The goal is not duplicate friction. The goal is layered assurance, aligned to the NIST SP 800-53 Rev. 5 Security and Privacy Controls model and informed by identity failure cases such as the Schneider Electric credentials breach. There is no universal standard for removing MFA entirely, and current best practice is to keep it as a fallback and step-up control wherever session or recovery risk remains material.

Related resources from NHI Mgmt Group

• Should organisations prioritise phishing-resistant MFA over other identity projects?
• Why do email attacks remain effective even when organisations use MFA?
• Why do phishing-resistant MFA controls still fail against social engineering?
• Should organisations rely on SSO and MFA as their main identity controls?