Passwordless authentication is only secure when cryptography replaces shared secrets

At a glance

What this is: This article explains why passwordless authentication is only meaningfully stronger when it replaces shared secrets with cryptographic proofs, not when it merely removes the password field.

Why it matters: It matters because IAM teams can misclassify weak passwordless methods as phishing-resistant, leaving users, admins, and service channels exposed to relay, interception, and fallback abuse.

Context

Passwordless authentication is a sign-in model that verifies identity without a reusable password, but that does not automatically make it phishing-resistant. The control question is whether the method removes the shared secret from the protocol, or only hides it behind email links, one-time codes, or approval prompts.

For IAM teams, the governance problem is not user convenience alone. It is whether the organisation has shifted assurance from something an attacker can copy or relay to something the authenticator binds to the correct origin and device, and whether that same standard applies beyond the browser to desktop, voice, and machine channels.

Key questions

Q: How should security teams evaluate whether a passwordless authentication deployment is actually phishing resistant?

A: Security teams should verify that the authenticator itself is certified, not just the broader platform or server. They should confirm there is no fallback to passwords or OTPs, check that the solution aligns with phishing resistance requirements, and validate interoperability with approved identity systems. Certification status, factor handling, and fallback behavior are the key controls to review.

Q: When does passwordless authentication create more risk than it removes?

A: Passwordless authentication creates more risk when the organisation cannot manage device loss, account recovery, or user education. In that situation, users fall back to weaker exceptions or support teams improvise recovery steps, which expands the attack surface. The control is strongest when the security model, help desk process, and device lifecycle are aligned.

Q: How should enterprises roll out passwordless across multiple authentication channels?

A: Start by mapping every channel where identity is verified, including web, desktop, voice, in-person, and service-to-service flows. Then standardise the assurance model so weaker fallback channels do not become the default bypass for stronger web authentication.

Q: What is the difference between passkeys and other passwordless methods in practice?

A: Passkeys provide the strongest phishing resistance because they use cryptographic keys bound to a device or authenticator, while methods like magic links and OTPs still rely on delivery channels that can be intercepted or abused. Teams should reserve passkeys for higher-assurance use cases and use weaker methods only where the risk profile supports them.

Technical breakdown

Shared secrets versus cryptographic credentials

Passwordless methods diverge at the protocol layer. A magic link or SMS code removes the password field, but the link or code still behaves like a bearer secret that can be intercepted, forwarded, or relayed. FIDO2/WebAuthn passkeys are different because the private key never leaves the device, and the authenticator signs a fresh challenge only after validating the relying party origin. That origin binding is what blocks phishing and adversary-in-the-middle relay. In security terms, the question is not whether authentication is password-free, but whether the verifier is still accepting a reusable secret in another form.

Practical implication: classify passwordless methods by whether a shared secret still exists in transit, not by whether the user sees a password field.

Why phishing-resistant and passwordless are not the same

Phishing resistance is a stricter property than passwordless. A system can eliminate passwords and still remain vulnerable if an attacker can forward the credential, replay the token, or trick the user into approving a fraudulent prompt. That is why standards bodies distinguish between methods that are merely passwordless and methods that are actually phishing-resistant. The meaningful boundary is whether the authentication ceremony is bound to the legitimate origin and cannot be replayed outside that context. If it can be relayed in real time, the control has not escaped the phishing problem, it has renamed it.

Practical implication: require phishing-resistance criteria in policy, not just password removal, before treating a method as a control.

Why omnichannel passwordless changes the identity model

Web-only passwordless leaves the rest of the identity estate untouched. Enterprises still authenticate people through desktop sign-in, call centres, in-person verification, and machine-to-machine flows, and attackers will route to whichever channel has the weakest assurance. True passwordless governance therefore spans the full authentication surface, not just the browser. For machines, that means sender-constrained tokens or other cryptographic assertions instead of static API keys. For humans, it means the same assurance principles must hold across the user journey, or the weakest channel becomes the default bypass route.

Practical implication: inventory every authentication channel and apply the same assurance standard to desktop, voice, in-person, and machine access.

Threat narrative

Attacker objective: The attacker aims to obtain authenticated access without ever needing the original password, then use that access to pivot into additional systems or channels.

