32 Bytes, No Rotation: How Pass-ta-key Steals Every Synced Google Passkey

Thirty-two bytes. That is the entire size of the key that encrypts every passkey Google syncs across your Chrome installs, and Google has confirmed there is no way to rotate or revoke it. Unit 42 published research this week showing that unprivileged malware, already running on a victim's machine with no administrator rights and no biometric prompt, can pull that key straight out of Chrome's process memory, decrypt every synced credential tied to the account, and forge valid logins to whatever those passkeys protect.

The researchers call the technique family Pass-ta-key, and they demonstrated three distinct attacks, each worse than the last. This affects you if your organization treats Google Password Manager as the place passkeys live, particularly on Windows machines with a TPM, which is the default on most business laptops sold since 2022: engineers signing into GitHub with a synced passkey, staff with a passkey-protected Salesforce or Workspace login, anyone who registered a passkey and let Chrome carry it to their next device instead of binding it to hardware. It does not affect you if every passkey in your environment lives on a hardware security key like a YubiKey, and it does not fully apply to Apple's iCloud Keychain or Microsoft's platform authenticator, which sync credentials through different architectures Unit 42 did not test here. The underlying lesson about where a synced credential's master secret ends up still applies to all of them, and it is worth reading this even if Google Password Manager is not your stack.

How malware turns a synced passkey into a skeleton key

Every device that joins Chrome's passkey sync group gets its own identity key, wrapped by the machine's TPM. On its own, that identity key is the first attack: Pass-ta-key. Malware exports the wrapped identity key using standard Windows CNG APIs, then uses it to sign an authentication request to Google's cloud authenticator without touching a passkey record directly. The cloud authenticator validates the device signature and returns an assertion, and the only thing missing from a fully legitimate login is the user-verified (UV) flag: a single bit that some relying parties, including eBay before the researchers reported it, did not bother to check.

The second attack, Silver Pass-ta-key, goes further. Malware forces the device to re-enroll by deleting or tampering with Chrome's local passkey_enclave_state file, then races into the resulting registration window before the legitimate user-verification key is created. The cloud authenticator accepts the attacker's replacement key without checking whether it came from real secure hardware. From that point forward, the attacker holds a reusable, fully user-verified credential and does not need the victim's device online again.

The third attack, Golden Pass-ta-key, is the one that should worry every defender reading this. It uses the same re-enrollment trigger to force Chrome to recover the account's Security Domain Secret, the 32-byte master key that encrypts every synced passkey. Google removed that key from its debug logs after Unit 42 reported it, but the key still transits through Chrome's process memory in plaintext to complete the recovery, and malware dumping that memory at the right moment walks away with it. With the SDS in hand, an attacker decrypts every passkey the account has ever synced, offline, with no further contact with the victim's device required.

The design choice that makes this possible

Passwordless authentication was sold on a simple promise: a passkey's private key never leaves the device it was created on, so there is nothing for a phishing page to capture and nothing for a database breach to leak. That promise holds for the phishing half. It runs into trouble the moment a vendor adds cross-device sync, because syncing a private key to a new device requires shipping some secret that can decrypt it, and that secret has to exist somewhere a new device can retrieve it from.

Google's answer is the Security Domain Secret: a single key, generated once, that wraps every passkey the account will ever hold. Unit 42's finding is that this secret is not confined to a hardware enclave the way the underlying passkey private keys are. It transits through Chrome's ordinary process memory during recovery and re-enrollment, where any code running as the logged-in user can read it. Because there is no rotation mechanism, a single exposure compromises every passkey currently in the account and every passkey that account will ever be used to create, indefinitely. A stolen password gets reset. A stolen TPM-bound private key stays on the device it never left. A stolen Security Domain Secret has no equivalent recovery path today.

Synced passkeys vs. hardware security keys: the real trade-off

Software (synced) passkeys and hardware-bound passkeys were marketed as interchangeable flavors of the same phishing-resistant control. Unit 42's research is the clearest evidence yet that they carry meaningfully different risk once you account for endpoint compromise, and the decision about which one to require deserves the same rigor you would apply to choosing a privileged-access workstation policy.

Synced passkeys cost nothing beyond what the user already owns, follow the user automatically between a new laptop and a new phone, and recover cleanly if a single device is lost because the account already holds copies elsewhere. The cost of that convenience, per this research, is that the private key material for every credential in the account is decryptable from one client-side secret that cannot be rotated, and an attacker only needs code execution on one enrolled device to reach it.

