Passwordless authentication removes shared secrets and phishing risk

At a glance

What this is: This guide explains how passwordless authentication works and finds that removing shared secrets improves phishing resistance, user experience, and operational efficiency.

Why it matters: It matters because IAM, CIAM, and machine identity programmes can reduce attack surface and support burden only if they replace passwords with phishing-resistant recovery and rollout design.

By the numbers:

• The average person now juggles somewhere between 70 and 100 online accounts, and the password model has buckled under the weight.

👉 Read Ory's guide to passwordless authentication and passkey rollout trade-offs

Context

Passwordless authentication removes the shared secret from the login flow, which changes the security model rather than simply adding another factor. In practice, that makes it relevant to human IAM, customer identity, and machine identity because the core question is how an identity proves possession without exposing something reusable.

The governance problem is that password controls were built for memorised credentials, password resets, and shared-secret recovery. Once authentication becomes cryptographic, teams have to rework recovery, device loss handling, fallback methods, and assurance levels rather than treating passwordless as a cosmetic front-end change.

For IAM leads, the main issue is not whether passwordless is convenient. It is whether the programme can preserve assurance when users, devices, and services stop relying on passwords altogether and start depending on key-bound, device-bound, or locally unlocked credentials.

Key questions

Q: How should security teams implement passwordless authentication without creating new recovery risk?

A: Security teams should remove passwords from both primary login and recovery paths, then require stronger proofing for reset workflows than for normal sign-in. The main mistake is leaving a secret-based fallback in place while claiming the environment is passwordless. Recovery, support, and re-enrolment must be treated as high-risk identity events.

Q: Why do passwords remain such a common authentication weakness?

A: Passwords remain weak because they depend on human memory, user discipline, and secrecy under attack pressure. They are often reused, guessed, phished, or stolen. Once that happens, the control no longer verifies identity reliably. That is why password-only access is still a frequent point of failure.

Q: What do teams get wrong when they treat passwordless as a single project?

A: They often focus only on the human login experience and assume the rest of identity management will follow. In practice, passwordless touches authentication methods, device binding, recovery, exceptions, and privileged access. If those pieces are not designed together, the programme creates inconsistency instead of reducing risk.

Q: Who should own password governance when identity spans humans and non-human identities?

A: Ownership should sit with the identity programme, not just the help desk or endpoint team. Password governance affects human users, service accounts, and privileged access, so it needs shared accountability across IAM, PAM, and lifecycle governance. The key is to tie each credential to a business owner and an offboarding path.

Technical breakdown

How passkeys replace passwords with cryptographic proof

Passkeys use public-key cryptography. During registration, the device creates a key pair and keeps the private key locally while the service stores the public key. At login, the service sends a challenge and the device signs it, so the password never exists as a reusable secret. Because the signature is bound to the legitimate domain, phishing pages cannot replay it. This is why passkeys behave differently from passwords and from second factors that can still be intercepted or approved under pressure.

Practical implication: treat passkeys as a control shift, not a feature flag, and map where shared-secret assumptions still sit in your authentication stack.

Why passwordless changes MFA fatigue and support economics

Traditional MFA often adds a password plus a push prompt, which creates both human friction and attacker leverage. Prompt bombing works because users can be overwhelmed into approving requests, while password resets remain one of the most common service desk workloads. Passwordless removes both the shared secret and the approval prompt in the strongest implementations, which reduces attack opportunities and shifts support effort toward recovery and re-enrollment instead of routine lockouts.

Practical implication: model the reduction in reset tickets and prompt-based abuse before rollout, then design recovery flows as a first-class operating process.

How passwordless extends to machine identity and AI agent access

The same no-shared-secret principle applies to machine-to-machine authentication and AI agent access, but the implementation changes from user gestures to token and certificate-based trust. That matters because machine identities do not type passwords, yet they still need revocation, scope control, and assurance that a credential is not broadly reusable. In identity terms, passwordless for machines is really about replacing static secrets with cryptographically verifiable workload identity and constrained token exchange.

Practical implication: separate human passwordless design from workload identity design, then govern each with the right assurance and lifecycle controls.

Threat narrative

Attacker objective: The attacker wants durable account access that can be replayed across services, impersonated through phishing, or used as a starting point for broader compromise.

1. Entry begins with phishing, credential stuffing, or reuse across breached services, which works because passwords are shared secrets that can be guessed or harvested.
2. Escalation follows when the attacker reuses stolen credentials, exploits MFA fatigue, or bypasses weak recovery flows to reach accounts with broader access.
3. Impact occurs through account takeover, support overhead, and repeated compromise across services because the same secret pattern keeps reappearing.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Passwordless is best understood as a shared-secret removal programme, not a login makeover. The security gain comes from eliminating the reusable credential class that attackers phish, stuff, and reuse across services. That changes the control objective from password protection to cryptographic assurance, which is a fundamentally different IAM problem. Practitioners should treat the move as an authentication architecture decision, not a user-interface preference.

