Passkeys in enterprise IAM: where phishing resistance still falls short

At a glance

What this is: RSA Security says passkeys materially improve phishing resistance, but enterprise adoption still exposes governance gaps around device binding, sync fabrics, recovery, and support processes.

Why it matters: IAM teams need to treat passkeys as a governance shift, not just a better authenticator, because the surrounding recovery and device-assurance model can reintroduce risk.

Context

Passkeys are a phishing-resistant authentication method built on public-private key pairs rather than shared secrets. In consumer environments they reduce password theft, but enterprise rollout changes the question from whether authentication is stronger to whether identity controls can manage recovery, device state, and support paths.

RSA Security's position is that passkeys are usable in enterprise IAM only when organisations confront the trust they shift onto device platforms, sync fabrics, and help desk processes. That makes this an identity governance issue, not just an authentication upgrade.

The article's core tension is familiar to IAM teams: a stronger login method can still create weaker operational assumptions if it is adopted without policy, platform, and lifecycle alignment.

Key questions

Q: What breaks when passkeys are rolled out without strong fallback controls?

A: The recovery path becomes the easiest route into the account. If password resets, device re-binding, or support exceptions are weakly controlled, attackers will bypass the passkey itself and compromise the identity through the exception process instead of the primary login.

Q: Why do syncable passkeys create more enterprise risk than device-bound passkeys?

A: Syncable passkeys increase risk because the private key can be backed up and used across devices through personal cloud accounts. That makes it harder for IT teams to control where credentials live and whether they are duplicated onto unmanaged devices. If a cloud account is compromised, an attacker may sync the passkey to their own device and bypass normal enterprise controls.

Q: What should security teams evaluate before adopting passkeys across their applications?

A: They should evaluate backend fit, application compatibility, compliance needs, and the ownership model for ongoing maintenance. If those factors are unclear, the organisation may deliver a working login flow but still fail to operate it reliably over time.

Q: How do help desk processes affect the security of passwordless authentication?

A: Help desk workflows can either preserve or undo the value of passwordless authentication. If support staff can rebind credentials too easily, attackers can social-engineer a new authenticator onto the account, so recovery scripts, verification steps, and exception handling need the same scrutiny as the authenticator itself.

Technical breakdown

How passkeys replace shared secrets with domain-bound keys

Passkeys use asymmetric cryptography, where the private key stays on the user's authenticator and the public key is registered with the service. At login, the authenticator signs a challenge, and the service verifies the signature against the stored public key. Because the credential is bound to the exact service domain, a fake phishing site cannot reuse the same passkey the way it might capture a password. This removes password reuse, replay, and many credential theft paths, but it also means the login experience is only as strong as the domain binding and the surrounding registration and recovery controls.

Practical implication: treat passkey rollout as an authentication change plus a governance change over registration, domain trust, and recovery paths.

Device-bound passkeys versus synced passkeys

Device-bound passkeys keep key material on a single device or hardware authenticator, which preserves a tighter trust boundary and reduces extraction risk. Synced passkeys move that trust boundary into a remote sync fabric owned by a platform provider, so the credential can appear on multiple user devices. That improves usability, but it also broadens the control surface to include account recovery on the sync account, device ecosystem policy, and consumer-style sharing features that may not fit enterprise risk. In practice, synced passkeys shift the enterprise from controlling one authenticator to depending on a platform account and its recovery chain.

Practical implication: classify which applications can tolerate synced credentials and which must remain device-bound or hardware-backed.

Why help desk and account recovery become the weak link

Passkeys do not remove identity recovery. They move the attack path from password reset to authenticator recovery, lost-device handling, and support-assisted re-enrolment. If an attacker can socially engineer the help desk or exploit weak recovery checks, the organisation can still be tricked into registering a new authenticator or restoring access to the wrong person. That is why passkeys do not eliminate MFA bypass risk. They change the abuse pattern. The enterprise control problem becomes whether recovery, exception handling, and support scripts are strong enough to resist impersonation and device-loss scenarios.

Practical implication: harden recovery and help desk workflows before broadening passkey use.

Threat narrative

Attacker objective: The attacker wants to gain authenticated access by subverting recovery and enrollment controls rather than defeating the passkey cryptography itself.

1. Entry occurs through a help desk or recovery pathway rather than password theft, because the attacker targets identity support processes around passkey enrollment.
2. Credential abuse follows when the attacker convinces the organisation to register or restore an authenticator under malicious control, or leverages a compromised sync account.
3. Impact is account takeover through a trusted authentication path, even though the original phishing-resistance property of the passkey itself was intact.