Hardware-bound security keys (a FIDO2 token like a YubiKey 5 series, roughly $25 to $60 per employee) generate and store the private key inside the token's own secure element and never export it, synced or otherwise. Compromising the endpoint's operating system does not get an attacker the key material, because the key material was never resident on that operating system to begin with. The cost is real: hardware to issue, a re-enrollment process when a key is lost, and a backup key requirement so nobody gets locked out of a privileged account because they misplaced a token.

The recommendation here is to stop treating synced and hardware-bound passkeys as the same control for every account. Passkeys as a category remain a real improvement over passwords; the choice that matters now is which type protects which account. Require hardware-bound keys for the accounts where a stolen master key would actually matter: Entra ID and Okta global admins, domain admin equivalents, GitHub and GitLab organization owners, cloud provider root and IAM-admin identities, anyone who can create another privileged account. Synced passkeys are a reasonable, low-friction choice for standard user accounts, provided the endpoint hygiene around them (EDR coverage, no local admin rights, current patch levels) is actually enforced, since every attack in this research starts from malware already running on the box.

What to check this week

None of this requires waiting on a Google fix that may never fully arrive for a secret that was never built to rotate. Three things are worth verifying in the next few days:

Three things to verify today

• Which privileged accounts still use a synced passkey. Pull the authentication methods registered against every Global Administrator, Privileged Role Administrator, and Security Administrator in Entra ID, plus the equivalent roles in Okta, GitHub, and your cloud provider. Anything relying on a software passkey instead of a hardware-bound one is a candidate for migration this month.
• Whether your own relying parties enforce the UV flag. If you run anything that accepts WebAuthn logins directly, confirm it rejects assertions where userVerification is not set, the exact gap Unit 42 found unpatched at eBay before disclosure. A missing check here turns Pass-ta-key from "needs a re-enrollment window" into "works immediately."
• Whether your EDR would notice the access pattern. A process other than chrome.exe reading Chrome's Local State, Login Data, or passkey_enclave_state files, or calling NCryptOpenStorageProvider and NCryptExportKey outside Chrome's normal behavior, is not something most EDR baselines flag today. It is now a documented technique rather than a theoretical one, and it is worth a detection rule even before you know of a specific campaign using it.

The first check is the one that actually moves risk, and it does not require any code beyond what most identity teams already have access to. Microsoft Graph PowerShell can answer it directly for your Entra ID privileged roles:

# Audit FIDO2/passkey registrations for Entra ID privileged roles.
# Flags AAGUIDs that are not on your approved hardware-security-key allowlist.
Connect-MgGraph -Scopes "RoleManagement.Read.Directory","UserAuthenticationMethod.Read.All"

# Replace with the AAGUIDs of the hardware keys you actually issue,
# e.g. a YubiKey 5 series AAGUID from the FIDO Metadata Service.
$approvedHardwareAaguids = @("cb69481e-8ff7-4039-93ec-0a2729a154a8")

$privilegedRoles = @("Global Administrator","Privileged Role Administrator","Security Administrator")

foreach ($roleName in $privilegedRoles) {
    $role = Get-MgDirectoryRole -Filter "displayName eq '$roleName'"
    if (-not $role) { continue }

    Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id | ForEach-Object {
        $user = Get-MgUser -UserId $_.Id -Property DisplayName,UserPrincipalName
        Get-MgUserAuthenticationFido2Method -UserId $_.Id | ForEach-Object {
            $status = if ($approvedHardwareAaguids -notcontains $_.AaGuid) { "REVIEW" } else { "OK" }
            [PSCustomObject]@{
                User   = $user.UserPrincipalName
                Role   = $roleName
                AAGUID = $_.AaGuid
                Model  = $_.Model
                Status = $status
            }
        }
    }
}

Run that against every privileged role in your tenant, and anything that comes back REVIEW is an account where a compromised endpoint, somewhere in the account's history, could have exposed a synced master key that will never be rotated. Fixing it is a matter of issuing a hardware key and re-registering the account, work most identity teams can finish before the next access review.

Move the accounts that matter behind a key nothing can sync

Pull the list of privileged accounts across Entra ID, Okta, GitHub, and your cloud providers today, check what each one actually authenticates with, and move the ones with the largest blast radius to a hardware-bound key this week. Leave standard user accounts on synced passkeys if your endpoint hygiene genuinely supports it, and revisit that call if it does not. The rest of the fix belongs to Google, and it is not clear yet what a complete one looks like for a key that was designed without a rotation path.