The first hour of a hacked account is an ordering problem

Search for what to do when an account is hacked and you will get the same six actions on every page. Change your password. Turn on two-factor. Check your recovery options. Sign out other devices. Review connected apps. Tell your contacts.

All six are correct. Almost none of those pages put them in an order, and the order is the entire thing. Done in the wrong sequence, at least two of those actions undo each other, and one of them can hand the account to the person you are trying to remove.

I run support here, which means I read the mail that arrives while this is happening to someone. The pattern is consistent enough to be depressing: the person did not do nothing. They did the right six things, in the order they appeared on the page they found, and lost the account anyway.

Changing the password can be the wrong first move

This is the one that costs people the account, so it goes first.

The instinct is obvious — someone is in, lock the door. But a password is not the only door. Every provider has a recovery path, and the recovery path outranks the password by design, because it exists precisely for the case where you no longer know it.

So if the attacker has already added their own recovery email or phone number — which is the first thing a competent one does, usually within a minute of getting in — then your password change does not lock them out. It notifies them. They run a reset, the code goes to the address they added, and now they have the current password and you do not.

Check and revert the recovery contacts first. Then change the password. On Google, Microsoft and Apple that is two screens, and taking them in the wrong order is the difference between recovering the account and losing it.

A new password does not sign anyone out

The second ordering trap, and the one that makes people think they fixed something.

On most providers, changing a password does not invalidate existing sessions. The attacker's browser stays signed in. Their session token was issued before your change and nothing about your change revokes it. They keep reading your mail while you feel better.

Signing out other devices is a separate control — "sign out of all sessions", "where you're logged in", "active sessions", depending on the provider — and it has to come after the password change. Revoke sessions first and the attacker simply signs back in with the password they still have. Revoke after, and the old password is dead and so is the live session.

Password, then sessions. One order works.

Fix your email before your bank

When both are compromised, or when you are not sure which, people go for the account with money in it. I understand the reflex completely and it is still the wrong one.

Your email is the reset path for every other account you own. Someone holding your inbox does not need your banking password — they can request a new one, and the code arrives where they are already sitting. Securing the bank account while the attacker holds the inbox buys you the time it takes them to click "forgot password".

Email first. Then the accounts that reset to that email, in order of what they can cost you.

The exception is money that has already moved, which is a different clock and it runs faster than any checklist. In India, report at cybercrime.gov.in and call 1930, the national cyber-fraud helpline, before working through anything else. That is what gives a bank a window to freeze a transfer, and the window is measured in hours, not days. Elsewhere, call the number on the back of the card, not one you searched for.

The step almost nobody does

Here is the one that decides whether this is over in an hour or quietly continues for six months.

After the password change, look at what was left behind. A password change revokes a password. It does not revoke:

• Mail forwarding addresses. A silent forward on your inbox copies everything to the attacker forever, and it is invisible unless you open the settings page that contains it.
• Inbox rules and filters. The common one matches OTP, code, invoice or the name of a bank, and either forwards it or sends it straight to trash so you never see the alert about what is happening.
• Connected apps — OAuth grants. Every "sign in with" and every third-party app you ever approved carries its own access token. That token was issued independently of your password and it does not care that you changed it.
• App passwords. If you ever generated one for a mail client or a device, it is a separate credential that survives the reset.

Every one of those is persistence, and none of them appears on the six-item lists. This is how a takeover that everybody believes was dealt with in March is still reading mail in September.

Walk all four, every time, in that order, after the password is changed and the sessions are revoked.

When the thing taken is the phone number

SIM swap deserves its own paragraph because the standard checklist is actively wrong for it.

If your SIM has stopped working or your number now answers on someone else's device, the recovery channel itself is what the attacker holds. Every "we'll text you a code" step in the normal sequence now sends the code to them. Nothing in the usual list works, and following it makes things worse.

The order here is different: call your carrier from another line and get the number reissued — that is the first move, not the fifth — then go to the accounts that were using SMS for recovery and move them onto an authenticator app or a passkey, not onto a different phone number. Until the number is back, treat SMS as hostile infrastructure.

What I would want someone to do, right now

If this is happening to you while you are reading, do not work from this page. Open the triage checklist. It asks two questions — what kind of account it is, and what you can still reach — and gives you the ordered list for that exact situation, because the order for a SIM swap is not the order for a work account and neither is the order for Instagram.

It has no text box anywhere, so there is nothing to upload even in principle. No account, no server, nothing saved. Close the tab and it is gone.

Three things it will not do, which I would rather say here than have you find out mid-panic:

It cannot get an account back that is already fully gone. Once the password and the recovery contacts are both changed, you are in the provider's account recovery process, and that is their timeline, not yours — days, sometimes weeks, sometimes never. The checklist is there to keep you out of that state, and it is much better at prevention than at rescue.

It does not cover the organisation case properly. If this is a work account on Google Workspace, Microsoft 365 or Okta, your IT or security team can revoke sessions centrally and see audit logs you cannot. Tell them before you start changing things — your cleanup can destroy the evidence they need.

And it assumes you still have one safe device. If the machine you are typing on is the one that was compromised, every password you change from it is a password the attacker now has. Use a different device.

Afterwards

When the account is back and the persistence is swept, there is one more decision, and it is the only part of this that stops it recurring: do not put a new password in the same place the old one was.

Passkeys, where they are offered, remove the thing that got taken — there is no longer a secret sitting on a server waiting to leak. Where they are not offered, an authenticator app beats SMS, and a password manager beats reuse, because reuse is what turns one breach into five.

And it is worth knowing how the credential got out in the first place, because that changes what else is exposed. Checking whether your address is in a known breach is fifteen minutes and it usually answers the question.