We’re seeing reports across social media that users of Elon Musk’s X (formerly known as Twitter) are getting stuck in endless loops and, in some cases, getting locked out of their X (formerly known as Twitter) account, following a mandatory two-factor security change that seems to have gone wrong.
On October 24, X (formerly known as Twitter) said in a post that it was asking users who rely on passkeys or hardware security keys (such as YubiKeys) as their method of two-factor authentication to re-enroll using the x[dot]com domain. (Users who use an authenticator app are unaffected.)
X (formerly known as Twitter) said [that] this was part of an effort to retire the older twitter[dot]com domain, which currently redirects to x[dot]com. That change took effect in May 2024. The problem is that passkeys and security keys are digitally tied to the old twitter[dot]com domain and can’t be transferred to x[dot]com. That means users have to manually un-enroll and re-enroll using the new x[dot]com domain.
As part of the switchover, X (formerly known as Twitter) warned that after November 10, customers would have their accounts locked until they re-enroll or choose another method of two-factor authentication.
Now that the deadline has passed, plenty of users are reporting that they’ve been locked out of their accounts and can’t re-enroll their passkey or security key, citing error messages or getting caught in an endless loop.
This is the latest issue to beset X (formerly known as Twitter), now owned by Elon Musk after he bought Twitter, as it was known then, for $44 billion. Since taking charge of the social networking site, the company has experienced massive layoffs and countless controversies.
X (formerly known as Twitter) did not respond to a request for comment, but Musk, who now owns X (formerly known as Twitter), has been posting as usual, presumably unaffected by the change.
Do you think this could have happened if passkeys were like ssh key based auth?
I can give a longer explanation later if you want.
Well, naturally, if it was like ssh, it probably wouldn’t have happened. I’ll take a write-up if you feel up for it, but I can also look up the whitepaper too.
Ok I read the “Whitepaper” and I still don’t really understand what the difference is. The server stores your public key and uses that key to encrypt a challenge message that is sent to your device, which you then use your private key to decrypt to prove your identity. This is tied to the domain that the key was created on. That’s the only real difference I can see here and the least explained part of the white paper. HOW is it bound to the domain address? If the domain address of the server I’m trying to SSH into changes and I try to connect to the old address, obviously it fails, but I probably know the new address. If I attempt to connect to the new address, I’ll be provided a signature for the server I’m connecting to, and then it would attempt the key challenge for authentication.
So is the domain address used in some silly way with passkeys that causes the key pair to become invalid? It reminds me of the issues with changing your domain on Lemmy, where you can’t convince the federated instances that this new domain is a continuation of the old domain because I think the old domain is used as part of the cryptographic process, and so when it changes, any authentication attempts from the new domain fail.
Which white paper are you referencing? Ive been meaning to read up on this.
This is the one I was refrencing: https://fidoalliance.org/white-paper-replacing-password-only-authentication-with-passkeys-in-the-enterprise/
But then there is also this one that I just saw in the search results, might have more information the above was lacking: https://www.onespan.com/sites/default/files/2025-11/OneSpan-White-Paper-Passkey-Security.pdf
Thanks! Really appreciate it
I am also interested in a longer explanation if you have the time!