Passwordless authentication exposes the limits of MFA-only strategies

At a glance

What this is: This is an analysis of why MFA-only authentication remains vulnerable and why passwordless methods change the trust model by removing the reusable password factor.

Why it matters: It matters because IAM teams have to decide whether they are still protecting login flows with factors that can be phished, replayed, or fatigue-abused, or whether they are moving to device-bound authentication that is harder to steal.

Context

Passwordless authentication is not just a user-experience upgrade. It changes the authentication boundary by removing the reusable password factor and shifting verification to device-bound credentials, local user verification, and cryptographic binding to the login origin.

The governance problem is that many MFA programmes still depend on a factor that can be intercepted, reused, or socially engineered. For IAM, PAM, and identity architects, the practical question is whether authentication policy still assumes a password can safely remain part of the control stack.

Key questions

Q: How should security teams phase out MFA-only login strategies?

A: Start with the accounts and workflows most exposed to phishing, credential stuffing, or helpdesk abuse. Replace password-dependent primary login with phishing-resistant authentication where possible, then tighten fallback and recovery paths so the old weakest factor does not remain the real control boundary.

Q: Why do passwords and OTPs still create risk in MFA programmes?

A: Because both can be intercepted, reused, or coerced. A password plus OTP model improves security, but it still leaves a reusable secret in play and depends on channels that attackers routinely target through phishing, SIM swapping, replay, or MFA fatigue tactics.

Q: What are the signs that a passwordless deployment is not actually enforcing strong authentication?

A: A weak deployment often shows up when user verification is optional, when the identity provider does not enforce it, or when the relying party has no attestation data to assess device trust. Another warning sign is any design that allows key material to be copied off the device, because that undermines the hardware-backed model and makes cloned authenticators possible.

Q: What should IAM teams prioritise when legacy systems do not support passkeys well?

A: Prioritise the applications that matter most to security and user friction, then use phased rollout and compatibility testing to isolate where legacy constraints are unavoidable. The goal is to prevent old systems from becoming permanent exceptions that preserve password dependence. If the legacy layer cannot be modernised immediately, govern its fallback tightly and separately.

Technical breakdown

Why password-based MFA remains phishable

Traditional MFA often pairs a password with a second factor such as an OTP, push notification, SMS code, or email code. That improves the baseline over passwords alone, but it still leaves the first factor reusable and the second factor vulnerable to interception, fatigue, or relay attacks. If an attacker can capture the password and the second factor, the control is bypassed without ever defeating the whole authentication flow. This is why password-centric MFA is not the same as phishing-resistant authentication. It reduces risk, but it does not remove the core weakness created by a credential that can be typed, reused, or socially engineered.

Practical implication: treat password-plus-second-factor as a transitional control, not a phishing-resistant end state.

How FIDO and passkeys change authentication trust

FIDO2 and passkeys replace the shared secret with an asymmetric key pair. The private key is generated on the device and kept non-exportable, while the public key is registered with the service. Authentication then depends on the device proving possession of the private key and the user locally unlocking it, usually with biometrics or a PIN. Because the credential is bound to the origin, a phishing site cannot reuse it against a different domain. This is a structural change, not a cosmetic one: the attacker is no longer trying to steal a password equivalent but to compromise a device-specific authentication ceremony.

Practical implication: prioritise origin-bound, non-exportable authenticators for high-risk accounts and workflows.

Why biometrics and device binding are governance controls, not UX features

In passwordless systems, biometrics do not identify the user remotely. They act as a local release mechanism for a key stored on the device. That means the biometric template stays on the device, and the relying party never receives the raw biometric data. The governance significance is that the identity control shifts from knowledge of a secret to possession of a managed device plus local verification. In healthcare and critical infrastructure, that shift also supports badge-based login and tap-and-go access, which reduces friction while preserving stronger assurance than OTP-based workflows.

Practical implication: govern passwordless rollouts as identity assurance changes, not as convenience projects.

Threat narrative

