Passkeys strengthen authentication, but edge cases still matter

At a glance

What this is: This is an analysis of why passkeys improve authentication security and where their edge cases still matter for regulated sign-in environments.

Why it matters: It matters because IAM teams must decide where passwordless authentication can replace passwords, where MFA and device binding still apply, and how human identity controls adapt without weakening assurance.

👉 Read OneSpan's analysis of the pros and cons of passkeys

Context

Passkeys are a passwordless authentication method that uses public and private keys instead of shared secrets. The core IAM question is not whether they work in theory, but where they change the assurance model enough to replace passwords in day-to-day sign-in.

For human identity programmes, passkeys reduce phishing exposure and simplify authentication flows, but they do not erase all risk. Regulated environments still have to account for device trust, account recovery, and the difference between high-volume usability gains and a small number of exceptional failure modes.

Key questions

Q: How should organisations decide where to use passkeys instead of passwords?

A: Start with applications where phishing and password reuse create the greatest exposure, then compare the sign-in journey to the assurance level required. Passkeys are strongest when the application can accept device-bound authentication and when recovery paths are governed tightly. Do not treat them as a universal replacement without mapping business risk and regulatory expectations.

Q: When do passkeys still need compensating controls?

A: They still need compensating controls when the environment depends on strict device trust, regulated assurance levels, or tightly controlled account recovery. Synced passkeys reduce risk, but they shift trust into the platform and recovery chain. If those paths are weak, the authentication control is weaker than the cryptography suggests.

Q: What do teams get wrong about passkey security?

A: Teams often assume passkeys are either perfect or too risky to adopt. The better view is that they remove the reusable secret that makes phishing and replay so effective, while leaving a smaller set of governance questions around recovery, sharing, and sync protection. The control is stronger, but policy still matters.

Q: Should regulated environments keep OTPs after adopting passkeys?

A: Yes, in some cases. OTPs can still serve high-assurance or transitional workflows where device binding, backup access, or regulatory interpretation require an additional factor. The key is to limit OTPs to defined exceptions rather than keeping them as the default path for all sign-ins.

Technical breakdown

Why passkeys resist phishing

Passkeys work because the private key stays on the user’s device while the relying party stores only the public key. That breaks the classic password attack pattern, where an attacker can trick a user into revealing a reusable secret. A fake site cannot complete the authentication ceremony without the bound key and the user verification step, so adversary-in-the-middle attacks fail by design rather than by detection. The security property is structural, not behavioural, which is why passkeys shift the baseline for human authentication.

Practical implication: replace password flows first where phishing risk is highest and identity verification can tolerate device-bound sign-in.

Synced passkeys and trust boundaries

Synced passkeys introduce a different trust boundary because key material may move through a platform ecosystem or password manager. That does not make them equivalent to passwords, but it does mean the security model depends on provider account protection, device trust, and recovery processes. The important distinction is that the relying party does not directly see how the key is protected in transit or at rest. For IAM architects, the question becomes whether the surrounding trust chain is strong enough for the assurance level required.

Practical implication: map synced passkeys to the required assurance level before allowing them into regulated or high-risk authentication paths.

Why edge cases do not erase the control value

The article’s main argument is that rare edge cases should not outweigh the broad reduction in attack surface. A passkey can be shared, restored, or exposed through ecosystem compromise, but those paths are still materially harder than password theft and reuse. In practice, passkeys are a control improvement, not a perfect control. They reduce credential replay risk, limit phishing success, and improve user experience at the same time, which is unusual in identity security and makes them strategically useful for human IAM.

Practical implication: treat passkeys as a default authentication upgrade, then layer compensating controls for recovery, enrolment, and regulated use cases.

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

Passkeys are a human identity control that removes the reusable secret from the attack path. That changes authentication from secret sharing to cryptographic possession plus user verification. The practical consequence is that phishing, credential stuffing, and password reuse lose their primary lever, so identity programmes can reduce dependence on brittle user behaviour.

Synced passkeys create a governance question about assurance, not just convenience. The article is right that synced credentials are still stronger than passwords, but the relying party must trust the surrounding platform recovery and transport model. That means the control decision is no longer binary. Practitioners have to decide which sign-in journeys can accept ecosystem-mediated trust and which ones need stronger device binding.

