What the listing actually proves
A combolist entry proves that a username and password associated with your domain exists in a file that someone compiled. It does not prove that your systems were accessed, that the password is current, or that the data is new.
This matters because the instinct on seeing your company name in a breach notification is to treat it as an intrusion. In most cases it is not one. It is evidence that your users exist in the wider credential economy, which they always did.
The dangerous version of this mistake is the opposite one. Because most listings are historical, teams learn to shrug at them, and then shrug at the one that is not. Separating the two is the whole job, and it takes about an hour.
Why the number in the headline is wrong
Combolists are built by merging. Somebody takes several existing collections, concatenates them, deduplicates badly or not at all, and publishes the result under a new name with an impressive count attached. The count is a selling point, not a measurement.
Two public datapoints show the scale of the recycling. Troy Hunt's examination of the Naz.API collection found 65.03 percent of a sampled set already present in previously known breaches. Of the 183 million record Synthient stealer log corpus, 91 percent was already in Have I Been Pwned before it was published.
So when a listing claims two million records and your domain appears in it, the number tells you about the aggregator's assembly method and nothing about your exposure. The figure to establish is how many distinct addresses on your domain appear, how many of those are still active accounts, and how many of those people still use that password anywhere. Those three numbers shrink dramatically at each step.
For what these collections are and how they are assembled, see what is a combolist.
The question that decides your response
There is one question worth answering before anything else. Did this data come from a third party breach, or from a device?
The answer changes everything, and the evidence is usually in the record format itself.
Third party breach data looks like a credential pair and little else. An address and a password, perhaps a username, often with no indication of which service it came from. The compromise happened at a company you do not control, probably some time ago, and the exposure is of a password your user chose to reuse.
Infostealer data looks different. Each record carries the URL or application the credential was used on, often alongside browser cookies, autofill entries, and details of the machine itself. That is the output of infostealer malware emptying a browser's credential store, and it means a specific device was compromised. Possibly last week. Possibly a contractor's laptop you have no visibility into.
If the data looks like the second kind, you do not have a historical exposure. You have an active one, and the password is the least interesting thing that was taken.
What to do, in order
The order is the part that gets skipped, and skipping it is what turns a contained incident into a prolonged one.
Scope it first. Pull the distinct addresses on your domain, match them against your directory, and separate current employees from leavers and from addresses that never existed. Many combolist hits resolve to accounts that closed years ago.
Revoke sessions before you reset anything. Microsoft's documented remediation sequence puts account disablement and session revocation ahead of the credential steps. Resetting a password while an attacker holds a valid session leaves them logged in, warns them that you have noticed, and gives them time to establish something that survives the reset.
Then reset the credential, and only for accounts where there is a real match rather than a lookalike address.
Check the persistence surfaces, which is the step most incidents omit. More on those below.
Remediate the source device if the evidence points at malware. If a machine is infected and you reset the password without cleaning it, the new password is harvested the next time it is typed. This is the single most common way a credential incident repeats itself a fortnight later.
Then look at reuse. A credential that appeared in a combolist was very probably used somewhere else too, which is the mechanism behind credential stuffing.
Six things that survive a password reset
An attacker who intends to keep access does not rely on the password, and a reset does not touch any of the following.
Mailbox rules and forwarding. Rules that quietly archive, delete or forward messages matching keywords, so your warning emails never reach the user.
OAuth application grants. A consented third party application holds its own token, entirely independent of the password.
Registered authentication methods. An authenticator app or phone number the attacker added, which lets them complete multi factor authentication after your reset.
Delegate and shared mailbox access. Permissions granted to another account the attacker controls.
App passwords. Microsoft states explicitly that these are not revoked by a password reset. They exist for legacy clients, and almost nobody audits them.
API tokens and keys. Generated by the account, valid independently of it.
Each needs checking separately. An incident response that resets the password and closes the ticket has, in a meaningful share of cases, changed nothing.
Why the password may be the smallest problem
If the exposure came from an infostealer, the browser's cookie store usually went with it.
Google stated in April 2024 that cookie theft of this kind happens after login, which means it bypasses two factor authentication and login time reputation checks entirely, and that stolen cookies remain valid even after the malware is removed. A session token is a login that already succeeded. Importing it requires no password, triggers no authentication, and consults no authenticator.
So if the records carry session data, a password reset addresses the least valuable thing that was stolen. See session cookie theft for what that actually involves.
What not to do
Do not download the combolist to check. Obtaining and holding a file of other people's credentials creates a legal and data protection problem of your own, on top of whatever you already have. Verify through a provider that already holds the data lawfully, or through your own directory.
Do not force a global password reset as a reflex. It generates helpdesk load, trains users to pick weaker variants of the same password, and does nothing about any of the six surfaces above.
Do not treat the absence of a listing as safety. Collections circulate privately for a long time before they are published, and publication is the last step rather than the first.
Do not accept a number without a denominator. If a provider tells you how many of your credentials are exposed, ask whether that counts credential pairs, unique addresses, distinct records or detection events. Those are four different numbers and the largest is usually the one quoted.
The part that actually reduces recurrence
A combolist listing is a symptom. The two things that stop it recurring are unglamorous.
Removing password reuse, through a password manager and by checking new passwords against known breached sets, so that a third party breach stops being your problem.
And monitoring exposure continuously rather than finding out when a collection is published, because the gap between a device being infected and its contents being compiled into a list is where the whole risk lives. That is what stealer log monitoring is for.
Neither prevents your users appearing in somebody else's breach. Both change how long it matters.