Attacker objective: The attacker wants to authenticate as the legitimate user and reach protected systems without needing to defeat a phishing-resistant authenticator.

1. Entry begins when the attacker targets a password-based login flow through phishing, credential stuffing, SIM swapping, or OTP interception.
2. Credential access succeeds because the reusable password or second factor can be captured, relayed, or coerced through MFA fatigue and similar tactics.
3. Impact follows when the attacker logs in as the user, bypasses account protection, and gains access to the protected application or environment.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Password-centric MFA is a mitigation, not a trust reset. The article shows that password plus second factor still depends on a reusable credential that attackers can phish, steal, or replay. That means the programme may improve hurdle height while preserving the same attack surface. For identity teams, the decision is no longer whether MFA exists but whether the authentication model still allows a stolen secret to remain useful.

Phishing-resistant authentication is really about removing shared secrets from the path. FIDO2 and passkeys shift trust from something the user knows to something the device proves and the user locally unlocks. That matters because authentication assurance improves only when the relying party can verify both origin and possession without exposing a reusable secret. The practical consequence is a lower-value target profile for accounts that are most likely to be attacked.

Identity assurance now depends on the device as much as the person. When the private key stays on the device and local verification gates release, the managed endpoint becomes part of the authentication boundary. That changes lifecycle governance, recovery planning, and helpdesk recovery design. IAM and security teams need to treat device binding, recovery paths, and registration policy as first-class identity controls.

Passkey adoption exposes a governance gap between policy and reality. Many organisations still say they want stronger authentication while retaining workflows that rely on SMS, email, or OTP fallback. That creates a hidden downgrade path. The implication is that authentication policy has to be written around the weakest permitted recovery and fallback method, not the strongest primary factor.

Device-bound authentication is becoming the practical baseline for higher assurance access. The article aligns with the direction of current guidance that favours stronger, phishing-resistant methods where services allow them. For practitioners, the real question is which populations and applications can move first, because mixed-mode authentication estates often leave the highest-risk users on the weakest path.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

Phishing-resistant authentication is now a governance decision, not a feature preference. Teams that keep password-based recovery and fallback paths in place are preserving the very downgrade routes attackers exploit. The more important boundary is no longer the primary login method alone, but whether the full recovery path still collapses back to a reusable secret.

Identity programmes should treat the device as an authentication control surface. Once the private key stays on the device and local verification gates release, endpoint governance becomes part of IAM design. That makes device integrity, registration policy, and replacement flows relevant to access assurance, not just endpoint hygiene.

For practitioners

• Replace password-first login paths Remove password-centric primary authentication from applications that support FIDO2, passkeys, or other phishing-resistant methods. Keep the strongest method as the default rather than an optional add-on.
• Eliminate weak fallback channels Review SMS, email code, and push-approval fallback paths for critical accounts, then remove or tightly restrict the ones that still allow phishing, SIM swap, or MFA fatigue abuse.
• Bind authentication to managed devices Use device-bound credentials and local verification for high-value users so the private key stays non-exportable and the relying party can verify origin-bound authentication.
• Redesign recovery and reset flows Treat account recovery, device replacement, and helpdesk resets as part of the authentication control set, because attackers often target the weakest fallback rather than the primary factor.

Key takeaways

• Password-based MFA reduces risk, but it does not eliminate the attack patterns that target reusable credentials and weak fallback factors.
• Passwordless authentication changes the trust model by binding access to a device-held private key and local user verification.
• IAM teams should treat recovery paths, device binding, and fallback controls as part of the authentication architecture, not as secondary details.

Key terms

• Passwordless Authentication: An authentication approach that removes passwords and uses a device-bound cryptographic key plus local user verification. It reduces phishing and replay risk, but it only improves assurance when enrollment, recovery, and revocation are tightly governed.
• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
• Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
• Local user verification: A device-side check that confirms the rightful user before releasing a cryptographic authenticator. This is usually done with biometrics or a PIN, and it matters because the approval happens on the trusted device rather than through an interceptable remote prompt or code.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.