1. Entry occurs when the user is steered into a fake login flow or a relay path that accepts a passwordless artefact such as an SMS code, magic link, or approval prompt.
2. Credential access happens when the attacker captures the bearer token, forwarded link, or one-time code and reuses it before it expires or is consumed.
3. Escalation follows when the attacker uses the authenticated session to reach the user’s account, downstream applications, or adjacent channels that still trust the same identity proof.
4. Impact is account takeover, which can lead to broader credential abuse if the compromised identity has privileged access or trusted fallback paths.

Breaches seen in the wild

• Dropbox GitHub breach 2022: Phishing posing as CircleCI gave an attacker Dropbox staff GitHub access; 130 repositories with developer API keys were copied. Keys were rotated.
• Twilio 0ktapus breach 2022: SMS phishing of employees exposed 209 Twilio customers and 1,900 Signal users, part of the 0ktapus campaign against 130+ firms.

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

Passwordless only becomes a security control when it removes the shared secret from the protocol, not just from the user interface. That is the core governance distinction this article makes. A bearer link or one-time code may reduce password friction, but it does not materially change the attack model if it can still be copied or relayed. Practitioners should treat secret removal, not password removal, as the control boundary.

Phishing-resistant authentication is the real threshold, and passkeys are the clearest example of that threshold in practice. Origin-bound cryptographic verification changes the trust model because the authenticator refuses to sign for the wrong relying party. That is qualitatively different from accepting a code sent over another channel. In governance terms, the issue is not method naming but assurance property, and assurance property should drive policy exceptions, fallback design, and recovery paths.

Omnichannel identity governance is now part of passwordless maturity. Web login can be cryptographically strong while desktop, voice, or machine access remains dependent on weaker fallback paths. That creates a split assurance model that attackers will route around. The practitioner takeaway is that passwordless programmes should be evaluated as an identity architecture, not as a login feature.

Magic links and OTPs are passwordless convenience patterns, not equivalent substitutes for cryptographic authentication. They can reduce the visible password burden while leaving relay and interception exposure intact. That distinction matters for risk acceptance, because many programmes stop at user experience metrics and never test whether the method resists adversary-in-the-middle abuse.

Shared-secrets elimination is the named concept that should anchor passwordless governance. The question is whether the organisation has truly removed reusable credentials from the trust path. If the answer is no, the control is still operating inside the old password-era threat model, only with a different front end.

From our research library:

• The IBM/Ponemon 2025 Cost of a Data Breach Report found that phishing-initiated breaches cost an average of $4.8M each.

What this signals

Shared-secrets elimination: Passwordless programmes should be judged by whether they truly remove reusable credentials from the authentication protocol. If the replacement can still be copied, forwarded, or relayed, the organisation has changed the user experience more than the security model.

Many teams will need to extend passwordless governance beyond the browser if they want consistent assurance. Desktop login, call-centre verification, and machine-to-machine authentication often preserve weaker fallback paths, and that is where attackers will concentrate once web sign-in becomes harder to phish.

For practitioners

• Inventory passwordless by assurance level Separate methods that still use bearer artefacts, such as magic links and OTPs, from methods that use origin-bound cryptographic proof, such as passkeys and security keys.
• Set policy on phishing resistance Treat phishing resistance as a mandatory control requirement for privileged users, remote access, and high-risk transactions rather than accepting any password-free login flow.
• Extend controls beyond the browser Map desktop, voice, in-person, and machine authentication paths and remove fallback patterns that preserve shared secrets outside the web channel.
• Harden fallback and recovery Use monitored identity proofing and audited break-glass recovery instead of email-based password reset flows that recreate the same relay problem.
• De-risk shared secrets in machine flows Replace static API keys and other reusable machine secrets with sender-constrained or otherwise cryptographically bound authentication where service-to-service access is involved.

Key takeaways

• Passwordless is not automatically safer than passwords if the replacement still behaves like a bearer secret or a relayable approval.
• The article’s central distinction is between password removal and phishing resistance, which only cryptographic, origin-bound verification can provide.
• IAM teams should evaluate every authentication channel together, because the weakest fallback path will define the real security posture.

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.
• Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.