Why changing your password does not log the attacker out

What does an attacker actually take?

Two different things, and only one of them is a password. The first is the store of saved logins in your browser. The second is the cookie file, which holds the small tokens that prove to each site that this browser has already signed in. The second one is worth more, because it skips the login screen entirely.

The FBI's Atlanta field office put out a public warning about exactly this in late 2024. Its description is worth repeating because it is plain. A "remember me" cookie is tied to your login and often lasts 30 days. If a criminal obtains that cookie from a recent sign-in to your web mail, they can sign in as you without your username, your password or your multi-factor authentication. The bureau named Gmail, Outlook, Yahoo and AOL as the targets it was seeing.

The software that collects this is called an infostealer. It is ordinary malware with an unglamorous job: copy the browser profile, compress it, send it somewhere. Google's security team is blunt about how hard that is to stop. There is no reliable way to prevent cookie exfiltration using software alone, because malware running as you can read the same files your browser reads. Verizon's 2026 Data Breach Investigations Report, which looks at business incidents rather than home users, found that 54 per cent of the devices listed by access brokers had at least one infostealer installed on them.

Why does the session survive a new password?

Because the password and the session are checked at different moments. The password answers the question "is this really you" once. The session cookie answers the question "have you already been let in" on every request after that. Cancelling the first does not automatically cancel the second. The service has to go and invalidate the session record on its own servers, and that is a separate operation that some providers run automatically and others leave to you.

This is also why a second factor is no help here. The code or the tap on your phone happens during sign-in. An attacker replaying your cookie is not signing in. From the server's point of view they are already inside, holding a valid ticket that was issued after all the checks passed.

Which accounts log the others out, and which do not?

There is no common behaviour. Google ends other sessions for you and names the exceptions. Apple asks you to decide during the password change. Microsoft, Netflix and Meta keep the two actions apart, so a new password on its own leaves the other sessions running.

Table scrolls sideways.

Three of those entries deserve a sentence more. Google's help page says you will be signed out everywhere except devices you use to verify that it is you, some devices with third-party apps you have given account access, and helpful home devices you have given account access. There is no single button to end everything at once, so you work down the device list and sign each one out.

Microsoft hides the control under Advanced security options and warns that signing out may take up to 24 hours to reach every browser, app and service. An Xbox console is excluded and has to be handled on the console itself. That delay matters if you are racing someone.

Apple is the clearest of the group. Change your password on an iPhone, iPad, Apple Watch or Vision Pro and it offers two buttons: Remove Other Devices, which forces everything else to sign in again, or Keep All Devices Signed In. Most people tap the second one without reading it. Removing a device also stops it showing two-factor verification codes, which is the point if somebody else is holding it.

What order should you do this in?

Clean the machine first, then change the password, then end the sessions. Doing it the other way round wastes the effort, because a computer that is still infected simply captures the new password and the new cookie a minute later.

1. Deal with the suspect device. If a computer or phone may be carrying the malware, do not use it for any of the following steps. Use another device you have reason to trust.
2. Change the password on the email account first. Mail is the reset route for everything else, so it comes before the bank, the shopping accounts and the social ones.
3. End every other session, on each account. Use the table above. This is the step people skip, and it is the only one that touches the stolen cookie.
4. Revoke third-party apps. An app you once connected holds its own long-lived access, which survives both a password change and a device sign-out. On a Google Account the list is under Security, in the section for your connections to third-party apps and services. Removing access stops future access, but it does not reach across and delete whatever the app already copied.
5. Check what was quietly changed. Look at the recovery email address, the recovery phone number, the registered second factors and any mail forwarding or filter rules. An intruder who expects to be thrown out leaves a way back in, and a forwarding rule is the cheapest one.

Each of these takes a minute or two. The whole sequence on a main email account is about ten minutes.

What does signing out everywhere still not fix?

It ends the sessions and nothing else. Anything already read or copied stays copied. Every password that was saved in that browser should be treated as known to somebody else, which means changing them rather than trusting that the sign-out covered it. Documents, messages and photos that were downloaded during the intrusion are gone in the sense that matters.

There are three more gaps worth knowing. Sign-out controls are usually per account, so each service needs its own visit. Some providers apply the revocation slowly, as Microsoft's own 24-hour caveat admits. And on a device that is still compromised, none of it holds for longer than your next sign-in.

This is also a different question from who is allowed to trade your data. Signing out of a shopping site does not stop that company sharing what it holds about you. That is the job of the browser setting that tells sites not to sell or share your data, which is a separate control with separate rules behind it.

Is anything being built so you do not have to notice?

Yes, and it started shipping this year. The approach is called Device Bound Session Credentials. Instead of a cookie that works in any browser that holds it, the browser generates a private key that lives in the computer's security chip and cannot be exported. The site then issues only short-lived cookies, and it refuses to renew them unless the browser can prove it still has the key. A copied cookie expires in minutes and cannot be refreshed, because the key never left the original machine.

Chrome 146 shipped it in general availability on Windows in April 2026, which ended the trial phase. It needs a Trusted Platform Module, the security chip present in Windows 11 and in most Windows 10 machines from the last few years. Google turned it on by default for Workspace accounts in a gradual rollout that began on 25 May 2026, with no administrator switch and no user setting. Support for macOS, using the Secure Enclave, is announced for a later release.

It is not a Google-only idea. The Web Application Security Working Group published the first public working draft of the specification on 21 August 2025, so other browsers and other sites can implement the same protocol. Two caveats are fair. A website has to do work at its end before any of this applies to your account there, so coverage will arrive one service at a time. And it protects the session, not the sign-in: a convincing phishing page that captures the password and the code at the moment you type them is a different attack, and this does not touch it.

Until that is everywhere, the sign-out button is the control you actually have. It is worth knowing where it lives on your main email account before the day you need it.

Sources

1. Cybercriminals are stealing cookies to bypass multifactor authentication, FBI Atlanta field office, on remember-me cookies and the 30-day figure
2. Hackers could take over your email account by stealing cookies, even if you have MFA, Malwarebytes, 5 November 2024, reporting the same alert
3. Protecting cookies with Device Bound Session Credentials, Google Security Blog, on why software alone cannot stop cookie theft
4. To counter cookie theft, Chrome ships device-bound session credentials, Help Net Security, 10 April 2026, for Chrome 146 and the hardware requirement
5. Prevent account takeovers with Device Bound Session Credentials, Google Workspace Updates, 28 May 2026, for the rollout from 25 May 2026
6. First public working draft: Device Bound Session Credentials, W3C, 21 August 2025
7. webappsec-dbsc, the specification repository of the Web Application Security Working Group
8. Change or reset your password, Google Account Help, for the three exceptions to being signed out
9. See devices with account access, Google Account Help, for the Manage all devices path
10. Third-party apps and services with access to your account, Google Account Help
11. How to sign out of your Microsoft account everywhere, Microsoft Support, for the 24-hour delay and the Xbox exception
12. Change your Apple Account password, Apple Support, for Remove Other Devices and Keep All Devices Signed In
13. Review devices signed in to your Apple Account, Apple Support, for Remove from Account and what it stops
14. Settings you can manage across your accounts in an Accounts Centre, Meta Help Centre, for Where you're logged in
15. Change your password, Facebook Help Centre, which does not mention other devices
16. How to sign out of a device, Netflix Help Centre, for Sign Out of All Devices
17. How to stop someone from using your account, Netflix Help Centre, which lists the password change and the sign-out as two steps
18. What the Verizon DBIR tells us about breaches in 2026, Push Security, for the 54 per cent figure from the 2026 Data Breach Investigations Report