What to do if your business passwords are compromised

It usually arrives as something small. A monitoring alert saying an employee’s work address showed up in a breach dump. A client asking why they got an invoice with different bank details. A staff member mentioning that they got a multi-factor prompt they did not request, tapped approve because they were busy, and then thought better of it an hour later. None of these look like an emergency at the moment they happen, which is exactly why the average credential compromise sits undiscovered for weeks.

The instinct when you do notice is to reset the password, and that instinct is right but incomplete. A password reset closes the front door. It does nothing about the session that is already inside, the forwarding rule that has been quietly copying your invoices for a month, the second authenticator the attacker registered under their own control, or the twelve other accounts that use the same password. Businesses that respond by resetting passwords and nothing else are frequently compromised again within days, using access that never went away.

This article covers how to tell what kind of compromise you are dealing with, what to do in the first twenty four hours and in what order, the specific list of things that survive a password reset and have to be removed separately, how to work out which accounts are affected, how long your evidence lasts before it expires, and when a credential compromise crosses into territory where you have reporting obligations. It assumes a business of roughly 20 to 50 people running Microsoft 365 or Google Workspace, with or without a password manager already in place.

If files are encrypted and there is a ransom note, you are past this article. Go straight to what to do after a ransomware attack and call your incident response contact.

Short answer

Work out which of three situations you are in, because they have very different blast radiuses: a credential appeared in someone else’s breach with no sign it has been used, a specific account of yours is being actively misused, or a machine was infected by credential-stealing malware and everything on it should be assumed gone. Then, in order: preserve the logs before you change anything, revoke active sessions rather than only resetting the password, remove the persistence an attacker leaves behind (mailbox rules, forwarding, OAuth app grants, added authenticator methods, app passwords, mailbox delegation, changed recovery addresses), fix the recovery paths before rotating passwords, and rotate in blast radius order starting with email and anything that can reset other accounts. Notify your cyber insurer early, because that clock is usually the shortest one you are running against, and talk to counsel about notification obligations before you finish cleaning up, because remediation destroys the evidence that the analysis depends on.

Password compromise at a glance

Question	Short version
Is a password reset enough?	No. It closes the login, not the session, and not the persistence.
What is the first thing to do?	Pull and preserve the logs. Remediation overwrites the evidence.
Why revoke sessions?	A live session token is an authentication that already passed MFA.
How do I find affected accounts?	Password reuse is the spread mechanism. Your vault knows; memory does not.
Which account first?	Email. Every other password reset in your business flows through it.
Do I have to change every password?	No. Rotate by blast radius, not alphabetically.
How long do I have to investigate?	Less than you think. Sign-in log retention can be as short as 7 days.
When do I tell my insurer?	Immediately. Policies commonly require notice within 24 to 72 hours.
Is this a reportable breach?	Sometimes. It depends on the data reachable, not just on the password.
Who decides that?	Your counsel, not your IT provider and not this article.

First, work out which kind of compromise this is

The response is not one size fits all, and the fastest way to waste a day is to run a full incident on a low-severity exposure or, much worse, to treat a live intrusion as a routine password change. Three situations, in increasing order of severity.

Exposure. A credential of yours appeared in a breach of somebody else’s service. This is the most common by far and the one you will usually learn about from a monitoring alert or your password manager’s breach report. The account being reported is often a third-party service that barely matters. The risk is not that service, it is that the password was reused somewhere that does matter, and that the email address is now on a list attackers work through systematically. There is no evidence of misuse in your environment yet, and the response is contained: rotate anything sharing that password, verify MFA, watch the logs.

Account takeover. One of your accounts is being used by someone who is not the owner. Signs include sign-ins from unfamiliar locations or unrecognized clients, an MFA prompt nobody requested, mail that has been read or deleted without explanation, replies missing from a thread the customer swears they answered, or a payment instruction the recipient did not send. This is an active incident and the persistence checklist further down is the core of your response.

