WebinarLive on Nov 18: Building a Business Case for PasskeysPasskey Business Case, recording for all registrantsRegister
Back to Overview

Synced Passkey Attacks: New Threat Models

Synced passkeys stop phishing, so attackers target recovery, endpoints and fallbacks. New synced passkey attacks from Authenticate 2026 and how RPs defend.

Vincent Delitz
Vincent Delitz

Created: October 29, 2026

Updated: October 30, 2026

Synced Passkey Attacks: New Threat Models
Key Facts
  • A phishing kit run by the threat actor tracked as UNC6671, active since early 2026, targets iCloud Keychain recovery to pull all of a victim's synced passkeys (Palo Alto Networks, Authenticate 2026).
  • Palo Alto Networks showed three malware-based attack classes against Google Password Manager's cloud authenticator on desktop, none of which break WebAuthn cryptography.
  • A single 32-byte Security Domain Secret decrypts every synced passkey in a Google account, and Google offers no way to rotate or revoke it today, according to the researchers.
  • eBay accepted assertions without checking the user verification flag until the researchers reported it. eBay now validates the flag.
  • 75% of passkeys registered in Microsoft Entra in the previous month were synced, Microsoft reported at Authenticate 2026.
  • PayPal sees no evidence of phishing among passkey logins. Takeovers happen through SMS OTP and password fallbacks, followed by attacker-registered passkeys.

1. Introduction#

Passkeys stopped phishing, replay and man-in-the-middle attacks at the protocol level, so attackers moved to the layers around the protocol. At Authenticate 2026, Arie Olshtein (Sr. Staff Security Researcher, Palo Alto Networks) showed a live phishing campaign that hijacks iCloud Keychain recovery and three endpoint attacks on Google's synced passkey design. One of them targets a 32-byte master secret that cannot be rotated today.

PayPal sees takeovers through phishable fallbacks while passkey logins show no evidence of phishing. This article describes the new attack classes conceptually and lists the defenses relying parties control. For the basics, see why passkeys are phishing-resistant.

WhitepaperEnterprise Icon

Enterprise Passkey Whitepaper. Practical guidance, rollout patterns and KPIs for passkey programs.

Get Whitepaper

2. Why do synced Passkeys need a different Threat Model?#

Synced passkeys trade hardware binding for recoverability. The private key is backed up and available on every device of the user, which enables planet-scale adoption but moves part of the attack surface to the cloud account, the sync service and the endpoint that unlocks it. Arie Olshtein called synced passkeys a deliberate trade-off: no shared secret to phish, but a larger surface around the key.

Source: Arie Olshtein and Amir Landau (Palo Alto Networks), Authenticate 2026

Synced passkeys now dominate new registrations even in enterprises. Hana Kim (Senior Product Manager, Microsoft) reported at Authenticate 2026 that 75% of passkeys registered in Microsoft Entra in the previous month were synced, with synced passkeys growing 330% month over month.

Credential managers harden this with cloud authenticators. In Google Password Manager on desktop, the private key is only decrypted inside an isolated cloud enclave. Microsoft runs passkey operations and PIN checks in Azure Confidential Compute, said Rakia Segev (Product Manager II, Microsoft). According to Arie Olshtein, Apple uses a very similar model. See device-bound vs. synced passkeys for the basic trade-offs.

3. How do Attackers phish synced Passkeys through Account Recovery?#

Attackers phish the recovery of the passkey provider account instead of the passkey. The UNC6671 campaign shown at Authenticate 2026 sends a fake security alert, relays a real Apple verification code and then asks for the iPhone passcode, which also works as an iCloud Keychain recovery factor. The attacker's device joins the victim's keychain and receives every synced passkey.

Source: Arie Olshtein and Amir Landau (Palo Alto Networks), Authenticate 2026

Debayan Basu (Principal IAM Engineer, Genuine Parts Company) described this as the recovery paradox. Passkeys sit at NIST AAL2 when synced and AAL3 when device-bound, while most recovery paths using SMS codes, email links or help desk calls are roughly AAL1, as defined in NIST SP 800-63B. Tatsuya Karino (Engineer, Mercari) confirmed that passkey provider account takeover is "actually happening right now". Our article on passkey account recovery covers how Google, Microsoft and Amazon want to close this gap.

