X Security Key Switchover Shuts Users Out

Users on the social platform X are locked out of their accounts after the company inadvertently forced a change to re-enroll passkeys and hardware security keys on x.com, its domain. The change, which retired credentials associated with the old twitter.com, has resulted in infinite error loops and unsuccessful enrollments for many people, leaving users behind an inescapable mandatory two-factor prompt.

Users of the authenticator app seem largely unaffected. The havoc is focused on people who are using FIDO-based passkeys or physical tokens like YubiKeys to log in with phishing-resistant login, the very category of folks inclined to up their account security. Several reports online suggest that after a cutoff, affected users are being prompted to enter into a re-enrollment flow that ends in error and prevents them from signing in.

What Broke With Security Keys During X’s Migration

The crux of the issue is in how passkeys and hardware security keys operate. Under the WebAuthn standard, a credential is cryptographically bound to a specific “relying party ID” (RP ID), and thus to the domain of a site. Credentials registered to twitter.com won’t prove their identity to x.com. That means you need orchestration to carefully re-provision any time there’s a domain migration.

Users were advised to unenroll and re-enroll their keys under x.com, X said in its post. But as widely reported bugs that ranged from session validation errors to endless loops between login and security settings indicate, the flow wasn’t designed to be resilient in those spot cases where cookies expired, if you have a multi-device account, or when an old-style U2F token is involved. When third-party violations started getting enforced, what had been bugs turned into lockouts.

Why Domain Changes Often Disrupt Passkeys and Keys

WebAuthn, and the FIDO Alliance model it was built on, are intentionally strict: credentials should only work to unlock the site for which they were created; otherwise, this would allow phishing. Some backwards compatibility is provided through the legacy U2F “appid” extension, but that is not uniformly available across browsers and does not cover new synced passkeys. In other words, in practice moving from one domain where requests are registrar-locked to a different registrable domain requires, e.g., either a transitory parallel deployment on the old name for long enough for clean migration, or else bulletproof re-enrollment protocols backed by serious fallbacks.

Standards bodies like W3C and FIDO recommend that services support multiple authenticators per account, and not have single points of failure while transitioning.

NIST’s digital identity guidance also emphasizes recovery flows that don’t push users down to weaker factors such as SMS unless risk controls are applied.

The Effect on Users and Teams Relying on Security Keys

In addition to annoying ordinary people, locked accounts can cripple newsroom social desks, brands conducting paid campaigns, and support channels that depend on immediate account access. Some companies keep staffers on rotation in different time zones — if the person with the physical key to the hardware is not available, a glitchy re-enrollment flow can jam things up. Even worse, when strong sign-in methods fail, users often revert back to weaker ones, which increases their susceptibility to phishing.

Where X Could Have Done Better During Key Migration

Migrations like that of Costco’s security operation succeed when they are slow, redundant, and highly communicative. Best practices include:

• Providing backup codes ahead of time
• Allowing multiple passkeys and hardware keys per account before enforcement
• Supporting authenticator apps as a temporary second factor
• Running a canary rollout to catch breakage

Transparent in-product guidance to guarantee a backup factor before disabling the old one helps avoid lockouts.

Technically speaking, services can also keep the old domain alive temporarily before it is finally decommissioned, monitor enrollment success rates in real time, and automatically halt enforcement if the failure rate exceeds any set threshold.

Enterprise accounts should also have an administrative recovery path, and be able to rely on organization-level SSO for standards like SAML or OIDC rather than having access tied to a single device.

What to Do If You Were Affected by the X Key Switch

• Try re-enrolling on a different device (desktop vs. mobile).
• Ensure you are redirected to the correct x.com domain when enrolling, and use a modern browser with strong WebAuthn support.
• If you still can’t make it through the loop, try to add or swap an authenticator app as a fallback second factor, then add your passkey again along with your hardware keys on x.com.
• Enroll at least two authenticators — a hardware key and then a passkey or an authenticator app — and keep offline backup codes in a secure location.

For team-managed accounts, assign multiple custodians and register keys on separate devices to prevent single points of failure. Beware of phishing in recovery; attackers take advantage of moments of disarray with lookalike domains and support messages. Those who do reach out will have to be prepared to provide their identity through known means, and should never share one-time codes with strangers.

The Bigger Lesson About Passkeys, Risk, and Trust

Passkeys and hardware security keys are still the gold standard in defending against phishing. Microsoft claims that enabling any type of MFA blocks 99.9% of automated account compromise attacks, and Google’s own studies have found that hardware-backed keys thwart almost all automated phishing attempts. The issue here isn’t the technology; it’s change management. If a platform fumbles domain-bound credential migration, trust is eroded and users are pushed away from stronger defenses.

Everyone will be watching to see whether X eases enforcement, closes the enrollment loop, and introduces safer recovery paths. There is a simple way to restore confidence quickly: Make the secure thing the easy thing and do not lock people out in the process.