Changer un mot de passe X (Twitter) sans se retrouver verrouillé

You took over an X account, changed the password straight away because that is what you do with anything you have just been handed, and now something is wrong. Either the scheduling tool has gone quiet, or worse, the platform has asked you to confirm the change at an email address that is not yours.

The instinct is right. The order is usually wrong, and the order is what decides whether you end up in control of the account or shut out of it.

Why the password is not the first step

On most things you buy, changing the password is the move that transfers control. Here it is not, and the reason is that changing a password on X is not a form submission. It is a security event the platform evaluates: which device, which address, how long since the last login. If it reads as unusual, it asks you to confirm, and the confirmation goes to the email address or phone number currently on the account.

On a freshly acquired account those are exactly the things you may not control yet. So the step meant to protect you is the one that locks you out, and it does it while the warranty window is still running but you can no longer demonstrate that the account ever worked.

This is not hypothetical caution. On our own X shelf, out of more than nine hundred live listings, forty two say outright in their own description that the supplied email may not be usable. Check before you act, not after.

The order that works

1. The inbox first. Log in to the email address on the account and confirm you can actually receive mail there. Everything after this is guesswork without it.
2. A quiet login. Log in normally and then do nothing for twenty minutes except read. Do it from the connection you intend to keep using, not from a temporary setup you will tear down afterwards.
3. Sign out the other sessions. This is the step that actually removes whoever else is holding the account, and unlike the password it is not in doubt. More on it below.
4. The contact details. Replace the email address and phone number with your own. This is what transfers control. A password governs future logins; the recovery address governs who can take the account back.
5. Then the password. By this point a confirmation prompt is harmless, because it arrives with you.
6. Then reconnect your tools.

Step four is where most people invert the sequence, and it is the expensive inversion. Changing the password while somebody else's address sits on the account is bolting the door and leaving the key outside.

Worth knowing before you buy rather than after: out of more than nine hundred live listings on our X shelf, only nineteen mention supplying a recovery email at all, and only eight mention that the phone number has been removed. Listings that include a working inbox are common, at about two thirds of the shelf, and they cost roughly a tenth more than the middle listing. That is a small premium for the thing every step above depends on.

The one action that reliably ends other access

This deserves care, because it is widely stated wrongly, including in the earlier version of this page.

It is often said that changing your X password signs out every other device. X does not publish a statement we can read either way: its help pages refuse automated requests, so we cannot check. What is on the record is that in September 2022 Twitter disclosed that voluntary password changes had not been ending sessions on other devices, a bug that had run for months before it was fixed. That history is reason enough not to lean on the side effect, whatever it does today.

The reliable action is a different one, and it is sitting in your settings: Security and account access, then Apps and sessions, then Sessions. There is a control that logs out every session except the one you are using. It is explicit, it is under your control, and its effect is not a matter of interpretation.

So do not treat a password change as a way of clearing other logins. Treat it as a password change, and clear the other logins yourself, on purpose, from the list built for it.

What actually breaks, and what does not

Two kinds of access hang off an X account and they behave differently, which is the single most useful distinction in this whole area.

Copied session values are cookies lifted out of a logged-in browser, which is what a lot of automation tools ask for. They are tied to a login session, so ending sessions ends them. Tools running on copied values usually do not report an error when this happens; they simply stop posting, and you find out the next day. If you have any, expect to redo them after a security change, and read what auth_token and ct0 actually do before you paste anything anywhere.

Authorised applications are different. An app you connected through the official authorisation flow holds a grant of its own that does not ride on your password or on any browser session, so it survives all of this. That cuts both ways and both ways are useful: you can change your password without stopping your automation, and you can cut off a single application without touching your password. It also means an authorisation somebody else granted before you owned the account will outlive everything you just did, so the connected apps list needs a manual pass.

That asymmetry is the real argument for using the official route for anything you intend to run for more than a week. Copied values are quick and they break on every security action you take. A proper authorisation takes longer once and then stops being your problem.

When the password change will not go through

Three different situations hide behind "it will not let me", and they need different responses.

It is accepted and does not take effect. Almost always a confirmation waiting in the inbox. Check spam, and allow a few minutes before trying again rather than resubmitting.

You get a challenge you cannot complete. The platform has scored your access as unusual. What helps is patience: the same connection, the same device, another attempt later. What does not help is switching to a different connection to get around it, because that makes the assessment worse rather than better.

The account is restricted or suspended. Then the password is a symptom rather than the problem, and the route back is a different one. That case is covered in our guide to restricted and suspended accounts.

Where tokens leak, which is more ordinary than people expect

A session value pasted somewhere is live access to the account until the session ends. It is not a technical string, it is a key. The routine ways they escape:

• Screen sharing with developer tools open during a support call
• Pasting the raw value into a chat, a ticket, or a shared document
• Storing it in a plain text file that syncs to cloud storage
• Browser extensions with permission to read page data
• Signed-in sessions left behind on a shared or resold machine

If you think one has escaped, go to the sessions list and end everything. That is the action with a known effect. Change the password too, by all means, but do not let it be the only thing you do.

Recovering when you have nothing left

If the address on the account was changed and you cannot receive anything, the ordinary routes are closed and the only one remaining is the platform's own contact form. What matters there is evidence that the account was yours: the previous email address, the phone number that used to be on it, roughly when it was created, old notification emails. Gather that before you fill in the form, because adding it afterwards is difficult.

The blunt part: there is no published processing time, no phone number, and no way to move it along. Services that promise a paid recovery are using the same form you are.

The only prevention that actually works is doing steps one through four above while you are still logged in. If you are choosing between listings, the ones that come with an inbox you can log into are on the X account listings page. The same password-last order applies to Facebook accounts and for the same reason.

X's own help pages are the first-party reference. We could not read them from here, so we are not going to characterise what is on them.