Passwordless authentication is only secure when cryptography replaces shared secrets

At a glance

What this is: This is an explainer on passwordless authentication, and its core finding is that passwordless is not automatically phishing-resistant unless it uses cryptographic public-key binding.

Why it matters: It matters because IAM teams need to distinguish user experience changes from real assurance gains when deciding how to replace passwords across web, desktop, voice, and machine channels.

By the numbers:

• NIST SP 800-63A-4 no longer recognizes security questions as acceptable identity proofing.

👉 Read Scramble ID's guide to passwordless authentication and phishing resistance

Context

Passwordless authentication removes the reusable password from the sign-in flow, but that alone does not make authentication resistant to phishing or relay attacks. The real question for identity programmes is whether the method replaces shared secrets with origin-bound cryptographic proof, because that determines whether the control actually changes the attack surface.

For IAM teams, the governance issue extends beyond browser login. Desktop access, voice channels, in-person verification, and machine-to-machine authentication all need assurance models that do not quietly fall back to passwords, OTPs, or bearer tokens when the web experience is modernised.

Key questions

Q: How should security teams implement passwordless authentication without weakening assurance?

A: Start by separating passwordless methods into two groups: cryptographic, phishing-resistant methods and merely password-free methods. Deploy passkeys or comparable origin-bound credentials for high-risk users first, keep fallback tightly governed, and remove weaker alternatives only after recovery, helpdesk, and alternate channels are secured.

Q: Why do some passwordless methods still leave organisations exposed to phishing?

A: Because they remove the password field but keep a relayable factor in place. Magic links, SMS OTP, and some push approval flows can still be intercepted, forwarded, or socially engineered, so the attacker bypasses the password without defeating the underlying identity proof.

Q: What do organisations get wrong when they treat passwordless as a single control?

A: They confuse user convenience with authentication strength. A programme can eliminate passwords in the browser and still rely on weak recovery, email links, OTPs, or passwords in other channels, which means the attack surface is reduced in one place but preserved elsewhere.

Q: How do teams know whether passwordless is actually improving security?

A: Measure how much authentication traffic is truly origin-bound and how often users can still authenticate through weaker fallback paths. If passwordless adoption rises but relayable methods remain common, the programme has improved usability more than assurance.

Technical breakdown

Passkeys and WebAuthn: why origin-bound cryptography matters

FIDO2 is the umbrella standard and WebAuthn is the browser API that implements it. During registration, the authenticator creates a public-private key pair scoped to the relying party, then keeps the private key on the device. During authentication, the browser checks the origin, the authenticator signs a fresh challenge, and the server verifies the signature against the stored public key. That origin check is what blocks fake login pages from relaying the credential. In practice, passkeys change authentication from secret recovery to cryptographic proof.

Practical implication: treat passkeys as a control upgrade only when the implementation binds the credential to origin and removes shared-secret fallback.

Passwordless methods that still leave relay paths open

Not every passwordless method removes the attacker’s leverage. Magic links, SMS OTP, and some push flows eliminate the password field, but they still rely on a bearer token, a relayed code, or a user approval that can be intercepted, forwarded, or socially engineered. The protocol changes, but the trust primitive remains weak because possession is not strongly bound to the authenticating device. That is why these methods may improve usability while leaving phishing exposure largely intact.

Practical implication: do not classify a passwordless rollout as phishing-resistant unless the protocol eliminates reusable or relayable credentials.

Enterprise passwordless must cover every authentication channel

A web-only passwordless deployment leaves the rest of the identity estate unchanged. If call centers, desktops, facility checks, or API authentication still depend on passwords, security teams have only shifted the weakest point, not removed it. True enterprise passwordless applies cryptographic identity consistently across user and machine channels, using device-bound proofs for people and sender-constrained tokens or client assertions for service-to-service flows. The governance challenge is consistency across channels, not isolated modernization.

Practical implication: inventory every authentication touchpoint before calling the programme passwordless, then remove password fallback channel by channel.

NHI Mgmt Group analysis

Passwordless is an assurance model, not a UI change: The article correctly separates password removal from phishing resistance, and that distinction is the real governance issue. Removing the password field changes user experience, but only cryptographic binding changes the attack surface. Practitioners should evaluate authentication by what the protocol still allows an attacker to relay, steal, or reuse.

Shared-secret authentication is a broader identity problem than web login: Passwords are only one expression of the larger control failure, which is dependence on reusable credentials across channels. When desktop, voice, and machine authentication preserve that dependency, the organisation has modernised a single entry point while leaving the identity programme exposed. The implication is that IAM strategy must be channel-complete, not browser-complete.

