X (formerly Twitter) has notified users that they must re-register their passkeys and hardware security keys used for two‑factor authentication (2FA) by 10 November. Accounts that do not update will face a temporary lock until users rebind their keys, switch to another 2FA method, or disable 2FA (the latter is not recommended).
Who is affected and what will change in 2FA on X
This requirement applies only to accounts using phishing‑resistant 2FA based on FIDO2/WebAuthn—namely device‑stored passkeys and hardware security keys such as YubiKey. X Safety clarified that users can re‑register their current key or add a new one. A critical detail: registering a new key will invalidate previously registered keys, so plan the update carefully if you sign in from multiple devices.
Why this is happening: RP ID binding and the move to x.com
X says the change is not related to a security incident. The platform is completing its migration from twitter.com to x.com. Under the WebAuthn standard, authenticators are cryptographically tied to a site’s Relying Party Identifier (RP ID)—typically the domain. As a result, passkeys and hardware keys registered for twitter.com will not validate against x.com once the legacy domain is fully retired.
How to re-register passkeys and hardware security keys on X
To manually update, go to x.com/settings/account/login_verification/security_keys. Remove existing security keys and register them again for x.com. You will be prompted to confirm the action with your account password. If preferred, you can temporarily switch to an authenticator app (TOTP), but for maximum phishing resistance, maintain passkeys or hardware keys as your primary factor.
What makes passkeys phishing-resistant and why they matter
Passkeys and FIDO2/U2F security keys use asymmetric cryptography: the private key remains on your device or hardware token, while the service receives only a signed challenge. Because the authenticator verifies the origin (domain) during the protocol flow, it blocks credential reuse on look‑alike phishing sites. Real‑world results back this up: Google reported eliminating successful employee phishing account takeovers after moving to security keys (Google Security Blog), and NIST SP 800‑63B identifies phishing‑resistant authenticators (such as FIDO2) as preferred. By contrast, SMS codes are vulnerable to interception and SIM‑swapping attacks (see FCC guidance), and NIST flags SMS OTP as a restricted authenticator due to these risks.
Operational risks of delaying the update and safer interim options
Deferring re‑registration may lead to temporary account lockouts after 10 November—an operational issue for brand, corporate, and developer accounts that rely on continuous access. Avoid disabling 2FA to regain entry. If you need a fallback during the migration window, use an authenticator app as a temporary measure and return to passkeys or hardware keys as soon as possible.
Practical preparation checklist for organizations and power users
Test sign‑in flows from all workstations and mobile devices, ensure browsers and operating systems are up to date with WebAuthn support, and verify primary email access for recovery. Enterprises should document the re‑registration procedure, schedule a maintenance window before the deadline, and communicate the change to staff to prevent mass lockouts. When registering a new key, remember that older keys will stop working—coordinate updates across all users and devices.
Completing passkey and security key re‑registration now will preserve phishing‑resistant MFA on x.com and minimize business disruption. Act before 10 November: update your passkeys or hardware keys, validate access from every device you use, and keep an authenticator app as a fallback—not as a replacement. Strengthening authentication today remains one of the most cost‑effective ways to prevent account compromise tomorrow.
