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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on RSA Security's blog post: Pass-ta-key is a three-part attack pattern showing how synced passkeys can be abused through device compromise, re-registration, and master-key exposure.
Why it matters: It matters because enterprise IAM cannot assume a synced passkey remains bound to the original device trust boundary, especially for regulated or privileged workforce use cases.
Context
Synced passkeys are designed to make the same credential work across multiple devices through a cloud-backed trust model. That convenience changes the security boundary: the protection no longer depends only on the credential holder, but also on the integrity of the device, the browser, and the cloud authenticator that manages re-registration and recovery.
RSA Security uses Unit 42’s Pass-ta-key research to show why that model is risky for enterprise IAM. If malware can reach the credential store or the registration flow, the control problem is no longer phishing resistance alone. It becomes a device trust and credential lifecycle problem, which is materially different from a hardware-bound passkey model.
For workforce and privileged access, the article argues that synced consumer-style passkeys are often the wrong fit. The issue is not that passkeys fail as a concept, but that copying private key material across devices under one shared secret creates a broader compromise surface than many identity programmes are built to govern.
Key questions
Q: What breaks when synced passkeys are used as a workforce default?
A: The trust boundary breaks. Synced passkeys rely on cloud-backed recovery and shared trust across devices, so endpoint compromise can turn into credential abuse even when phishing is not involved. For workforce access, that means assurance depends on the device, browser, and recovery path behaving correctly, which is a much harder condition to govern than a single hardware-bound token.
Q: Why do synced passkeys increase account takeover risk after device compromise?
A: Because the attacker no longer needs to steal a reusable password. If malware can abuse the trusted device context, force re-registration, or reach the master secret used for sync, it can create or decrypt authentication material that survives beyond the original endpoint. The risk rises when recovery flows are treated as convenience features instead of privileged identity events.
Q: What do security teams get wrong about passwordless authentication in regulated environments?
A: They often treat passwordless as a convenience layer instead of a governance control. If identity proofing, recovery, logging, and policy enforcement are weak, the organisation has only moved the risk elsewhere. In regulated settings, passwordless must support accountability and evidence, not simply remove a password prompt.
Q: Should organisations use synced or device-bound passkeys for privileged access?
A: For privileged access, device-bound passkeys are the better default because they keep the private key on a single device and narrow the portability of the credential. Synced passkeys are more convenient, but that convenience comes with different recovery and propagation assumptions. Privileged roles need the tighter assurance boundary.
Technical breakdown
How malware abuses synced passkey trust on a Windows device
The base Pass-ta-key technique works because the device is already trusted by the passkey ecosystem. Malware on the endpoint can request a signed authentication response without needing the user’s PIN, biometrics, or interaction, if it can impersonate a trusted device context. The cryptography is not broken; the trust boundary is. In practical terms, the attack turns endpoint compromise into credential use by exploiting the fact that synced passkeys inherit device trust from the platform layer rather than from a dedicated hardware token.
Practical implication: treat endpoint integrity as part of passkey assurance, not as a separate control domain.
Why re-registration breaks the assumption behind synced credential recovery
Silver Pass-ta-key shows the second weakness: re-registration is a governance moment, not a convenience feature. Malware can force the device to re-enrol with the cloud authenticator and then register a new verification key in place of the victim’s key. Because the cloud side does not verify that the new key came from trusted hardware, the attacker gains a fresh authentication path from another machine. That is a failure of re-binding trust, not merely a sign-in issue, and it exposes how recovery flows can become privilege transfer events.
Practical implication: harden re-registration so it cannot silently replace a credential without strong trusted-hardware checks.
Why master-key exposure turns one compromise into account-wide decryption
Golden Pass-ta-key is the most severe variant because it targets the security domain secret, the master key used to encrypt every passkey synced to an account. Unit 42 found that key briefly exists in browser process memory during device registration and recovery. Once exposed, the attacker can decrypt present and future synced passkeys for that account, and the article notes there is no rotation path for the key. This is a classic shared-secret problem: one secret becomes the recovery root for an entire credential estate.
Practical implication: do not put a rotating enterprise trust model on top of a non-rotatable shared master secret.
Threat narrative
Attacker objective: The attacker wants durable authentication control over the victim’s synced passkey account and, in the worst case, the ability to decrypt the entire synced credential set.
- Entry occurs when malware already running on a Windows endpoint reaches the synced passkey workflow and abuses the local trusted-device context.
- Credential access follows when the malware requests authentication responses, forces re-registration, or retrieves the security domain secret from browser memory.
- Escalation happens when the attacker replaces the victim’s verification key or decrypts the synced credential set tied to the account.
- Impact is account takeover from another machine, with potential exposure of all passkeys synced to that account, past and future.
Breaches seen in the wild
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
- Google API Keys Exposure — Gemini AI: Google API keys exposed in client-side code via Gemini AI integrations, creating data leak risk.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Synced passkeys create a shared trust anchor that enterprise IAM cannot safely treat as device-bound assurance. The article shows that one cloud secret can govern multiple devices, which means compromise is no longer limited to a single endpoint. That is a structural mismatch for workforce access, where assurance should be tied to a controlled device or token, not a portable recovery model. The practitioner conclusion is straightforward: a synced credential estate behaves like a shared secret problem, not a simple passwordless upgrade.
Device trust has become the real control plane for passwordless enterprise access. Passkeys are phishing-resistant, but the article makes clear that phishing resistance does not solve malware on the endpoint or abuse of the re-registration path. For identity governance, that shifts the control question from authentication method selection to trust-boundary enforcement across device, browser, and recovery flow. The practitioner conclusion is that passwordless programmes need endpoint governance that matches the credential model in use.
Credential lifecycle controls are now part of passkey governance, not an implementation afterthought. The article highlights recovery, re-registration, and master-key handling as the points where assurance collapses. That means joiner-mover-leaver logic, recovery policy, and offboarding assumptions all matter even for modern passwordless stacks. The practitioner conclusion is that lifecycle governance must extend to how a passkey is recreated, rebound, and retired.
Device-bound passkeys are the better enterprise default because they preserve the boundary that synced passkeys erase. A passkey tied to one enrolled device or dedicated hardware does not rely on a cloud-held shared secret that can be extracted or reused elsewhere. This is not a vendor preference; it is an identity architecture choice. The practitioner conclusion is to reserve synced passkeys for low-risk convenience use cases and keep higher-assurance workflows on bounded hardware roots.
Passkey assurance has to be measured at the endpoint, not inferred from the authentication protocol alone. The article makes clear that an authentication method can still be compromised after the user has done everything right if the device is already hostile. That collapses the old assumption that credential protection is mostly an authentication-layer problem. The practitioner conclusion is to align passkey assurance with endpoint risk and recovery design, especially in regulated environments.
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
Shared-secret passwordless designs create a governance problem, not just a user-experience choice. When one recoverable secret can unlock multiple devices, the identity programme inherits a cross-device blast radius that most access policies never model explicitly. That is why passwordless strategy has to be aligned with device trust, recovery governance, and the sensitivity of the account being protected.
Credential recovery is now part of the attack surface for modern IAM. Teams that evaluate passwordless solely on phishing resistance miss the point of this research. The control question is whether recovery can silently replace trust, because that is where a synced credential model can turn a legitimate re-enrolment path into a takeover path.
Device-bound assurance should be the baseline for higher-risk workforce access. For regulated environments, the safer design is the one that preserves the credential’s attachment to a known device or hardware token and avoids a cloud-held shared secret. That reduces the chance that a compromised endpoint can become an account-wide compromise event.
For practitioners
- Prioritise device-bound passkeys for workforce access Use device-bound or hardware-rooted passkeys for employees, administrators, and regulated workflows where a shared cloud secret would materially expand blast radius.
- Harden re-registration and recovery flows Require strong trusted-hardware verification before a new passkey can replace an existing one, and treat recovery as a privileged lifecycle event.
- Add endpoint detection to passwordless programmes Pair phishing-resistant authentication with malware detection on the same device class that stores or uses passkeys, so a compromised endpoint is flagged before reuse.
- Remove shared-secret assumptions from credential design Review whether any passkey or credential store depends on a single recoverable master secret, then redesign those flows so one compromise cannot decrypt the entire account estate.
Key takeaways
- Synced passkeys can still be abused after endpoint compromise, so phishing resistance alone is not enough for enterprise assurance.
- The article’s key risk is not passkey cryptography failure, but a shared trust model that lets malware exploit recovery and re-registration.
- Enterprises should reserve synced passkeys for lower-risk use cases and favour device-bound or hardware-rooted credentials for sensitive access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article shows synced passkeys failing under device compromise and weak trust validation. |
| NHI-07 — Long-Lived Secrets | A non-rotatable master secret can decrypt every synced passkey on an account. | |
| NHI-08 — Environment Isolation | Malware on one endpoint can affect credentials that are reused across devices. | |
| Recommendation — Use NHI-04 to validate device trust and authentication paths for passkey-based sign-in. Eliminate non-rotatable shared secrets from synced credential designs and recovery paths. Isolate device trust domains so compromise on one endpoint cannot spill into account-wide credential access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centers on authenticator lifecycle, recovery, and replacement controls. |
| Recommendation — Apply IA-5 to govern authenticator replacement, recovery, and rotation for passwordless credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Enterprise passkey assurance depends on enforcing correct authorization boundaries. |
| Recommendation — Use PR.AA-05 to tie passkey entitlement and re-registration to explicit authorization. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack moves from device compromise into credential abuse and account takeover. |
| Recommendation — Map Pass-ta-key patterns to credential access and lateral movement detections in your endpoint telemetry. | ||
Key terms
- 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.
- 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.
- Recovery Path: The set of backup methods, reset flows, and help-desk procedures that restore access when a user loses their primary credential. Recovery paths often become the weakest part of identity governance because they can reintroduce shared secrets, manual override, or inconsistent verification standards.
- Master Secret: A high-value root secret used to protect or decrypt other credentials in a synchronised credential store. If it is exposed, the impact is disproportionately large because one secret may control access to many passkeys, creating a broad and difficult-to-rotate compromise condition.
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.
Published by the NHIMG editorial team on August 11, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org