Endpoint compromise. A machine got hit with an infostealer. The response is categorically different because you cannot triage credential by credential. That malware class takes the entire browser credential store, the session cookies, and any credential files it finds within seconds of landing, so the correct assumption is that every credential ever entered or saved on that device is in someone else’s hands, including the ones for systems you retired. This is the scenario browser-saved passwords exist to worry you about, and it means rebuilding the machine as well as rotating credentials.

The types nest. An endpoint compromise contains account takeovers, which contain exposures. When you are not sure which one you have, respond to the more severe one until the logs say otherwise. Being wrong in that direction costs a day of work; being wrong in the other direction costs the incident.

The first 24 hours, in order

Sequencing matters more than speed here, and several of these steps are useless or actively counterproductive if done out of order.

When	What you do	Why it belongs here
Minute 0 to 30	Export the sign-in and audit logs for the affected accounts, and note the time you first became aware	Everything after this changes the environment. Retention windows are short and evidence does not come back
Minute 30 to 60	Notify your cyber insurer and your IT provider or incident contact	Insurer notice windows are contractual, tight, and easy to blow while you are busy fixing things
Hour 1	Reset the password and revoke all active sessions in the same action	The reset alone leaves live tokens working. The two steps are one step
Hour 1 to 2	Remove attacker persistence: inbox rules, forwarding, OAuth grants, extra MFA methods, app passwords, delegations	This is the part that determines whether they come back tomorrow
Hour 2 to 4	Fix recovery paths: recovery email, recovery phone, security questions, backup codes	Rotating a password while the recovery address is attacker controlled achieves nothing
Hour 4 to 12	Identify reuse and rotate the accounts that share that password, email and registrar and finance first	Reuse is how one compromise becomes six
Hour 12 to 24	Read the audit trail: what was accessed, what was sent, what was downloaded, what rules existed and when they were created	This is the input to the notification decision, and it is a different question from containment
Day 2 onward	Rebuild any infected endpoint, review conditional access and MFA strength, close the gap that allowed it	Cleaning the account without closing the route means doing this again

Two notes on that table. Log preservation comes before remediation for the same reason you photograph an accident before moving the cars, and it is the step people skip because it feels like it is delaying the fix. It is delaying the fix by about fifteen minutes. Insurer notification sits at the top because it is the only item on the list with a contractual deadline attached, and because most policies route you to a panel incident response firm at pre-negotiated rates, which is a better outcome than finding one yourself at 9pm.

Why a password reset does not evict the attacker

This is the part most businesses get wrong, and it is worth being specific rather than general. Here is what remains fully functional after you have changed the password and told everyone the problem is handled.

Active session tokens. When someone signs in successfully, the service issues a token and stops asking. That token represents an authentication that already happened, including the multi-factor step. Resetting the password does not invalidate it in most platforms unless you explicitly revoke sessions. In Microsoft 365 that is a separate revoke sign-in sessions action in the admin center, or Revoke-MgUserSignInSession in PowerShell. In Google Workspace it is the sign out of all sessions option on the user record. Do it as part of the same action as the reset, every time, without deciding whether it is necessary.

OAuth application grants. Modern account takeovers frequently end with the attacker consenting to an application on the user’s behalf. That application holds its own long-lived token and keeps its access after the password changes and after sessions are revoked, because it is not using the password at all. Review the enterprise applications and third-party access on the account and remove anything the user cannot account for. This one is the most commonly missed and the most commonly used for quiet re-entry.

Additional MFA methods. If the attacker got in far enough to register their own authenticator app or phone number as a second factor, they now satisfy your MFA with a device you do not know about, and a password reset hands them the new password through your own reset flow. Enumerate the registered authentication methods on the account and remove any that the user does not recognize.

App passwords and legacy authentication. App passwords are not revoked automatically when the account password changes. If any exist, delete them all and reissue only the ones that turn out to be needed. Legacy authentication protocols that bypass modern controls deserve the same treatment.

Inbox rules and forwarding. This is the signature of business email compromise and it is deliberately boring so nobody notices. A rule that moves messages containing the words invoice, payment, wire, or the attacker’s own domain into a rarely opened folder or straight to deleted items, so the real conversation is invisible to the account owner while the attacker replies from the outside. Sometimes a straight forward to an external address instead. Check both the inbox rules and the mailbox-level forwarding settings, because they are different places and a business can have one without the other.

