Passkey Enrollment Is Your New Attack Surface: What Pass-the-Passkey Means for Your IdP

The pitch for passkeys was simple, and it was true: there is nothing to phish. No string the user can be tricked into typing into a lookalike domain. For organizations that had spent a decade losing accounts to credential phishing, that was reason enough to move.

Then, within forty-eight hours of each other in early August 2026, two independent research teams published work that changes what that sentence means in practice. Neither of them broke the cryptography. Both of them went around it — and both landed in the same place: the moment a credential gets registered.

If you are running or planning a centralized identity deployment, this is the part worth reading carefully. The engineering response is almost entirely a configuration problem, and most of it lives in your identity provider rather than your endpoints.

What actually landed in August

Unit 42, 3 August. Researcher Arie Olshtein published three attack chains against Google Password Manager’s synced passkeys, working through the cloud authenticator that Chrome uses on Windows. All three assume malware is already running on the machine at ordinary user privilege — no administrator rights, no prompt on the victim’s screen.

The first path impersonates the trusted device to Google’s cloud authenticator and obtains a valid authentication assertion outright, with no fingerprint or PIN interaction. The second abuses the device re-enrollment workflow: the malware invalidates the existing verification key or deletes the local credential-state file, forces Chrome to re-onboard, and registers its own user-verification key in the process — after which the attacker can sign in from their own machine and never touch the victim’s device again. The third, and the most consequential, extracts the 32-byte security domain secret that briefly sits in Chrome’s process memory during re-enrollment. That single value decrypts every synced passkey private key on the account, including ones created afterwards, and there is currently no mechanism to rotate or revoke it once it leaks.

No CVEs were assigned. Google has shipped some mitigations.

SpecterOps, 5 August, Black Hat USA. Michael Grafnetter presented a family of attacks named, deliberately, after Pass-the-Hash. The most serious chain combined two weaknesses: Windows 11 was writing complete WebAuthn assertion responses into an operational event log that authenticated unprivileged users — in some configurations, remote ones — could read, and Microsoft Entra ID was not validating those responses strictly enough to reject a replay. Together that allowed an attacker to impersonate a privileged cloud identity while still satisfying phishing-resistant MFA enforcement. The same research found past hardware-token signatures sitting in cleartext where unprivileged accounts could read them.

Microsoft addressed the Windows logging half as CVE-2026-34348 in the 14 July 2026 updates, truncating the logged signature to six bytes — enough for troubleshooting, not enough to replay. SpecterOps considers the full Windows-to-Entra chain broken on patched systems.

The structural point: the risk moved to enrollment

Under passwords, the secret is the asset. Steal it, replay it. Every defense we built — rotation, complexity rules, MFA, impossible-travel correlation — assumes the attacker’s goal is to obtain something the user already has.

Under passkeys, that goal largely stops working. A device-bound private key does not leave its authenticator, and phishing a passkey is not a thing. So the attacker’s question changes from how do I steal their credential to how do I get one issued to me.

The Silver Pass-ta-key path is the cleanest illustration. The attacker never obtains the user’s key. They add their own, through the workflow the system provides for exactly that purpose. That is not credential theft. That is credential issuance — and it is durable in a way a stolen password never was, because it survives the password change and the session revocation that normally end an incident.

There are only two moments when an identity provider will accept a new authenticator: initial enrollment, and recovery or re-enrollment. In most deployments those are the two least monitored, least policy-gated operations in the entire identity stack.

flowchart TD
    A["Credential enrollment"] --> B["Everyday authentication"]
    B --> C["Recovery or re enrollment"]
    C --> A
    A --> D["Attacker registers their own authenticator"]
    C --> D
    B --> E["Assertion captured from logs and replayed"]
    C --> F["Sync master secret extracted during re onboarding"]
    D --> G["Durable access that survives password reset"]
    E --> G
    F --> G

The practical corollary is uncomfortable but clarifying: your passwordless posture is exactly as strong as your weakest enrollment path. If a helpdesk agent can bind a new authenticator to a finance director’s account off the back of a phone call, you have a password-reset process wearing a passkey costume.

