Passkeys strengthen phishing-resistant authentication without passwords

At a glance

What this is: This is a passkey-focused authentication guide showing how phishing-resistant sign-in and step-up flows can be introduced without replacing existing systems all at once.

Why it matters: It matters because IAM teams have to balance phishing resistance, user experience, and deployment complexity across human login journeys, even as authentication assurance becomes more risk-sensitive.

By the numbers:

• Up to 93% login success rates with passkeys vs ~63% for traditional methods.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read OneSpan's guide on strengthening authentication with passkeys

Context

Passkeys are a phishing-resistant authentication method that replaces shared secrets with cryptographic keys tied to a user device or synced credential store. In practice, they address one of the oldest IAM weaknesses: password reuse, phishing, and friction-heavy login journeys that push users toward weaker workarounds.

The operational challenge is not the cryptography itself but the transition model. Most enterprises still run mixed authentication estates, so the real question is how to introduce passkeys alongside existing methods while keeping step-up decisions, user enrolment, and assurance levels consistent across cloud, on-prem, and hybrid environments.

Key questions

Q: How should security teams roll out passkeys without disrupting existing authentication flows?

A: Start with applications where phishing risk and user friction are both high, then introduce passkeys alongside current methods while you preserve enrolment, recovery, and audit continuity. The goal is not a big-bang replacement. It is to reduce shared-secret exposure while keeping access stable for the users and systems that are not ready to move yet.

Q: When do passkeys improve security but still leave governance gaps?

A: Passkeys improve security when they replace reusable secrets, but governance gaps remain if fallback authentication, recovery, or exception handling still relies on passwords or OTPs. If those paths remain open, the organisation may have improved the primary login but left the real control boundary unchanged.

Q: What do IAM teams get wrong about passkey adoption?

A: They often treat passkeys as a user-enrolment project instead of an authentication governance change. The hard part is defining which users, apps, and transaction types can accept each authenticator, then enforcing that policy consistently across mixed environments.

Q: How do passkeys fit into step-up authentication and zero trust?

A: Passkeys fit best when step-up is driven by transaction risk, not by a one-size-fits-all login rule. In a zero-trust model, the authenticator should be selected and challenged according to context, so stronger proof is used where the access decision warrants it.

How it works in practice

Passkeys vs shared-secret authentication

Passkeys use public-key cryptography rather than shared secrets such as passwords or OTP codes. The authenticator stores a private key locally or in a synced secure environment, while the service keeps only the public key. That means phishing pages cannot reuse the credential, because there is nothing reusable to steal in the first place. The article also frames passkeys as supporting step-up authentication, which matters because the authentication event is tied to device and risk context rather than a password challenge. This changes how assurance is established, but only if the surrounding IAM flow can recognise and trust the authenticator state.

Practical implication: map which applications still depend on shared-secret fallback and prioritise them for passkey adoption first.

Synced and device-bound passkeys in hybrid IAM

The article distinguishes synced and device-bound passkeys, which is a deployment choice with governance consequences. Synced passkeys improve portability across devices, while device-bound passkeys retain tighter control over where the credential can be used. In hybrid environments, that trade-off matters because different user groups may need different assurance profiles. The important design point is not treating all passkeys as equivalent. Assurance, recovery, and onboarding behavior vary based on how the authenticator is stored and how the organisation defines acceptable risk for each population.

Practical implication: separate passkey policy by user segment and application risk rather than rolling out one uniform registration rule.

Adaptive step-up authentication with authenticators

Passkeys become most useful when they are part of adaptive authentication, not a standalone login replacement. An adaptive system chooses the right authentication method based on risk, transaction sensitivity, and the available authenticator. That is different from a static MFA flow because the system can ask for stronger proof only when the context requires it. The article’s transaction approval example shows passkeys working as part of a broader assurance decision, where the authenticator is one control in a layered access journey rather than the whole control plane.

Practical implication: align step-up policy with transaction risk and application sensitivity so passkeys reduce friction without flattening assurance.

NHI Mgmt Group analysis

Passkeys solve a human authentication problem, but they do not remove the IAM governance problem. The article is about replacing shared secrets with phishing-resistant sign-in, yet enterprises still have to govern enrolment, fallback, recovery, and assurance consistency across systems. That means the control challenge shifts from password hygiene to authentication state management. Practitioners should treat passkeys as an authentication change with lifecycle consequences, not as a drop-in fix.