Mailbox delegation and send-as rights. Access granted to another mailbox, including one the attacker created, survives the password change on the original account entirely.

Changed recovery details. If the recovery email or phone was swapped, the attacker can walk back in through the front door using your own account recovery process, and you will have no idea it happened.

API keys, tokens, and integrations created during the intrusion. Anything generated while they had access keeps working on its own credential.

Registered or joined devices. A device enrolled during the intrusion may retain trust that outlives the password.

Nine items, and only the first one is intuitive. The practical version is this: a password reset is a single step in the middle of the response, and treating it as the whole response is the single most common reason a business gets compromised twice through the same account.

How to work out which accounts are affected

Password reuse is what turns one compromised credential into an incident, and this is where having a password manager changes the response from guesswork into a query.

If you have a vault, ask it. Every business password manager reports reused passwords across the account and flags credentials that appear in known breaches. Search the compromised password directly and you get the definitive list of everywhere it was used, in seconds, without anyone having to remember anything. This is the moment that justifies the tool, and it is worth saying out loud to whoever approved the spend.

If you do not have a vault, reason it out. Ask the user directly and specifically, because the honest answer is usually a short list of variations rather than a single string. Then work outward from the reset chain: start with the email account, because whoever controls it can reset almost everything else, then the domain registrar and DNS, then banking and payroll and payment processing, then the identity provider itself, then any system holding customer data. Assume reuse rather than asking whether it happened, because a busy person reconstructing their own password habits from memory is an unreliable source, not a dishonest one.

Check what the breach actually contained. If this came from an exposure alert, the report usually tells you which service was breached, when, and what data classes were involved. A breach that exposed hashed passwords, an address, and a username is a different problem from one that exposed plaintext passwords and security question answers. Running a proper password audit covers the tooling for this, including the domain-wide breach search, and doing it once during an incident is a strong argument for doing it on a schedule afterwards.

Widen the scope to shared logins. Any shared credential the affected person had access to is now compromised regardless of whether it was reused, because you cannot rule out that they stored it somewhere the attacker reached. The same applies to service accounts whose credentials were documented anywhere that user could see, with the standing caveat that rotating those without understanding them first breaks production.

Your evidence expires sooner than you think

The reason to pull logs in the first half hour is not procedural tidiness. It is that the default retention on the systems you are investigating is genuinely short, and credential compromises are typically discovered long after they started.

Microsoft Entra ID sign-in logs are retained for 7 days on the free tier and 30 days with Entra ID P1 or P2, which most Microsoft 365 Business Premium customers have. The Microsoft 365 unified audit log, which is where mailbox and file activity lives, keeps Audit Standard records for 180 days by default for logs generated since October 2023, with a year available for certain workloads under E5. Google Workspace retains most audit logs, including login and admin activity, for about six months, and you cannot extend that from the Admin console.

Put those numbers next to the reality that a compromised mailbox is often quietly monitored for weeks before anything visible happens, and the problem is obvious. By the time an invoice fraud attempt surfaces the intrusion, the sign-ins that started it may already be outside the window, especially on the free tier. That gap is the difference between an investigation that can say what happened and one that can only say what is happening now, and the second one is a much weaker position when a client, an insurer, or a regulator asks what data was accessed.

Two practical conclusions. Export first, ask questions second, because an export is cheap and irreversible loss is not. And if you have never checked which retention tier you are actually on, do that this week rather than during an incident. Longer retention is generally a licensing or a log-forwarding decision, and it is one of the few security investments whose value is entirely invisible until the day you need it, at which point it is the whole ballgame.

Rotate in blast radius order

Once containment is done, rotation is a work list rather than an emergency. Do not work alphabetically or by whatever is in front of you. Order it by how much an attacker gains from each credential.