Passkey adoption will create a false sense of closure unless fallback is governed: Even strong passwordless methods can be undermined if password recovery, helpdesk resets, or alternate authenticators remain weak. Identity teams should treat fallback paths as part of the control, not as exceptions outside the control boundary. In practice, the real risk often shifts from the login screen to the recovery and exception process.

Cryptographic identity is now the baseline for both human and machine authentication: The same strategic logic that makes passwordless necessary for people is already visible in workload identity and service-to-service flows. Strong identity programmes are converging on the same principle across actor types, which means human IAM, NHI governance, and device trust are no longer separable design problems. Practitioners should align their identity architecture around proof, not secrets.

Origin binding is the named concept that explains why some passwordless methods work and others fail: Passwordless systems only become resilient when the authenticator verifies the relying party before releasing a signature. Without origin binding, the flow can still be relayed, forwarded, or socially engineered. The practical conclusion is that assurance comes from protocol design, not from the mere absence of a password.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, which shows how slowly compromised credentials are often remediated in practice.
• For the broader control model behind this problem, see Ultimate Guide to NHIs - Static vs Dynamic Secrets and its discussion of replacing long-lived secrets with better-bound identity.

What this signals

Origin binding is becoming the dividing line between modern authentication and cosmetic password removal: IAM programmes should expect auditors and security architects to ask whether a method is cryptographically bound to the relying party, not whether the login screen lacks a password. The organisations that can answer that question clearly will be better positioned to defend both user and machine identities.

The operational risk is fallback, not just primary authentication. If recovery, helpdesk, or alternate channels still rely on email links, OTPs, or password reset workflows, the strongest passkey deployment can be undercut by the weakest path in the chain.

As passwordless spreads into desktop and machine channels, identity teams need a common governance model for proof, recovery, and exception handling. That aligns with the broader shift from secret management to trust-bound identity, the same shift that also underpins NHI governance across service accounts and workload credentials.

For practitioners

• Classify passwordless methods by phishing resistance Separate passkeys, platform authenticators, and security keys from magic links, SMS OTP, and push approval flows in your control catalogue. Use that classification in risk reviews, not the generic label passwordless.
• Map every authentication channel before you redesign policy Inventory web, mobile, desktop, voice, in-person, and machine-to-machine sign-in paths, then identify where reusable secrets still exist. A programme is not passwordless if one channel still depends on passwords or bearer tokens.
• Govern fallback and recovery as first-class controls Review helpdesk recovery, break-glass access, and alternate authenticator enrollment with the same scrutiny as primary sign-in. Weak recovery paths often reintroduce the very secret-based risk passwordless was meant to remove.
• Extend cryptographic identity to non-web channels Use device-bound confirmation for voice and in-person workflows, and sender-constrained or assertion-based methods for service authentication. If those channels stay secret-based, attackers will route around your strongest browser control.
• Measure phishing resistance, not just adoption Track how much of the user base is on methods that verify origin and remove relayable credentials, then measure how often users can still fall back to weaker options. Adoption without assurance tells you little about actual risk reduction.

Key takeaways

• Passwordless only reduces risk when it replaces shared secrets with cryptographic proof, not when it merely hides the password field.
• Passkeys, platform authenticators, and security keys are the methods that consistently deliver phishing resistance, while links, OTPs, and approvals can still be relayed or intercepted.
• Identity teams should govern recovery, fallback, and non-web channels as part of the authentication control, because attackers will use the weakest path that still authenticates the user.

Key terms

• Passwordless Authentication: Authentication that verifies identity without requiring a reusable password. In practice, the strongest versions replace shared secrets with cryptographic credentials, device-bound proofs, or biometrics that unlock a local key. Weak versions may remove the password field but still rely on relayable tokens or codes.
• Phishing-Resistant Authentication: Authentication that cannot be convincingly replayed through a fake login page or real-time relay attack. The credential is bound to the legitimate relying party or device, so interception alone does not produce a usable sign-in artefact. This is a property of the protocol, not of the user interface.
• Passkey: A public-key credential used for passwordless sign-in, usually stored on a device or synced through a platform credential manager. The private key never crosses the network, which removes the shared secret problem associated with passwords and most OTP-based methods. Assurance depends on origin binding and recovery governance.
• Fallback Authentication: An alternate sign-in method used when the primary method is unavailable, locked out, or not yet enforced. Fallback is often the weakest part of an identity programme because it reintroduces passwords, email links, or helpdesk-driven verification that attackers can exploit more easily than the primary control.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.

This post draws on content published by Scramble ID: What Is Passwordless Authentication? Read the original.