Changing your password stops a hacker who came in through the password. Nobody else. A live session keeps working. A stolen token keeps minting access. A recovery address the attacker added lets them walk straight back through the reset page. Malware on your machine watches you type the replacement and takes that too. So the password change helps in one case out of several, and most advice after a breach stops there, as if the job were done.
Picture the usual sequence. A login alert lands, and you open settings, pick something stronger, breathe out. Then the account moves again. That second movement is the clue. It tells you the password was never the way in.
The password is only one way in
You prove who you are once. The service then gives your browser or app a session token, a pass that says this device already passed the check. From that point the token speaks for you. The password sits idle. The reset flow is a separate entrance, keyed to a recovery email or phone number. Malware is a third, and it lives on your side of the screen, reading keystrokes as you make them.
Federal guidance treats passwords the same way. NIST SP 800-63B-4, the US federal authentication standard, says providers must not force changes on a calendar. They must force one when there is evidence the credential is compromised. New passwords go against a blocklist of known compromised ones. Password managers must be allowed. CISA's baseline asks for the same trio: long, random, unique passwords, one per account, held in a manager, plus multifactor authentication everywhere it exists and software kept current. NIST's digital identity guidelines place passwords inside a wider system of proofing, authentication and session handling. One part fixed. The rest untouched.
The question after a suspected break-in is not whether you changed the password. It is which entrance the attacker used, and whether that entrance is now shut.
Three ways in that a new password misses
Three routes survive a reset, and each needs its own fix.
Sessions and tokens that outlive the reset
A reset kills a password. Tokens are a different object, and a reset does not always kill them. Someone holding a live session cookie or a refresh token can carry on using the account without typing anything. Refresh tokens can run for days or months, minting fresh access tokens as old ones lapse. Session cookies can linger for weeks. Providers differ on whether a password change revokes them. Assume nothing.
So sign-out belongs beside the password change, not behind it. Google's unfamiliar-activity flow logs the account out on every other device when you flag activity as not yours, and asks for the password change after that, in that order. Microsoft's sign-out-everywhere control logs you out of browsers, apps and everywhere else the account runs, but it needs up to 24 hours and it skips an Xbox console. Other services carry their own version, usually under Security or Sessions. Find it. Use it. Third-party apps hold grants of their own, and a grant the attacker approved stays live until you revoke it, new password or not.
Malware sitting on your own machine
Malware flips the order. Change the password on an infected machine and you have just handed the watcher the replacement. They read it as you type, or they pocket the fresh session the moment you log in with it. Worse than useless. It leaves you thinking the account is safe while the watcher stays put.
Scan first, or change the password from a different, clean device. A change on an infected machine hands the attacker the new password.
The FTC's order for hacked email runs the other way: scan first with trusted security software, delete what it finds, restart, and only then change the password. No clean machine? Do the whole job from a different one, and treat the infected box as out of service until it is cleaned.
A recovery method the attacker added
The reset page is a second front door. An attacker who added their own recovery email or phone number can return through "forgot password" after your change, and can lock you out through the same route. Quiet persistence: nothing looks broken, the account looks clean, and their address waits in settings.
Google's hacked-account guide pairs the password change with a settings audit for this reason: change the password, then hunt down unfamiliar devices, switch on two-step verification, and strip out filters or forwarding rules you never made. Run the same audit anywhere. Open recovery settings and confirm every address and number is yours, then delete the rest. Locked out because the attacker replaced the recovery method? Go through the provider's account recovery, and expect it to drag, because the slowness is what keeps the attacker from using it too.
One address per site keeps a break-in small
All of that is one account. The wider failure is that one account opens the rest, because the same email address serves as the username and the reset destination everywhere. Whoever holds your inbox can reset passwords across your life, one reset email at a time. A new inbox password does not undo resets already run.
Aliases change the shape of the damage. AliasFleet gives each site its own forwarding address, so the address a site holds belongs to that site alone. One account falls, the fall stays in that account. Pause the alias that leaked. The rest of your mail carries on. How aliases work is a forwarding rule plus a reply trick plus a kill switch, and the kill switch does the work here. The setup guide takes about two minutes.
Two limits worth saying out loud. Aliases do not stop session theft, malware, or recovery takeover on an account already compromised. They do not make you anonymous. What they do is fence the damage in: a stolen alias is one site's address, not your identity, and pausing it costs nothing.
Reading the signs
You rarely watch the break-in happen. You read the traces it leaves.
| What you see | Likely route | What it means |
|---|---|---|
| A login from a device or place you do not know, and nothing else wrong | Password | The password was the way in. Change it, then hunt for reuse. |
| Activity carries on after the password change | Live session or token | The session survived. Sign out everywhere and revoke grants. |
| The replacement password gets compromised too, or logins you never made keep appearing | Malware | Something on the device is watching. Clean the machine first, then change again from a clean one. |
| You cannot get in, or the recovery email or phone is not yours | Recovery takeover | The attacker owns the reset flow. Use account recovery and rebuild the settings. |
| Mail vanishes, or rules and forwarding you never made show up | Mailbox rules | The attacker built persistence inside the mailbox. Remove the rules and the forwarding. |
| Your password turns up in breach data | Exposed credential | The password itself is already out there. Change it everywhere it was reused, and check it against Pwned Passwords, which checks breach data without seeing your password. |
No trace points anywhere? Run the checklist anyway, because silence proves nothing. A quiet attacker is usually the one who already set up persistence.
The full lockout, in order
Work through this in order, from a device you trust.
- Clean the machine. Run trusted security software, remove what it flags, restart. If there is no trusted machine, do everything below from a different, clean one.
- Change the password. Long, random, unique to this account, kept in a password manager. If the service checks new passwords against breach data, let it. A password already in a breach is not a new password.
- Sign out everywhere. Use the provider's sign-out or session control, and revoke third-party app access and grants you do not know. NIST SP 800-63B-4 treats authenticator invalidation on loss or theft as part of the authenticator lifecycle, the formal version of this step: a stolen credential stays stolen until you invalidate it.
- Rebuild recovery. Confirm the recovery email and phone are yours, strip out the rest, and add a second method you control if the service allows it.
- Audit the mailbox. Remove forwarding rules, filters, delegates and signature links you never made. Read sent mail for messages you never wrote.
- Switch on two-factor authentication. An authenticator app or a security key beats SMS where you get the choice. Microsoft's two-factor setup covers phone and authenticator-app verification, plus a passwordless option. Once it is on, a stolen password alone opens nothing.
- Change the password everywhere it was reused. Start with the accounts that lean on this inbox for resets: banking, email, social, shopping. A password used in two places is one password, not two.
- Check whether your address shows up in known breaches, and switch on breach notifications so the next one reaches you. Have I Been Pwned is safe to use, and its check is the fastest way to see what is already out there.
Change the password, then finish the job
A password change is the second step of eight. It closes the password route while sessions, malware, recovery and reuse stay open. The lockout is the checklist: clean machine, fresh unique password, sign-out everywhere, recovery rebuilt, mailbox audited, two-factor on, reused passwords changed, breaches checked. Run all of it and the attacker needs a new way in. Run half of it and you have swapped the lock while they still hold a spare key.