Email first, always, because it is the master key that resets everything else. Then the domain registrar and DNS, because control of those means control of your email and your website regardless of what else you fix. Then anything that moves money: banking, payroll, payment processing, accounts payable systems. Then the identity provider and the password manager admin account themselves. Then remote access and VPN. Then customer data systems. Then everything else, in whatever order is convenient.

And keep the ordering rule from the offboarding case, because it applies identically here: fix the recovery paths before you rotate the password. If the recovery email on an account is still pointing somewhere the attacker controls, a new password is a speed bump. That principle, along with the rest of the credential surface a departure leaves behind, is covered in what happens to your passwords when an employee leaves, and a compromise is the same problem arriving through a different door.

While you are in each account, turn MFA on if it is not already, and prefer an authenticator app or a hardware key over SMS. If the compromise involved an approved push prompt that the user did not initiate, move that account to number matching or a phishing-resistant method, because MFA and passwords are two layers that fail in different ways and this particular failure has a specific fix.

When a credential compromise becomes a reportable breach

This section is orientation, not legal advice, and the single most useful thing in it is the recommendation to involve counsel earlier than feels necessary. Notification analysis is a legal determination, it varies by state and by industry, and it is not a decision for your IT provider to make on your behalf.

What is worth understanding before that conversation:

The trigger is usually access to data, not theft of a password. Every state has a data breach notification law, and they generally turn on unauthorized access to or acquisition of personal information about residents of that state. A compromised password for a system that holds no personal data is an IT incident. A compromised mailbox containing customer records is a different conversation, because the mailbox is the data. This surprises people who think of email as messages rather than as a data store, and it is the most common way a small credential problem becomes a reportable one.

The burden often runs the wrong way. Several frameworks presume a breach unless you can demonstrate otherwise. Under HIPAA, an impermissible use or disclosure of protected health information is presumed to be a breach unless a risk assessment shows a low probability that the information was compromised, with a 60-day outer limit for notification to affected individuals. Not being able to prove what an attacker did is not the same as proving they did nothing, which is precisely why the log preservation step sits at the top of the timeline and why remediating before you have exported anything is a costly kind of tidy. If you handle protected health information, HIPAA cybersecurity requirements covers the surrounding obligations.

International data has its own clock. If you hold personal data on people in the EU or UK, GDPR requires notification to the supervisory authority within 72 hours of becoming aware where there is a risk to individuals. Other jurisdictions have their own rules and their own definitions, which is another reason this is a counsel question rather than a checklist item. The broader landscape is covered in AI and data privacy laws, which deals with the same statutes from a different angle.

Your insurance policy is the tightest deadline you have. It is also contractual rather than statutory, which makes it the one nobody thinks of as a deadline. Policies commonly require notice within a defined window after discovery, often 24 to 72 hours, and missing it can jeopardize coverage on a claim you would otherwise have. Call the hotline before you are certain it is serious, because an early call that turns out to be nothing costs you a phone call, while a late call on a real incident can cost you the claim. Cyber insurance for small business covers what those policies do and do not include, and how much a data breach costs a small business covers the numbers on the other side of that decision.

Contracts can oblige you independently of law. Client agreements, particularly with larger customers or in regulated supply chains, often contain their own notification clauses with shorter windows than any statute. Check the contract, not just the statute.

The honest summary: most credential compromises at small businesses do not become reportable breaches, and the ones that do are usually mailbox compromises where personal data was reachable. Assuming it is not reportable without looking is a bad habit, and so is announcing a breach before anyone has determined that one occurred.

Telling people

Staff, immediately and plainly. Tell them what happened, what you are doing, and what you need from them, which is usually to expect password resets and to report anything odd rather than assume someone else has. Add one specific warning that is easy to forget: attackers follow up. A wave of legitimate password reset emails is exactly the cover a phishing attempt wants, so tell people the resets are coming, tell them how they will arrive, and tell them you will never ask for a password or a code by phone or chat. That sentence prevents a second incident on top of the first.

