Why changing a password may not finish an account takeover response

Changing a password is visible and satisfying. The old secret no longer works, the new one is unique, and the security page confirms the update. It feels like closing the door. Sometimes it is an essential part of containment. It is not a universal proof that every form of access has ended.

Accounts can involve credentials, sessions, application grants, recovery methods and devices. A response that changes one object without checking the others can leave important questions unanswered. The exact behavior varies by provider, so broad claims such as “a reset always signs everyone out” or “a reset never helps” are both poor guidance.

The useful model is an inventory: what gave access, what access still exists, what changed while it existed, and what must be verified before normal use resumes?

Five objects, five different questions

Add recovery methods and devices to that first set. Recovery information can provide a route back into the account. A compromised device can expose new credentials or sessions even after the account’s settings are repaired.

This table is an editorial organizing tool, not a command list. A personal email account and an enterprise identity system expose different controls. Use the relevant provider’s current recovery instructions and involve the responsible administrator for work accounts.

Why sessions exist in the first place

People do not type their password for every click. After authentication, a service uses session state or tokens to recognize subsequent activity. That is ordinary functionality, not inherently a vulnerability.

The security question is what happens when that state is stolen or remains active after an account event. Different applications have different lifetimes, checks and revocation mechanisms. A central identity provider and a connected application may not control exactly the same session object.

Microsoft’s access-revocation documentation distinguishes access tokens, refresh tokens and application sessions. It explains that the effectiveness and timing of revocation depend on how the application grants access, including sessions controlled by the application itself.

That is a concrete example of why recovery needs provider-specific knowledge. It is not a claim that every service behaves like Microsoft Entra or that all tokens survive every password reset.

A “sign out everywhere” control still has a scope

The label sounds absolute, but the provider’s documentation defines what the control actually does. Does it affect browser sessions, refresh tokens, mobile applications, external users or separately connected services? Is there a delay? Are additional actions required?

Microsoft’s revokeSignInSessions reference describes a particular operation, including its effect on refresh tokens and browser-session cookies, possible delay and limitations for external users. It is an administrative reference, not a universal recovery recipe.

For an ordinary user, the practical action is to use the official security controls and ask support what remains in scope. Do not copy administrative commands from unrelated environments or assume that a successful button press proves every downstream application has rechecked access.

A good incident record notes both the action taken and what was verified afterward.

Start with the event, not a favorite fix

What happened? A password was entered on a lookalike site, a code was approved, an application was granted access, software ran on a device, or unfamiliar activity appeared without a clear cause? Those starting points suggest different questions.

If you only know that a message was suspicious, do not invent a completed compromise. If you know credentials were exposed, do not minimize it because no damage is visible. Describe the observable action and time, then let the provider or security team evaluate the relevant access.

For example, a person who approved an unexpected consent request may need an application-grant review. A person who ran instructions from a fake verification page may need device assessment as well as account work. The same password reset does not answer both scenarios completely.

This is why an intake form should ask what the user did, not merely whether they “clicked.”

A recovery sequence with explicit checkpoints

Contain the access you can identify

Use official account-recovery and security channels. For a work account, contact the security or identity team promptly. They may need to restrict access, revoke sessions or take other controlled steps while preserving evidence.

Avoid making destructive changes to a managed device or account without the responsible team’s guidance. Deleting messages, reinstalling software or wiping a device can remove information needed to determine scope. Containment and evidence preservation should be coordinated.

Repair the account’s control points

Review authentication and recovery methods, connected applications, delegated access and other relevant settings. Look for changes that could permit return access or redirect information. The available controls depend on the service.

Do not assume that a familiar-looking entry is legitimate or that every unfamiliar entry is malicious. Record and verify with the account owner or administrator. Shared accounts and business integrations can have legitimate complexity.

Check what happened during access

The response may need to examine sent messages, changed payment instructions, file access, forwarding rules or other account-specific activity. The aim is to understand consequences, not merely restore your ability to log in.

If another person or organization could be affected, coordinate accurate notification through the responsible channels. Do not announce an attacker identity or data-loss scope before it is established.

The device can reopen the problem

If untrusted software is running on the device used for recovery, new credentials or sessions may be exposed again. That is why device context matters. A clean-looking desktop is not a reliable assessment.

Use trusted technical support and the provider’s guidance. For a managed endpoint, follow organizational instructions about isolation, scanning, collection and restoration. For a personal device, use reputable support rather than a service advertised by the suspicious message.

Do not treat reinstalling the operating system as a casual first step without considering backups, evidence and account recovery. It can be appropriate in some cases, but this article cannot decide that remotely.

Equally, do not assume that every suspicious login requires a full device rebuild. Match the response to the evidence.

Avoid the false finish line

A response ticket can close too early because one visible action is easy to measure. “Password changed” is a completed task. “Unauthorized access no longer available and relevant consequences assessed” is a broader outcome.

Define what evidence supports completion. Which sessions were revoked? Which grants were reviewed? Which recovery methods were confirmed? Was the device assessed where necessary? Were affected transactions or messages examined?

There may still be uncertainty. Document it instead of turning a checklist into a guarantee. A provider may not expose every log to a personal user, and an organization may need further investigation. Honest limits are better than a confident claim that the account is certainly clean.

The goal is a defensible recovery state, not a reassuring phrase.

For support teams: improve the first conversation

Ask specific, nonjudgmental questions. “Did you enter a password, approve a prompt, grant app access or run a file?” gives the user useful categories. “Why did you click?” adds blame without identifying the access path.

Record the source of each fact. A user’s recollection, a screenshot and a sign-in log can all be valuable, but they are different evidence. Do not present an assumption as a confirmed event in the handoff.

Provide the user with one clear next action and explain what not to do while waiting. Ambiguous silence can lead them to keep interacting with the attacker or attempt their own cleanup.

Our reporting-without-blame essay discusses how the first response affects whether people provide complete information.

A tabletop exercise for a small team

Take a fictional incident: an employee entered credentials, approved a prompt and later noticed an unfamiliar application. Ask the team to assign an owner to each object in the table above.

Who handles identity controls? Who checks application access? Who assesses the device? Who reviews possible business consequences? Who communicates with the user? If the same person owns everything, identify what help they need rather than assuming the work is automatic.

Then ask what evidence would allow each owner to say their part is complete. This exercise does not require a live attack, production changes or a simulated compromise. It tests whether the response process distinguishes the objects that matter.

The model to retain

A password reset can be necessary and effective within its scope. The mistake is treating it as a universal reversal of everything that happened before it.

Recover the account as a system of access relationships, not as a single secret. Use the provider’s documented controls, review the relevant objects, and verify the outcome appropriate to the incident.

Sources: Microsoft Entra emergency access-revocation guidance and Microsoft Graph revokeSignInSessions reference. The five-object model and tabletop exercise are editorial synthesis, not a substitute for an incident-response professional or provider-specific procedure.