Passkeys in enterprise IAM: where phishing resistance still falls short

At a glance

What this is: This is an RSA Security analysis of whether passkeys are ready for enterprise use, with the key finding that stronger authentication does not remove enterprise governance, recovery, and platform-dependency risks.

Why it matters: It matters because IAM teams cannot treat passkeys as a drop-in password replacement; they must rework registration, recovery, help desk, and device-policy controls across human and machine-facing identity programmes.

👉 Read RSA Security's analysis of passkeys for enterprise authentication

Context

Passkeys are a passwordless authentication method built on asymmetric cryptography, but enterprise readiness depends on more than resisting phishing. The real issue is whether identity governance can control registration, recovery, device binding, and support processes without creating new trust assumptions.

RSA Security's central point is that consumer adoption does not automatically translate to enterprise fit. For IAM teams, the question is not whether passkeys are stronger than passwords, but which passkey model, recovery path, and platform dependency matches the organisation's risk posture.

The strongest enterprise concern is synced passkeys, because they shift part of the authentication trust model to external sync and account-recovery ecosystems. That makes authentication design a governance problem, not just a user-experience decision.

Key questions

Q: How should security teams implement passkeys without weakening enterprise control?

A: Treat passkeys as one authentication method inside a broader IAM policy, not as a universal replacement for every login flow. Define which users, apps, and devices may use them, require strong enrolment and recovery checks, and keep a fallback path only where business risk justifies it.

Q: When do synced passkeys create more risk than they reduce?

A: Synced passkeys create more risk when the organisation cannot control the external recovery ecosystem, cannot verify device ownership consistently, or cannot tolerate credential reappearance on unmanaged devices. In those cases, the convenience benefit can outweigh the assurance benefit.

Q: What do teams get wrong about passkey phishing resistance?

A: Teams often assume phishing resistance means the entire identity flow is hardened. In practice, the credential may be strong while recovery, help desk support, and enrolment remain vulnerable to social engineering and account takeover.

Q: What is the difference between device-bound and synced passkeys for enterprise use?

A: Device-bound passkeys keep key material on one authenticator and are easier to constrain inside enterprise policy. Synced passkeys can reappear on multiple devices through a vendor ecosystem, which improves convenience but adds recovery and trust dependencies that organisations must explicitly manage.

Technical breakdown

Device-bound passkeys vs synced passkeys in enterprise IAM

Passkeys are FIDO credentials that use a public-private key pair. Device-bound passkeys keep the private key on a single authenticator, which limits extraction and makes the key harder to move, while synced passkeys replicate key material through a vendor sync fabric so the same credential can appear on multiple devices. In enterprise use, that distinction matters because the latter adds recovery, cloud sync, and account-takeover dependency to the authentication chain. The authentication method may still be phishing-resistant, but the trust boundary shifts outward to the ecosystem that stores and restores the credential.

Practical implication: classify passkeys by storage model before rollout, and treat synced passkeys as a separate risk tier from device-bound authenticators.

Why passkeys reduce phishing but not all MFA bypass paths

Passkeys stop the classic credential-reuse and fake-login-page problem because the key pair is bound to the real domain and no shared secret is entered. But that only addresses one class of attack. Social engineering against help desks, compromised recovery flows, or device enrollment abuse can still bypass an otherwise strong authentication method. In other words, passkeys remove password theft as the weak link, but they do not eliminate identity proofing failure, recovery abuse, or operator error. Enterprise IAM still has to govern the surrounding processes, not just the login ceremony.

Practical implication: harden recovery and support workflows at the same time as passkey rollout, or the attack path simply moves from login to enrollment.

Cross-platform passkey adoption depends on identity platform readiness

Enterprise passkey adoption is limited by operating system, browser, remote-access, and legacy application support. Where an organisation still depends on on-premises or web-incompatible systems, passkeys may not be universally usable without additional authentication layering. That creates a common transition pattern: passwordless works in some flows, while exceptions pile up in older applications and remote desktop scenarios. The technical challenge is not the cryptography itself, but the mismatch between modern authenticators and older access architectures that were not built for them.

Practical implication: inventory application and access-path compatibility first, then decide where passkeys can be primary authentication versus a constrained option.

Threat narrative

Attacker objective: The attacker wants legitimate access through a trusted authentication or recovery path, not the passkey secret itself.

1. Entry occurs when attackers exploit non-phishing paths such as help desk social engineering or compromised recovery processes rather than trying to steal the passkey itself.
2. Escalation follows when the attacker registers or restores a legitimate authenticator through a trusted support or sync workflow.
3. Impact occurs when the attacker uses that legitimate authentication path to access enterprise applications and move past the intended MFA boundary.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

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 an authentication upgrade, not an identity governance finish line. The article makes the right distinction between stronger login technology and enterprise control readiness. Passwordless authentication reduces phishing and credential theft, but it does not by itself solve recovery, device governance, or application compatibility. IAM teams should treat passkeys as one control in a broader authentication architecture, not as a programme endpoint.