Passkey edge cases do not negate the control, they define where policy has to stay stricter. Shared keys, restoration abuse, and provider compromise are real scenarios, but they are not equivalent to the everyday exposure of passwords. The named concept here is passwordless assurance boundary: the point at which an authentication method is no longer just about user experience, but about how much trust the organisation is willing to place in the surrounding device and recovery chain. IAM teams should use that boundary to set policy.

Regulated authentication programmes should treat passkeys as a control tier, not a universal replacement. The article correctly notes that OTPs still have a role in some high-assurance settings. That means the best operating model is selective adoption with explicit assurance mapping, not blanket replacement by default. Practitioners should align passkey type, recovery design, and policy exception handling to the business risk of each application.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• From our research: 80% of organisations report their AI agents have already performed actions beyond their intended scope, including access to unauthorised systems, according to AI Agents: The New Attack Surface report.
• From our research: Use the Ultimate Guide to NHIs , Why NHI Security Matters Now to frame passwordless sign-in as part of a broader identity risk reduction programme, not a standalone authentication change.

What this signals

Passwordless assurance boundary: passkeys make authentication more resilient, but they also force IAM teams to define where device trust, sync, and recovery are acceptable parts of the identity chain. That boundary should sit inside the application risk model, not inside user preference alone. Teams that align passkey type to assurance level will avoid turning a stronger control into a weaker policy exception.

With the Ultimate Guide to NHIs , Key Challenges and Risks as the baseline for identity sprawl, the broader lesson is that authentication improvements only work when lifecycle and recovery are equally governed. Human IAM, NHI governance, and emerging agentic controls increasingly share the same pattern: remove reusable secrets, then close the recovery gap.

Organisations that adopt passkeys without updating recovery governance will still carry the same operational blind spots they had with passwords. The difference is that the failure mode moves from secret theft to trust-chain abuse, which is a better problem, but still a real one for compliance, audit, and incident response.

For practitioners

• Prioritise password replacement in phishing-heavy journeys Move customer and workforce sign-in flows that are most exposed to credential theft onto passkeys first, especially where the business impact of phishing is high and the application can tolerate device-bound authentication.
• Separate synced and device-bound assurance decisions Document which applications may accept synced passkeys and which require stronger device binding, then align that split to regulatory and internal assurance requirements.
• Review recovery and enrolment paths as part of authentication design Treat account recovery, key restoration, and device replacement as part of the control, because those are the routes that can weaken passkey assurance if they are left unmanaged.
• Keep OTPs only where assurance requirements justify them Retain one-time passwords for narrowly defined high-assurance or transition scenarios, but do not let legacy fallback paths become the default for everyday access.

Key takeaways

• Passkeys materially reduce phishing and replay risk because they remove the reusable secret from the authentication flow.
• Synced passkeys improve usability, but they shift the governance question toward platform trust, recovery, and assurance mapping.
• IAM teams should adopt passkeys selectively, with explicit policy for regulated workflows, fallback methods, and enrolment controls.

Key terms

• Passkey: A passkey is a passwordless credential that uses public key cryptography to authenticate a user without exposing a shared secret. In practice, it binds sign-in to a device or synced ecosystem account and is designed to resist phishing and replay attacks much better than passwords.
• Device-bound passkey: A device-bound passkey is stored on a specific device and used from that device during authentication. It strengthens assurance because the private key is not intended to roam freely, which makes account takeover harder, but it also makes device trust and recovery design more important.
• Synced passkey: A synced passkey is a credential that can be restored across devices through a provider or password manager ecosystem. It improves usability and adoption, but the organisation must understand the trust chain behind sync, restoration, and account recovery before relying on it for higher-assurance access.
• Passwordless assurance boundary: The passwordless assurance boundary is the point at which an organisation decides whether a passkey flow is strong enough for a given application, user group, or regulatory context. It is defined by device trust, recovery controls, and risk tolerance, not by the label 'passwordless' alone.

Deepen your knowledge

Passkeys, phishing resistance, and assurance mapping are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are redesigning authentication for regulated or high-risk applications, it is worth exploring.

This post draws on content published by OneSpan: Pros and cons of passkeys: Security benefits outweigh risks. Read the original.