4. What can Malware on a compromised Endpoint do to synced Passkeys?#

Malware on a compromised endpoint can misuse the trust that a cloud authenticator places in the device. Palo Alto Networks showed three attack classes against Google Password Manager on desktop, starting from malware that runs as a normal user without admin rights. Each one breaks an assumption relying parties usually make about passkeys, while WebAuthn and FIDO2 cryptography stay intact.

Arie Olshtein presented the joint research with Amir Landau as three classes:

  • Pass-ta-Key signs without any user gesture: Malware lets the victim's own TPM sign requests to the cloud authenticator through device identity impersonation. This breaks the assumption that the user consented. It only works when the relying party does not strictly require user verification.
  • Silver Pass-ta-Key takes over user verification: The attacker replaces the key that proves user verification with one they control. This breaks the assumption that the victim's device takes part in each sign-in.
  • Golden Pass-ta-Key copies every passkey offline: The attacker obtains the account's 32-byte Security Domain Secret and decrypts synced passkeys offline. This breaks the assumption that a passkey cannot be copied, and turns it into a transferable criminal asset.

Golden Pass-ta-Key has the widest impact: one-time access is enough to decrypt every future passkey of that account. Google removed the secret from a Chrome log after the report. Unit 42 published the research in August 2026. As of October 2026, Google offers no way to rotate or revoke the secret, according to Olshtein.

Igor Gjorgjioski Testimonial

Igor Gjorgjioski

Senior Product Lead, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users, alongside their existing IDP.

Read the case study

5. Why must Relying Parties validate the User Verification Flag?#

Relying parties that require user verification must check the UV flag in every assertion. At Authenticate 2026, Palo Alto Networks showed that Google's cloud authenticator returned valid assertions even when no PIN or biometric was used and only cleared the UV bit. eBay required user verification but did not check that bit, so a single compromised factor was enough for account takeover.

eBay fixed the check after the report. In its own session, Ilangovan Vairakkalai (Senior Staff Engineer, eBay) said eBay now enforces and validates both the UV and UP flags, with version-specific waivers for browsers that send them incorrectly.

Setting userVerification to required in the request is only a wish. The server has to verify the UV bit in the authenticator data, as defined in the W3C WebAuthn Level 3 specification. Our guide to WebAuthn user verification explains the request options and the server-side check.

Substack Icon

Subscribe to our Passkeys Substack for the latest news.

Subscribe

6. Why do phishable Fallbacks remain the main Account Takeover Path?#

Phishable fallbacks remain the main takeover path because attackers choose the weakest method on the account. Rakan Khalid (Sr. Director, Identity Product Management, PayPal) said at Authenticate 2026 that PayPal sees no evidence of phishing among passkey logins. Attackers instead take over accounts through SMS OTP or password fallbacks and then register passkeys in their own credential managers.

The FIDO Passkey Index 2026 shows the upside of passkeys: all 8 respondents to the phishing question reported fewer successful phishing attacks, and 3 participants reported fewer account takeovers. The remaining risk sits in what is still attached to the account.

Microsoft sees groups like Jasper Sleet and Scattered Spider target onboarding and recovery instead of authentication, said Sangeeta Ranjit (Principal Lead PM, Identity Division, Microsoft). Debayan Basu cited the 0ktapus OTP relay campaign, which failed only at Cloudflare because Cloudflare used hardware security keys.

7. How can Relying Parties defend against synced Passkey Attacks?#

Relying parties defend best by closing the paths they control: validate the UV flag, remove phishable fallbacks for passkey users, harden recovery and watch for unusual credential events. Credential managers protect endpoints and sync, while relying parties decide what an assertion is worth and what else can sign a user in. Measures named at Authenticate 2026:

  • Validate UV and UP flags on the server: Check both flags server-side whenever the policy requires them (Palo Alto Networks, eBay).
  • Remove phishable fallbacks for passkey users: Test access with phishing-resistant authenticators only, as PayPal plans, or remove phishable methods for consistent passkey users, as Meta is testing.
  • Harden recovery with risk tiers: Use identity proofing and a cooling-off period of about 30 minutes plus one-click revocation (Genuine Parts Company).
  • Treat a new passkey after a fallback login as a red flag: Watch for unexpected recovery, re-registration or a passkey created right after an SMS OTP or password sign-in.