NHI Mgmt Group analysis

Passkeys improve authentication, but they do not remove identity governance debt. The stronger cryptography solves phishing against the login ceremony, not the broader question of who can recover, rebind, or sync the credential. Enterprise IAM still has to govern the lifecycle around the authenticator, not just the login event. The practical conclusion is that passkeys should be evaluated as an operating model change, not a simple password replacement.

Sync fabrics create an expanded trust boundary that many enterprise programmes do not model explicitly. When key material can reappear across multiple user devices through Apple, Google, or Microsoft ecosystems, the organisation is depending on external account recovery logic as part of its access model. That means access governance now spans device policy, platform account assurance, and cross-device trust. Practitioners should treat the sync layer as an identity dependency, not a convenience feature.

Passkey readiness is really recovery readiness. The enterprise question is whether the organisation can safely handle lost-authenticator events, device replacement, and support-assisted re-enrolment without opening an impersonation path. If the answer is unclear, the authentication programme is not ready for broad passkey use. IAM leaders should read passkeys as a test of governance maturity, because the weakest control now sits outside the credential itself.

Device-bound credentials define the high-assurance baseline; synced credentials define the convenience baseline. Those are not equivalent choices, and organisations should stop treating them as interchangeable implementations of the same control. The distinction matters most in regulated, high-assurance, or privileged access paths where the enterprise needs a narrower trust boundary. Practitioners should align passkey type to risk tier, not user preference alone.

From our research library:

• eBay's passkey data shows 55-60% of passkey adoption happens on mobile, against around 20% on desktop.

What this signals

Passkey adoption should be evaluated as a governance programme, not a feature rollout. The control question is whether an organisation can distinguish strong phishing resistance from weak recovery handling, because the latter often determines the real attack surface. IAM teams should expect passkeys to expose gaps in device policy, help desk verification, and exception management that password-centric processes never had to confront.

Device-bound versus synced is the key enterprise design choice. The right decision is rarely universal across the estate. High-risk access paths need a narrower trust boundary, while low-risk journeys may accept more convenience if recovery and support are tightly governed.

Authentication modernisation will fail if lifecycle governance stays old-fashioned. If passkeys are added without updating recovery, enrolment, and support workflows, organisations simply move abuse from password reset to authenticator reset. The programme implication is to align authentication standards with account recovery, not treat them as separate workstreams.

For practitioners

• Define where passkeys are allowed by risk tier Classify applications, user groups, and data sensitivity before selecting passkey type, then reserve device-bound credentials for higher-assurance access paths.
• Harden authenticator recovery workflows Review lost-device, reset, and re-enrollment processes so that recovery cannot become a stealth enrollment path for an attacker.
• Limit sync fabrics for enterprise authentication Decide which business systems may rely on synced passkeys and which must remain isolated from consumer-style account recovery and cross-device sharing.
• Test help desk resistance to social engineering Use realistic impersonation scenarios to verify that support teams can distinguish authenticator recovery from account compromise and do not bypass policy under pressure.
• Modernise MFA policy across legacy and remote access Map where passkeys work, where they do not, and where alternate methods such as OTP, biometrics, or push remain necessary for business continuity.

Key takeaways

• Passkeys reduce phishing exposure by removing shared secrets, but they do not remove the need to govern enrollment, recovery, and support channels.
• The article's practical warning is that synced passkeys shift trust into external platform recovery and device ecosystems, which many enterprise policies do not yet model clearly.
• Enterprises should decide passkey type by assurance level and recovery risk, not by convenience alone.

Key terms

• 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.
• Device-Bound Passkey: A device-bound passkey is a FIDO credential tied to one physical device and generally stored in hardware-backed secure components. The value for enterprise security is lifecycle control, because the credential is easier to inventory, constrain, and revoke without relying on cloud sync paths.
• Synced Passkey: A synced passkey is a FIDO credential that can be replicated across multiple devices through a cloud account and recovery system. It can improve usability, but it also shifts trust from a single device to the sync provider, recovery workflow, and account protections surrounding the credential.
• Authenticator recovery: Authenticator recovery is the process used to restore access when a primary login method is lost or unavailable. It is often the weakest part of a modern identity stack because attackers target support workflows, reset paths, and backup channels that have lower assurance than primary authentication.

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