Revoke Sessions First
Account takeover recovery often fails when people reset a password without removing existing login sessions. Many services keep a session alive using tokens stored in your browser or on the server, so the attacker can continue using the same session even after you change the password.
Session revocation forces the service to invalidate those tokens, which breaks active access paths. In practice, you want to revoke sessions tied to unknown devices before you change the password, then verify that only your devices remain logged in. This order matters because some systems treat password changes as separate from session validity, and some attackers also set up new sessions during the reset window.
If you suspect takeover, start with the security settings page that lists active sessions, logged-in devices, or “recent activity.” I’ve seen recovery flows where the password reset screen appears immediately, but the session list sits one menu deeper—users miss it because the reset button looks like the finish line.
Main Problems And Pain Points
People often assume a password reset ends all access. That assumption breaks when session tokens remain valid until they expire or are explicitly revoked. Services differ: some invalidate sessions on password change, others do not, and some invalidate only sessions that use the old password.
Another common mistake is changing the password first, then revoking sessions. If the attacker already has an active session, they may keep using it while you work, and they may even trigger additional changes such as adding a new recovery email or enabling a new authentication method. The attacker’s session can also be used to view account settings, which means the “reset” can become a moving target.
Session management depends on supporting technologies such as cookies, refresh tokens, and server-side session records. A browser cookie might store an access token, while a refresh token can mint new access tokens without re-entering a password. Some systems also use device fingerprints and risk scoring, which can keep a session active even when the user’s password changes.
Solutions And Advice
Step 1: Identify Active Sessions
Open the account’s security or privacy settings and locate a section labeled “Active Sessions,” “Logged-in Devices,” “Recent Sessions,” or “Where you’re signed in.” Record the device names, locations, and timestamps shown there. If the interface offers a “show details” option, use it; the details often include an approximate city or IP region, which helps you spot impossible logins.
When you see a device you do not recognize, treat it as attacker-controlled until proven otherwise. If the account uses multi-factor authentication, check whether the unknown session is associated with a recent MFA event. I once watched a recovery attempt stall because the user changed the password but never removed a session that was still listed as “signed in” two days later.
Step 2: Revoke Sessions Before Reset
Use the “Sign out of all devices” or “Revoke all sessions” control before changing the password. If the UI offers per-device revocation, remove the unknown devices first, then revoke the rest if you want a clean slate. After revocation, log out of any remaining sessions on your side and close the browser tabs that might still hold cookies.
Then perform the password reset. Choose a new password that is not reused from other sites, and avoid patterns that match prior passwords. If the service supports passkeys or authenticator apps, switch to those after the reset; SMS codes can be weaker against certain attack paths, though they still add friction.
Realistic outcome: after session revocation, the attacker’s active session should stop working at the next request. Some services show a “session expired” message, while others silently redirect to login. If you still see the unknown device listed after revocation, refresh the session list and repeat the revocation action; the UI sometimes updates with a delay.
Step 3: Lock Down Recovery Channels
Attackers frequently target recovery settings because they can regain access even after password changes. Check the recovery email address, phone number, and any “account recovery” options. Remove unknown destinations and confirm that the email or phone you control is the only one listed.
Review connected apps and API tokens if the service offers them. OAuth apps and “trusted devices” can retain access until revoked. In one incident pattern, the attacker added a third-party integration that kept pulling data after the password reset, which is why revoking sessions alone did not end access.
If the account supports alerts, enable login notifications and security change alerts. Set them to a channel you monitor closely, such as an email inbox you control.
Step 4: Verify With a Controlled Test
After you revoke sessions and reset the password, verify by signing in from a known clean environment. Use a private/incognito window or a different browser profile to confirm the account prompts for the new password and MFA. If the service allows it, check “recent activity” again and confirm the unknown session disappears or is marked as ended.
Also check whether any security settings changed during the incident window. Look for new MFA methods, new security keys, new trusted devices, or changes to notification preferences. If you see changes you did not make, treat the account as still compromised until you revert them and re-secure recovery channels.
Small aside: on some services, the session list refreshes only after a full page reload, not after a partial update. That can make it look like revocation failed when it actually succeeded.
Case Examples
Example 1: Email Account Takeover
An anonymized user noticed password reset emails they did not request. They changed the password immediately, then saw the attacker still listed under “Where you’re signed in” with a timestamp from the same hour. The user revoked all sessions first, then reset the password again and removed an unfamiliar recovery phone number. After revocation, the unknown device stopped appearing in the session list within the next refresh cycle, and login prompts required the new password plus MFA.
The lesson was procedural: the first password reset did not end the attacker’s active session, and the attacker used that session to adjust recovery settings. The user’s second pass succeeded because it broke the session before changing credentials and then corrected recovery channels.
Example 2: Banking Portal Login
An anonymized user received a notification about a new device signing in to a banking portal. They changed the password but did not revoke sessions because the UI labeled the option as “log out of other devices,” which they skipped. The attacker’s session continued to show as active for several hours, and the user later found a new “payee” draft created from the portal. After the user revoked sessions, removed the draft and reviewed recent activity, the attacker’s session stopped and no further changes appeared.
This example highlights a practical risk: even if the password changes, an attacker’s session can still perform actions until it expires or is revoked. The safest sequence reduces the time window for unauthorized actions.
Comparison Table And Checklist
| Action | What It Breaks | What It Might Not Break | When To Do It |
|---|---|---|---|
| Revoke Sessions | Active session tokens and “where you’re signed in” entries | Recovery settings changes already made by the attacker | Before password reset |
| Password Reset | Future logins that require the password | Existing sessions that remain valid until revoked or expired | After session revocation |
| Recovery Channel Review | Attacker’s ability to regain access via email/phone | Active sessions if you skip session revocation | After password reset, before you relax |
| Verification Login | Confirms the account requires new credentials and MFA | Past unauthorized actions already performed | After changes, using a clean browser profile |
Step-by-step checklist you can follow in order:
- Open security settings and capture the list of active sessions and devices.
- Revoke sessions for unknown devices, then revoke all sessions if the option exists.
- Reset the password to a new, unique value.
- Review recovery email, phone number, MFA methods, and connected apps.
- Sign in again from a clean browser profile and confirm the unknown session no longer appears.
- Check recent activity for actions you did not initiate, then reverse them if possible.
A small aside: if you use a password manager, verify it updated the stored password after the reset. Some users change the password but keep an old saved credential, then get locked out and blame the service.
Common Mistakes
Skipping session revocation is the most common error. Password resets can be necessary, but they often do not invalidate existing sessions, so the attacker can keep acting until the session expires or is revoked.
Another mistake is trusting the “password changed” confirmation without checking “recent activity” or the active session list. Some services show a successful password reset even when the attacker still has a valid session, which creates a false sense of closure.
Users also forget to check recovery channels. If an attacker changed the recovery email or phone number, the account can be re-taken even after you fix the password. This is why you should review recovery settings after you revoke sessions and reset the password.
People sometimes revoke sessions but leave unknown trusted devices or OAuth apps connected. Those connections can re-establish access without a password prompt. Revoke or remove them, then verify by signing in from a clean profile.
Finally, users may ignore local device hygiene. If the attacker used malware or a compromised browser profile, the account can be re-compromised after you finish recovery. A practical step is to scan the device with reputable endpoint protection and consider clearing suspicious browser extensions.
FAQ
Does Changing My Password Log Out Sessions?
Some services invalidate sessions on password change, but many do not. The reliable approach is to revoke sessions in the account’s security settings and then verify that unknown devices disappear from the active session list.
Where Do I Find “Revoke Sessions”?
Look in account settings under Security, Privacy, or “Where you’re signed in.” The wording varies by provider, but it usually appears near device management or session history.
Will Session Revocation Affect My Legitimate Devices?
It can. “Revoke all sessions” logs you out everywhere, so you may need to sign in again on phones, tablets, and desktop browsers. If the UI supports per-device revocation, remove unknown devices first.
How Long Do Attackers Keep Access After Revocation?
In many systems, access stops at the next request after tokens are invalidated. Some services update session lists with a delay, so you should verify by attempting a clean login and checking recent activity rather than relying only on the UI refresh.
What If I Can’t Access the Account Settings?
Use the service’s account recovery flow, then immediately review recovery email/phone and any MFA settings once access returns. If the attacker changed recovery channels, you may need to recover the email or phone account first.
Author's Insight
Session revocation is a security control that targets tokens and server-side session state, not just the password verifier. Password resets change one credential, while sessions can remain valid until they expire or are explicitly invalidated. That separation explains why the safest recovery sequence starts with revoking sessions, then resetting the password, then reviewing recovery channels and connected apps.
Because providers vary in how they handle session invalidation, readers should confirm outcomes by checking active sessions and recent activity after each step. A practical test is signing in from a clean browser profile and confirming MFA prompts occur as expected. If the account still shows unknown sessions after revocation, repeat the revocation action and escalate to the provider’s support channel.
On a side note, I’ve seen recovery instructions that mention password resets but omit session revocation; the omission creates a predictable failure mode when attackers keep an active session alive.
Key Takeaways
- Revoke active sessions before resetting the password to stop attacker-controlled sessions.
- Reset the password afterward, then review recovery email/phone, MFA methods, and connected apps.
- Verify using a clean browser profile and check recent activity for unauthorized actions.
- If unknown sessions persist, repeat revocation and escalate to the service’s support.