Source: Arie Olshtein and Amir Landau (Palo Alto Networks), Authenticate 2026

Demo Icon

Try passkeys in a live demo.

Try Passkeys

8. How Corbado can help#

The attacks in this article share one pattern: the passkey holds, and the account falls through whatever else is attached to it. A realistic threat model therefore starts with an inventory of the credentials your users hold and of the phishable methods that can still sign them in. Most teams cannot answer either question from their identity provider's logs.

Corbado Observe, the authentication observability layer, builds that inventory from the login you already run. Authenticator Inventory names every credential your users hold from its AAGUID and counts synced and device-bound credentials apart, so the share of passkeys that live in iCloud Keychain, Google Password Manager or a third-party manager becomes visible. That is the exposure the UNC6671 campaign and the Pass-ta-Key classes target.

See Authenticator Inventory in Corbado Observe →

Login Methods puts passkey, password and social side by side on share of logins, completion, error rate and duration. Subflow Explorer counts the phishable factors one level down, the SMS code, the email code, the TOTP app and the push confirmation, with volume, completion and error rate on every line. That is the fallback traffic PayPal and Meta want to remove, expressed as a number. User debugging replays a single journey with its device context, so a fraud team can review a recovery or fallback login that ends in a new passkey registration.

Corbado Connect then acts on that picture. It adds passkeys on top of the identity stack you already run, and Rollout Rules decide per client who is offered which method. Teams can remove phishable fallbacks for passkey users step by step, simulate a ruleset against recorded traffic before it takes effect and roll it back if a cohort breaks. Passkey Intelligence decides on passkey availability from the client environment and the user's existing passkeys, so users with a working passkey are not pushed into the fallback in the first place.

9. Conclusion#

Synced passkeys ended classic phishing at the protocol level. Attackers now target the layers around the key: the UNC6671 campaign phishes iCloud Keychain recovery, Palo Alto Networks showed three endpoint attack classes including a non-rotatable 32-byte master secret and PayPal sees takeovers through SMS OTP and password fallbacks. None of these attacks breaks WebAuthn cryptography.

Relying parties cannot fix credential manager recovery or endpoint malware, but they control three things. They must validate the UV flag on the server, because requiring user verification without checking it leaves a one-factor path. They should remove phishable fallbacks for consistent passkey users. And they should harden their own recovery and treat a new passkey after a fallback login as a red flag. Device-bound passkeys remain the right choice for admins and privileged users, while synced passkeys carry mass adoption.

Corbado

About Corbado

Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (more than 80% passkey activation rate). Talk to a Passkey Expert →

Frequently Asked Questions#

Can synced passkeys be phished?#

The passkey itself cannot be phished, because WebAuthn binds it to the relying party's origin. The account that syncs it can be. At Authenticate 2026, Palo Alto Networks showed the UNC6671 campaign, which phishes an Apple ID, a relayed verification code and the iPhone passcode to join the victim's iCloud Keychain and receive all synced passkeys.

What is a Golden Pass-ta-Key attack?#

Golden Pass-ta-Key is an attack class presented by Palo Alto Networks at Authenticate 2026. Malware obtains the 32-byte Security Domain Secret that protects all synced passkeys in a Google account. With it, an attacker can decrypt passkeys offline and sign in from anywhere. According to the researchers, Google currently offers no way to rotate or revoke that secret.

Why does the UV flag matter for passkey security?#

The user verification (UV) flag shows whether the user unlocked the passkey with a PIN or biometric. Palo Alto Networks showed that a cloud authenticator returned valid assertions without user verification and only cleared the UV bit. eBay required UV but did not check the bit until the researchers reported it. Relying parties must validate it server-side.

Are device-bound passkeys safer than synced passkeys?#

Device-bound passkeys reach NIST AAL3 and cannot be copied through a sync account, so they suit admins and privileged users. Synced passkeys reach AAL2 and are recoverable, which supports mass adoption. Microsoft reported that 75% of new Entra passkeys in the previous month were synced and recommends choosing per persona instead of one rule for everyone.

See what's really happening in your passkey rollout.

Book a Demo

Share this article


LinkedInTwitterFacebook