Notifications
Clear all
Topic starter
11/08/2026 3:12 pm
TL;DR: Unit 42's Pass-ta-key research shows malware on a Windows device can extract synced passkeys from Google Password Manager, re-register a fraudulent key, or in the worst case decrypt every passkey tied to one account, according to RSA Security. Device-bound passkeys and stronger endpoint controls matter because synced credential stores create a shared trust anchor that enterprises cannot treat like consumer convenience.
NHIMG editorial — based on content published by RSA Security: Pass-ta-key, passkeys, and enterprise use cases
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.
Questions worth separating out
Q: How should security teams decide where to use syncable passkeys versus device-bound keys?
A: Use syncable passkeys where usability and scale matter most, but keep device-bound keys for privileged access, regulated workflows, and any application where the organisation must preserve a stronger device-to-credential binding.
Q: Why do synced passkeys create more risk than many teams expect?
A: Synced passkeys shift trust to the cloud account, recovery process, and browser environment that protect them.
Q: What should teams get wrong less often about phishing-resistant authentication?
A: They should stop assuming that passkeys or enforced MFA close every door.
Practitioner guidance
- Classify workforce passkeys by actor and use case Separate consumer-style synced passkeys from workforce and privileged accounts.
- Review device registration and re-registration flows Inspect how new verification keys are accepted, what hardware proof is required, and whether a compromised endpoint can replace an existing key without strong trust checks.
- Treat browser memory as a credential exposure zone Assume a malicious process can inspect credential material in memory during registration or recovery.
What's in the full article
RSA Security's full blog post covers the operational detail this post intentionally leaves for the source:
- The three Pass-ta-key attack variants and the conditions that make each one possible
- The practical difference between synced passkeys, device-bound passkeys, and hardware-rooted authenticators
- RSA's product-specific deployment examples for passwordless across cloud, hybrid, and on-premises environments
- The article's implementation guidance on secure enrollment, malware detection, and workforce passwordless design
👉 Read RSA Security's analysis of Pass-ta-key and synced passkey risk →
Synced passkeys: are your enterprise controls keeping up?
Explore further
11/08/2026 3:26 pm
Synced passkey trust debt is the real enterprise problem. The cryptographic primitive is not the issue. The issue is that syncing introduces a recoverable trust layer that assumes the endpoint, recovery flow, and cloud authenticator all remain trustworthy over time. For enterprise IAM, that is a weaker assumption than most workforce and privileged use cases can tolerate.
A few things that frame the scale:
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, showing how identity exposure compounds once governance fails.
A question worth separating out:
Q: Who should approve synced passkeys for workforce use?
A: Identity, security, and risk owners should approve them only after reviewing the recovery model, endpoint controls, and audit requirements. If a regulated role can access sensitive data, shared secrets and cross-device portability usually justify a more restrictive authentication design.
👉 Read our full editorial: Synced passkeys expose a device trust gap in enterprise IAM