Recovery becomes the new governance boundary once passwords disappear. When the password is gone, the account recovery path becomes the highest-risk entry point because it substitutes for the missing secret. That means identity proofing, device loss handling, and re-enrollment matter more than complexity rules ever did. Teams should judge passwordless programmes by how well they manage recovery without reintroducing the same weak patterns they are trying to remove.

Machine identity and human passwordless design share the same principle but not the same execution. Human users authenticate through biometrics, taps, or passkeys, while workloads and AI agents rely on certificates and tokens that must still be scoped and revoked. The common error is to assume one authentication model can be stretched across all actor types without separate lifecycle controls. Practitioners should align the method to the identity type instead of assuming passwordless means the same thing everywhere.

Passkeys create a phishing-resistant baseline, but assurance still depends on method selection. Synced passkeys, device-bound passkeys, hardware keys, magic links, and SMS codes are not equivalent. The stronger methods bind authentication to device-held keys that never leave the endpoint, while weaker methods still depend on channels attackers can intercept. Teams should classify passwordless methods by assurance level before they standardise on rollout policy.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• 59.8% of organisations see value in a solution that simplifies non-human access management and introduces dynamic ephemeral credentials.
• Guide to the Secret Sprawl Challenge shows why static secret sprawl keeps creating governance debt across pipelines and runtime access.

What this signals

Passwordless is pushing IAM teams to re-evaluate where trust actually lives. Once the password disappears, the control plane shifts toward device trust, recovery governance, and assurance-level selection. That makes passkeys useful only when they are paired with lifecycle controls that keep fallback methods from becoming the weak link in the programme.

Secret reduction in human authentication points in the same direction as NHI governance. If teams already struggle to govern non-human access with static credentials, the move to passwordless should sharpen the case for reducing shared secrets across every identity type. The design lesson is simple: the fewer reusable secrets in circulation, the smaller the attack surface and the lower the recovery burden.

Passwordless also exposes a widening policy gap between convenience and assurance. Many organisations will adopt the easiest login path first, then discover that not all passwordless methods deliver the same security outcome. Teams should standardise on assurance tiers now, because later migration from SMS or email-based flows to passkeys is harder than choosing the stronger path up front.

For practitioners

• Inventory every password dependency before rollout Map customer, workforce, partner, and machine login paths, then identify where shared secrets, reset flows, and fallback authenticator methods still control access. Use the inventory to decide which journeys can move first to passkeys or hardware keys.
• Design recovery as the highest-risk control path Build account recovery with identity proofing, device replacement, and re-enrollment steps that do not quietly recreate a password equivalent. Test what happens when a user loses the enrolled device, changes phones, or cannot use the primary authenticator.
• Separate assurance levels by use case Use synced passkeys where adoption is the priority, device-bound passkeys or hardware keys for privileged access, and token or certificate-based methods for workload identity. Document which methods are acceptable for each risk tier so teams do not mix convenience and high assurance by accident.
• Track adoption with operational metrics Measure login success rates, password-reset tickets, fallback usage, and re-enrollment volume after each phase of the rollout. Those indicators show whether passwordless is reducing friction or simply shifting it to another part of the journey.

Key takeaways

• Passwordless authentication removes the shared-secret weakness that attackers most often exploit.
• The biggest design risk shifts from password cracking to recovery, device loss, and method selection.
• IAM teams should govern passwordless as an architecture change across human, workload, and agent identities.

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.
• 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.
• Phishing-resistant Authenticator: An authentication factor that cannot be easily replayed, proxied, or tricked into disclosure by phishing. In practice, it uses public key cryptography and binds the authentication response to the legitimate origin and transaction context, reducing the value of stolen passwords or repeated prompts.
• Account recovery flow: The recovery path used to regain access after a password loss, device change, or session lockout. It is part of authentication governance, not just support, because a weak recovery branch can bypass stronger controls and convert a temporary issue into durable account takeover.

What's in the full article

Ory's full guide covers the operational detail this post intentionally leaves for the source:

• Side-by-side explanation of passkeys, biometrics, hardware keys, magic links, and one-time codes for different user populations.
• Implementation trade-offs for customer identity, workforce access, and machine-to-machine authentication.
• Rollout sequencing guidance for teams that need to migrate without breaking recovery or accessibility requirements.
• Ory Kratos implementation context for organisations evaluating API-first passwordless flows.

👉 The full Ory guide covers passkey mechanics, rollout choices, and the cost and UX trade-offs teams need to weigh.

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 building or maturing an IAM programme, it is worth exploring.