Mixed authentication estates create assurance drift unless policy is explicit. Introducing passkeys alongside passwords, OTPs, and other existing methods can leave users with very different levels of protection depending on application, device, or channel. That makes authentication policy a governance issue, not just a user-experience decision. The implication is that teams must define which sign-in paths are acceptable for which risk tiers before they scale adoption.

Authentication method choice becomes a transaction-control problem, not a login problem. The article’s step-up framing shows that passkeys are most relevant where authentication strength needs to vary by context. This aligns with Zero Trust thinking because assurance should follow risk, not habit. Practitioners should evaluate whether their current access policies can distinguish routine sign-in from high-risk transaction approval.

Passkey adoption exposes the cost of maintaining legacy shared-secret dependencies. Traditional methods rely on secrets that can be phished, replayed, or socially engineered, while passkeys reduce that exposure. But the broader lesson is that organisations have accumulated authentication debt in older flows, recovery paths, and user exceptions. The practitioner takeaway is to measure where legacy authentication still defines the effective control boundary, then phase it out where risk justifies the change.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• That matters because only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For a broader control view, see the 52 NHI breaches Report for how exposed credentials translate into breach paths.

What this signals

Passkey rollouts should be measured as policy migrations, not feature deployments. If users can still fall back to passwords in high-risk paths, the organisation has only shifted the problem, not reduced it. The practical signal to watch is whether step-up policy, recovery design, and application coverage are converging around the same assurance standard.

With 79% of organisations having experienced secrets leaks and 77% of those incidents resulting in tangible damage, authentication changes cannot be separated from broader credential governance. Even though passkeys are a human IAM control, the same control discipline matters for service accounts and autonomous systems where shared secrets still dominate.

Authentication assurance is becoming a lifecycle issue across identity types. Human login modernisation, NHI secret hygiene, and future agentic access policy are converging on the same question: who can assert identity, through which proof, and for how long. Teams that build one consistent governance model will reduce exceptions faster than teams that treat each identity type separately.

For practitioners

• Inventory legacy authentication dependencies Map which applications, user groups, and step-up flows still depend on passwords or OTPs, then identify where those methods remain the effective fallback for critical access paths.
• Segment passkey policy by assurance tier Set different registration and recovery rules for routine users, privileged users, and high-risk transactions so synced and device-bound passkeys are not treated as interchangeable.
• Redesign step-up decisions around risk Tie passkey prompts to transaction sensitivity, device posture, and sign-in context so authentication strength changes only when the access request warrants it.
• Reduce fallback paths that reintroduce shared secrets Review recovery, enrolment, and exception handling to remove password or OTP shortcuts that undermine phishing resistance in the main authentication journey.

Key takeaways

• Passkeys reduce phishing exposure by removing shared secrets, but they do not eliminate the need for authentication governance.
• The strongest operational value comes from pairing passkeys with explicit step-up policy, segmented assurance tiers, and controlled fallback paths.
• IAM teams should treat passkey adoption as a mixed-estate migration that must be governed across enrolment, recovery, and transaction risk.

Key terms

• Passkey: A passkey is a phishing-resistant credential that uses public-key cryptography instead of a shared secret. The private key stays with the authenticator or synced secure store, while the service verifies the public key. That design reduces replay, phishing, and password reuse risk in human authentication flows.
• Step-up Authentication: Step-up authentication is the practice of requiring stronger proof only when risk or transaction sensitivity increases. In modern IAM, it is used to avoid making every login equally burdensome while still demanding higher assurance for sensitive actions or unusual context.
• Shared Secret: A shared secret is any credential both sides must know, such as a password, OTP seed, API key, or token. Shared secrets are vulnerable because they can be phished, copied, replayed, or leaked, which is why they remain a weak foundation for high-assurance identity control.
• Adaptive Authentication: Adaptive authentication changes the authentication challenge based on context such as device, location, behavior, or transaction risk. It is stronger than static rules because it lets the control respond to real conditions instead of treating every sign-in the same way.

Deepen your knowledge

Passkeys, step-up authentication, and phishing-resistant login journeys are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are modernising authentication across mixed estates, it is worth exploring.

This post draws on content published by OneSpan: Strengthen authentication with passkeys. Read the original.