Why do passwordless programmes still need MFA and step-up authentication?

Why passwordless still needs another layer when conditions change

Passwordless improves sign-in by removing the password attack surface, but it does not make every login equally trustworthy. Assurance still has to rise when the context changes, such as a new device, a shared workstation, an unfamiliar network, or an action that carries higher business impact. That is why MFA and step-up checks remain part of a mature authentication design.

Most passwordless programmes are built around a normal baseline, not a permanently trusted user session. If the user is on a known device with a strong authenticator, the system can keep friction low. When the context shifts, the programme needs a way to re-check the claimant before granting the next privilege or sensitive action.

Passwordless also does not eliminate identity recovery, session risk, or account takeover paths. A passkey or other phishing-resistant method can still be paired with additional verification for device enrolment, recovery, help desk reset, or an unusual transaction. The practical objective is to avoid making one successful factor, or one trusted device, the only control that matters.

Where MFA and step-up add value in a passwordless flow

MFA in a passwordless environment is often less about replacing the primary sign-in method and more about increasing assurance at the right moments. The strongest use cases are access to privileged functions, elevation from a low-risk to a high-risk action, and recovery or re-binding events where the original authenticator is no longer enough on its own.

Step-up authentication is especially useful when the environment changes faster than the user profile does. A user may still be legitimate, but the current request may be less ordinary than the last one, so the system should ask for a stronger proof before continuing. That makes the control adaptive instead of uniformly heavy-handed.

For programmes that rely on phishing-resistant methods, the key design question is not whether the user has "already authenticated", but whether the current trust level is still adequate for the requested operation. Passwordless and Passkeys Guide is useful here because it frames passkeys as a strong sign-in method, not a substitute for all downstream access decisions.

What breaks when organisations treat passwordless as the whole answer

The common failure is over-trusting the first successful sign-in. Attackers do not need to defeat passwordless everywhere if they can abuse recovery, session theft, device enrolment, or a weaker access path that was left unprotected. In practice, the risk often shifts from password guessing to token theft, help desk social engineering, or abuse of legacy and shared endpoints.

This is why passwordless programmes still need conditional escalation logic. If an attacker gets hold of a trusted device, hijacks a session, or triggers a recovery flow, the organisation needs a second decision point before the account can be used for sensitive work. Workforce Identity Security Guide covers the operational realities of phishing-resistant MFA, passkeys, help desk resets, and step-up authentication in the same lifecycle.

Real-world breaches also show that "logged in" and "secure" are not the same thing. CitrixBleed exploitation 2023 illustrates how session token theft can bypass MFA entirely once a session is established, which is why step-up and session revalidation matter after initial authentication.

Practitioner Guidance

What to verify: Confirm that your passwordless design distinguishes between initial sign-in, device trust, session continuity, and sensitive action approval. If those are all treated as one event, the programme will either over-prompt users or under-protect high-value actions.

Decision rule: Use step-up when the request changes the risk profile, not just when the user has not signed in recently. New device, recovery flow, admin action, payment, export, or privilege escalation are good triggers for an additional check.

What good looks like: Low-friction sign-in for routine access, with visible escalation only when context or privilege changes. The system should preserve usability for normal work while making it hard to turn one successful authentication into unlimited trust.

Common mistake: Treating passkeys or another passwordless method as a complete replacement for MFA policy. That usually leads to weak recovery, weak help desk processes, and no meaningful response when the session or device context becomes suspicious.

Practitioner takeaway: Passwordless should reduce routine friction, not flatten assurance. The best programmes keep the primary sign-in strong, then re-check identity only when context, device, or privilege makes the next action materially riskier.

Related resources from NHI Mgmt Group

• Why does passwordless authentication still need MFA and session controls?
• Why do passwordless authentication programmes still need strong enrollment controls?
• Why do organisations still need step-up verification after strong authentication is in place?
• Why do passwords, MFA, and passwordless methods still fail to solve workforce authentication on their own?