Six things to configure on your identity provider

1. Treat enrollment as a privileged operation

The default in a lot of tenants is that any authenticated session can register an additional authentication method. Think about what that means: a stolen session cookie, which used to expire, now converts into a permanently registered credential.

Gate registration behind conditions that a session cookie alone cannot satisfy — a managed or compliant device, a fresh step-up challenge performed in the last few minutes, a known network range, or an explicitly opened administrative window. In Entra ID this is the authentication methods policy combined with a Conditional Access rule targeting the security-information registration user action. In Authentik it means a dedicated enrollment flow with its own stages and policies, rather than allowing the standard login flow to bind new devices as a side effect.

The rule to hold onto: the credential authorizing the addition of a new credential should be at least as strong as the one being added.

2. Stop treating the user-verified flag as proof a human was present

Relying parties routinely accept the user-verified bit in an assertion as evidence that someone touched a sensor or entered a PIN. Unit 42’s finding is that a compromised authenticator can set that bit with nobody touching anything at all.

Where you own the relying party, validate the whole assertion rather than reading one boolean: origin, challenge freshness, signature counter behaviour, and the authenticator model identifier against an allowlist. Where you do not own it — most SaaS — the compensating control has to sit at the identity provider, by constraining which authenticator models are allowed to register in the first place.

3. Decide synced versus device-bound per tier, not globally

Synced passkeys are the reason passkey adoption happened at all; the recovery story is what made them usable for normal humans. They are also a cloud account’s worth of blast radius, and Golden Pass-ta-key demonstrated that the master secret behind that sync has no revocation story today.

A defensible split: synced credentials are fine for the long tail of internal applications. Device-bound hardware authenticators, with attestation required at registration, for administrative roles, finance systems, and anything that can move money or alter identity configuration. Enforce it with attestation and model allowlisting at registration time, because a policy document does not stop a registration request.

4. The recovery path is your real security level

Every passwordless deployment keeps a fallback, because people lose phones. SMS one-time codes, email magic links, helpdesk-initiated resets, temporary access passes.

If the fallback can mint a passkey, then the fallback is your authentication strength, regardless of what the primary method is. Attackers have gone straight to the recovery path for a decade and there is no reason to expect that to change now that the primary path got harder.

Concretely: keep temporary access pass issuance restricted to a small named group, short-lived, single-use, and alerted on every single issuance. Require helpdesk-initiated resets to verify the caller through a channel the caller could not already have compromised — which rules out the email address and the phone number attached to the account.

5. Build a credential inventory, then alert on changes to it

Most organizations cannot answer basic questions about their own authenticators: how many does this user have, when was each registered, from what device and location, and which are still actually in use.

Build that report first. Then alert on the patterns that matter — a registration from a new country, a second credential added minutes after the first, registrations outside working hours, and any credential change on an account holding a privileged role. These should page someone, not sit in an audit log that gets read after the incident.

Offboarding matters here too. A SCIM deprovisioning event needs to invalidate sessions and remove registered credentials. A deactivated account with a live authenticator still attached is a reactivation waiting to happen — and it is precisely the kind of gap that a centralized identity layer is supposed to close.

6. Confirm the July patch actually landed

CVE-2026-34348 shipped on 14 July 2026. The Windows-to-Entra replay chain depends on it being absent. Verify deployment across the estate, and pay particular attention to administrative workstations and jump hosts, which are both the highest-value targets and, in a lot of organizations, the machines most likely to be excluded from a standard patch ring.

What the hardened flow looks like

flowchart TD
    U["User requests a new authenticator"] --> P1["Check device is managed and compliant"]
    P1 --> P2["Require fresh step up verification"]
    P2 --> P3["Check attestation against model allowlist"]
    P3 --> T["Evaluate account tier"]
    T --> H["Privileged tier requires device bound hardware key"]
    T --> S["Standard tier permits synced passkey"]
    H --> L["Emit registration event and alert"]
    S --> L
    L --> R["Credential registered and added to inventory"]