Do not blame the person who reported it. Whoever clicked the thing or approved the prompt is also the reason you found out. Handle it as an incident rather than a personnel matter or you will find out about the next one considerably later, which is the same reason a password policy should say explicitly that reporting a mistake promptly is the expected behavior rather than a punishable one.

Clients and vendors, when they are affected. If a compromised mailbox was used to email your customers, they need to know quickly and specifically, particularly if payment instructions were involved. A short, factual, non-defensive message on the day beats a polished one next week. Say what happened, what to distrust, and how to verify a payment instruction going forward. If money moved, that becomes a fraud response as well as a security one, and it should involve your bank immediately.

Everyone else, on counsel’s advice. Formal notification wording, timing, and audience are legal decisions. Draft nothing publicly until that determination is made.

How to stop it happening again

The corrective work is short and it is the same list every time, which is a useful thing to notice.

Get every credential into a business password manager so that the next time this happens, the question of which accounts are affected takes thirty seconds instead of two days. If you have not chosen one, why your business needs a password manager and how to choose one are the starting points, and deploying it across the business covers the rollout.

Turn on MFA everywhere and move the accounts that matter most to phishing-resistant methods, while keeping in mind that MFA on its own is not enough, since this whole article is largely a description of the ways attackers get past it. Passkeys are the strongest available answer for the platforms that support them, because a passkey cannot be phished, reused, or copied out of a browser store.

Close the storage gaps: get business credentials out of browsers and off the shared spreadsheet, because those are the two stores an infostealer empties first.

Run a real audit on a schedule rather than after an incident, and put the conditional access policies and tenant hardening in place that turn an unfamiliar sign-in into a blocked one. And since the initial access for most of these is still a convincing message, phishing prevention and the newer AI-assisted version of it are where the recurrence actually gets prevented.

Finally, write down what you just did while it is fresh. The response above is your incident response plan whether or not you have ever called it that, and a one-page version of it, with the insurer’s hotline number and your provider’s escalation contact at the top, is worth more at 11pm than any document you will write calmly next quarter. It belongs in your cybersecurity policy alongside the reporting rule, because an incident response plan nobody can find is functionally the same as not having one.

Common mistakes when responding to a password compromise

1. Resetting the password and stopping there. The session, the rules, the grants, and the extra authenticator all survive it.
2. Remediating before exporting the logs. The evidence you need to answer what was accessed is the first thing your cleanup destroys.
3. Forgetting to revoke sessions. A stolen session token has already passed MFA and does not care about the new password.
4. Missing the OAuth grants. They are the quietest form of persistence and they outlive everything else you do to the account.
5. Not checking for added MFA methods, so the attacker satisfies your second factor and receives the reset through your own recovery flow.
6. Rotating passwords while the recovery email still points somewhere the attacker controls.
7. Assuming it was one account. Reuse is the default, not the exception, and the vault answers this in seconds if you have one.
8. Calling the insurer late, or only once you are certain it is serious. The window is measured in hours and it starts at discovery.
9. Deciding on your own whether it is reportable. That is a legal determination, and the wrong answer in either direction is expensive.
10. Cleaning the account but leaving the infected machine in service, which reinfects everything you just fixed by the end of the week.

How this fits the rest of your credential security

Everything else in credential security is an investment in making this day shorter. A password manager turns the scope question into a query. MFA turns a stolen password into a failed login attempt. Getting passwords out of browsers removes the store the malware goes for first. A written policy makes prompt reporting the expected behavior instead of the brave one. Log retention decides whether you can answer the questions that follow. And knowing the signs that something is already wrong is what determines whether you are reading this on day two or day sixty.

None of it makes a compromise impossible. It makes the difference between an afternoon of methodical work and a month of finding out, in stages, how far it went.

What is next in this series

The next article works backwards from here to the methods themselves: how business passwords actually get stolen, from phishing and credential stuffing through infostealer malware, session hijacking, and brute force against exposed remote access, with the specific control that blocks each one. Knowing the route is what turns the corrective list above from generic advice into a prioritized plan.

How Sequentur can help

If you are dealing with a compromised account right now, or you want the monitoring, response plan, and credential controls in place before you need them, schedule a call.