After a Credential Breach: What to Reset, and in What Order

A credential compromise is discovered and the instinct is to reset the affected password immediately. That is rarely the right first action, and doing it in the wrong order routinely leaves the attacker in place while alerting them that they have been noticed.

Scope before you act

Resetting one password tells the attacker they are detected and prompts them to use whatever other access they hold. So establish scope first, quickly but deliberately: which accounts, which systems, how long, and what else the attacker obtained.

Look for what usually accompanies credential theft — additional accounts created, multi-factor methods registered by the attacker, mail forwarding rules, application consents granted, API tokens issued, SSH keys added, and certificates enrolled. Each is independent of the password and survives resetting it.

The attacker-registered MFA method is the one most often missed. A password reset on an account where the attacker controls a second factor hands the account straight back to them.

Sessions and tokens outrank passwords

The point that matters most. Authentication already happened; an active session or a valid token does not care that the password changed.

So the reset sequence has to include invalidating sessions and revoking tokens alongside the password change, and on most platforms these are separate actions. Refresh tokens are particularly durable and frequently long-lived, which is why a compromised endpoint requires session revocation rather than only a password reset — the bearer problem described under session hijacking.

Where an infostealer is suspected, assume every credential and cookie on that endpoint is gone, including personal ones the user had stored in a browser.

A workable order

1. Contain, coordinated. Where possible, act on everything at once rather than sequentially, so the attacker does not get warning and time to re-establish. Isolate the compromised endpoint if there is one.

2. Remove attacker-added access. Rogue MFA methods, added keys and certificates, mail rules, OAuth consents, and any accounts created. Do this before the password reset, or you reset into an account the attacker still controls.

3. Reset the credential and revoke sessions and tokens together.

4. Work outward. Any credential the compromised account could reach, any service account whose password was stored on the affected system, any shared credential the user knew. Where a privileged account was involved, the blast radius is the whole tier — the reasoning behind tiering under privileged access management.

5. The special cases. If a domain's Kerberos service account was exposed, its password must be reset twice to invalidate outstanding tickets, and that is disruptive enough to need planning. If certificates were enrolled, revoke them. If signing or API keys were exposed, rotate them with the overlap handling described under key rotation.

6. Force reuse checks. People reuse passwords, so a compromised credential may work elsewhere entirely. Screen against the breached value across the estate.

What to tell users

A forced reset with no explanation produces helpdesk volume and suspicion, and a vague "security incident" email is indistinguishable from phishing — which attackers exploit by sending their own version alongside yours.

Say what happened, what the user needs to do, how to verify the message is genuine, and what the organization has already done. Never include a link in a reset notification, since that trains exactly the behaviour you spend the rest of the year discouraging.

Notification obligations

Where personal data was exposed, regulatory clocks start at detection rather than at conclusion of the investigation, and several regimes require notification within short fixed windows. Contractual obligations to customers frequently have their own, shorter deadlines.

The practical consequence is that legal and communications need to be engaged early, in parallel with the technical work, rather than after it — which is why those triggers belong in the incident response playbook with the deadlines stated in hours.

Afterwards

Determine how the credential was obtained, because resetting without fixing the cause invites a repeat. Phishing, an infostealer on an endpoint, reuse from an external breach, and an exposed service each need a different follow-up.

Then close the structural gap the incident revealed. If the account lacked phishing-resistant authentication, that is the finding — FIDO2 and passkeys make a stolen password insufficient, and a reset programme that does not change the authentication model simply schedules the next incident.

Exam angles

Know that credential compromise response requires invalidating sessions and revoking tokens as well as resetting passwords, because existing authentication survives a password change. Recognize attacker-registered MFA methods, mail forwarding rules, OAuth consents and added keys as persistence independent of the password, to be removed before the reset. Know that coordinated simultaneous action avoids warning the attacker, and that notification clocks typically start at detection.