If you also run detection

The enrollment controls above are the durable fix. If you operate an endpoint telemetry estate as well, three signals map cleanly onto the Unit 42 techniques and are worth adding to your rule set: unexpected process access to browser memory from unsigned or unusual binaries, browser credential-state files created or deleted by something that is not the browser, and reads of the browser’s sync database by non-browser processes. On a Sysmon estate these are event IDs 10 and 11 plus standard file-access telemetry.

On the identity side, the events to promote out of the audit log and into alerting are authentication-method registration and removal, temporary access pass issuance, attestation validation failures, and any credential change touching a privileged role. If you are already running a Wazuh-based monitoring stack, these are log sources, not new tooling.

A short audit you can run this week

1. List every path in your tenant by which a new authenticator can be registered. Include helpdesk procedures, not just technical flows.
2. For each path, write down what an attacker with a valid stolen session — and nothing else — would need to defeat it.
3. Check whether registration is gated on device compliance and a fresh step-up challenge, or only on an existing session.
4. Pull the credential inventory for every account holding an administrative role. Look for anything registered from an unexpected device or at an unexpected time.
5. Confirm which recovery methods can result in a new passkey, and who can trigger them.
6. Verify CVE-2026-34348 deployment on administrative workstations specifically.
7. Check that offboarding removes credentials, not just sessions. Test it with a real account.

FAQ

Should we stop rolling out passkeys?

No. Passkeys eliminate credential phishing, which remains the most common initial access vector by a wide margin. None of the August research changes that. What it changes is the assumption that deploying passkeys completes the identity work — it moves the work to enrollment, recovery, and inventory, which is where it should have been anyway.

Do these attacks affect us if we are not on Google Password Manager?

The specific Unit 42 chains target Google’s synced passkey ecosystem on Windows. The structural lesson applies to any synced credential system, and the SpecterOps chain targeted Windows 11 and Entra ID directly. If your staff authenticate to Microsoft 365, the second body of research is the one to read first.

Is a hardware security key still worth it?

For privileged accounts, yes — device-bound credentials with attestation remain the strongest option available, and the sync master-secret problem does not apply to them. The August research did find hardware-token signatures exposed in Windows logs, which is an argument for patching, not for abandoning hardware tokens.

We are a mid-size company without a dedicated identity team. Where do we start?

With the enrollment gate and the recovery path. Those two controls close most of the practical risk and neither requires new software — they are configuration changes on the identity provider you already run. The credential inventory comes next, because you cannot alert on changes to something you have never enumerated.

Does centralizing on a single identity provider make this worse by concentrating risk?

It concentrates the control point, which is the opposite of concentrating risk. With twenty-four separate login systems, there are twenty-four enrollment and recovery paths, most of which nobody has ever audited. With one identity provider there is one set of paths to harden, one credential inventory to maintain, and one place to revoke from.

---

Where this fits

Centralized identity is the precondition for all of this. You cannot gate enrollment, enforce attestation tiers, or maintain a credential inventory across a fragmented estate where each application manages its own logins — which is the underlying argument for consolidating in the first place.

Simplico builds and operates simpliSSO, an Authentik-based identity portal federated to Microsoft 365 and Azure AD, covering OIDC, SAML2, LDAP, step-up MFA policies, and SCIM provisioning across the full application estate. If you are working through enrollment hardening on an existing deployment, or scoping a new one, we are happy to look at your environment: hello@simplico.net.

---

Sources:

• Pass the Passkey: A Novel Attack Surface in Passwordless Authentication — Unit 42
• New Passkey Attacks Can Recover Synced Private Keys or Bypass Phishing-Resistant MFA — The Hacker News
• New Pass-ta-key attacks let malware hijack Google-synced passkeys — BleepingComputer
• Flaws in Passkey Implementation Show Old Attacks Still Work — Dark Reading
• Pass-the-Passkey Family of Attacks at Black Hat USA 26 — DSInternals