Synced passkeys create a distinct enterprise trust problem that most programmes will underestimate. Device-bound credentials keep key material on a single authenticator, but synced credentials extend reliance to consumer sync and recovery ecosystems. That shifts accountability outside the enterprise boundary and complicates control ownership across identity, endpoint, and support operations. Practitioners should recognise that the security model changes when the authenticator can reappear on another device without local enterprise control.

Help desk and recovery workflows are now part of the authentication attack surface. The article correctly points to social engineering attacks that bypass the factor itself and target support or enrolment processes. That means passkey governance must include identity proofing, recovery verification, and enrolment exception handling, not just cryptographic assurance. Organisations that ignore the operational edge of passwordless rollout will preserve the weakest link in a new form.

Passkey terminology confusion is already a governance issue, not just a usability issue. The article notes that passkeys, security keys, and FIDO credentials are often used loosely, which creates ambiguity in policy, user guidance, and assurance expectations. That ambiguity matters because the control obligations differ materially between device-bound and synced implementations. Practitioners should define the approved credential classes clearly before scaling adoption.

Passkey readiness should be judged by process maturity, not by consumer adoption rates. Enterprise programmes fail when they assume consumer-grade success automatically maps to workforce or privileged access use cases. The right test is whether the organisation can classify users, protect recovery paths, and support legacy access without weakening assurance. In practice, passkeys are ready only where the surrounding IAM operating model is ready.

From our research:

• Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, according to The State of Secrets in AppSec.
• For a wider view of how credential sprawl affects identity programmes, see Ultimate Guide to NHIs , Why NHI Security Matters Now.

What this signals

Passkey programmes will fail if the organisation only modernises login and leaves recovery untouched. The practical signal is whether identity teams can prove that enrolment, reset, and support processes are as strong as the authenticator itself. In many environments, the real risk sits in those adjacent workflows, not in the cryptographic factor. For governance teams, this is a policy and operating-model change, not a cosmetic MFA upgrade.

Synced passkeys introduce a named concept we should track: authentication recovery dependency. That is the point at which the enterprise relies on consumer recovery ecosystems to restore access, which can be convenient and operationally fragile at the same time. If your policy cannot explain who controls that dependency and how exceptions are handled, your passwordless rollout is incomplete.

The broader signal is that passwordless adoption is moving identity teams toward stronger assurance, but only if they align it with endpoint policy, application compatibility, and support process redesign. That is where the architecture meets reality, and where programme maturity becomes visible.

For practitioners

• Define passkey classes in policy Separate device-bound and synced passkeys in written policy, with different approval, assurance, and recovery rules for each class.
• Harden enrolment and recovery workflows Require strong identity proofing, verified recovery steps, and help desk controls before allowing passkey reset or re-registration.
• Map application compatibility before rollout Inventory which applications, remote access flows, and legacy systems can support passkeys, then assign fallback methods only where needed.
• Review third-party sync dependencies Document whether corporate authentication depends on consumer sync fabrics or cloud recovery services, and decide where that dependency is acceptable.

Key takeaways

• Passkeys improve phishing resistance, but they do not remove governance risk from enrolment, recovery, or support channels.
• The biggest enterprise distinction is between device-bound and synced passkeys, because the trust boundary changes materially.
• Teams that want passwordless success must redesign identity operations, not just swap one authenticator for another.

Key terms

• Passkey: A passkey is a passwordless credential built on public-private key cryptography. The private key stays with the user authenticator, while the service stores the public key and verifies a signed challenge at login. In enterprise use, the key question is not only strength, but how the credential is enrolled, recovered, and governed.
• Device-bound Passkey: A device-bound passkey keeps its key material on one specific authenticator and does not sync it to other devices. That tighter binding reduces portability and can improve assurance, but it also increases operational friction when devices are lost, replaced, or upgraded. Enterprises often prefer it where control and traceability matter most.
• Synced Passkey: A synced passkey is stored through a vendor-controlled sync fabric so the same credential can be restored on multiple devices tied to the same user account. It improves convenience, but it also extends trust into external recovery and synchronisation processes that the enterprise may not fully control.
• Identity Recovery Workflow: Identity recovery workflow is the process used to restore access when a user loses an authenticator or cannot complete login. For passwordless programmes, this workflow becomes part of the authentication control surface because weak recovery can undermine a strong primary factor. It must be designed, tested, and governed as carefully as sign-in.

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.

This post draws on content published by RSA Security: Passwordless Passkeys: Are They Ready for Enterprise Use? Read the original.