A leaked password is a state, not a growing number

Most leak reports show a single figure: credentials found. It rises every month, because old dumps re-enter circulation repeatedly and one password appears across five different combolists.

The reason is how the market works. Compilations like "Collection #1" were assembled from dozens of older breaches and are still reissued under new names. On Telegram channels the same file picks up a fresh date every time it is re-uploaded. So the growth measures repackaging speed, not intelligence quality.

Three months later you have the number 11,000 and no idea how many are valid today, how many were already rotated, or whether the increase means your risk increased.

It does not. A metric that can only rise cannot be a management instrument, because no action moves it. Whatever you do, the line goes up — and within a year nobody looks at it.

A leak is a state, not an event. Every finding sits in one of four states: newly found, active risk, resolved, archived. And it moves in one direction only.

The metric changes with it: instead of a running total, the report carries the number of active risks. That number can go down — which is exactly why it is worth reporting. It is also the only figure a board understands, because it responds to work done.

This is not decoration. The state machine also assigns the work: a new finding belongs to the analyst, an active risk to the IAM team, a resolved one to the archive. In a list without states nobody owns anything — which is why nothing gets closed.

Transitions have to be recorded too: who, when, on what basis. Otherwise "resolved" becomes a flag someone sets by hand and nobody audits.

When a new combolist appears, the first question is not "is any of ours in there". The first question is "is this new, or a repackaged copy of a 2019 dump".

If the credential has already been rotated, its reappearance is noise rather than an event. Without that check the system reissues the same alert for the same passwords every quarter, and the analyst stops reading them — which means they will not read the genuinely new one either.

Technically it is not hard: a stable identifier is stored for each finding — usually the address paired with a hash of the password — and new records are matched against it. The password itself need not be stored, and should not be.

The hard part is doing it from the beginning. Later there is nothing to correlate the old data with: all you have is counts, and which finding they belong to is unknown.

Notifying is not resolving. A leaked credential counts as closed only when three things have happened: the password was reset, active sessions were revoked, and multi-factor authentication was enforced for that account.

Not revoking sessions is the most common failure. The password is changed, but the attacker’s open session keeps working. That follows naturally from how applications are built: a refresh token or a long-lived cookie does not know about a password change unless the system deliberately invalidates it.

There are concrete, documented operations for this: `Revoke-MgUserSignInSession` in Microsoft Entra ID, resetting a user’s sessions in Google Workspace, deleting rows from your own refresh-token table. If the action is not on the checklist, it does not happen.

So the right to mark something resolved should belong to the system rather than to a person: the state changes on its own once all three actions are recorded. A flag set by hand is always optimistic.

When a staff credential leaks you have full authority to close it: reset the password in the directory, revoke sessions, enforce MFA. That is minutes of work and needs no negotiation.

Customer credentials do not work that way. A forced reset loads the support desk and costs you a share of the customers — especially where recovery runs through an email address that is sitting in the same dump.

So the usual answer is a graded response: an extra check at sign-in, then a warning, then a mandatory change. The first step is the cheapest and the most effective, because credential stuffing is automated and one additional step breaks the automation.

Both can live in one list; they cannot live under one policy. A report that does not separate them is not operational: there is no single action that applies to both groups.

A large share of combolists is unclean, repeated data. They contain addresses that never existed, records mixed in from other domains, and plainly generated lines.

So a finding has to be confirmed against the domain: is the address in your directory, is the account active, when did it last sign in. Without that check half the list is people who do not work there — leavers, distribution addresses, test accounts.

The second filter is the password itself. If a leaked password could not satisfy your current policy at all — too short, digits only — it most likely comes from a retired system or from an entirely different service. That does not void the finding; it lowers its priority.

The third case is infostealer logs. They differ from combolists in kind: the data was taken off a device, which means cookies and session tokens may have left with it. Here a password reset is not enough — the device itself is untrusted.

In leak handling the primary measure is not volume but speed. Every hour a credential is in open circulation is time granted for stuffing it somewhere else, because people reuse passwords across services.

So two times are measured: time to discovery and time to closure. The first characterises the quality of the intelligence, the second the quality of your internal process — and they must not be merged, because one belongs to the vendor and the other to you.

Measuring the first needs a publication date for the source, and that is not always known. So the practical measure is "from appearing in a channel to appearing in our console" — a checkable number the vendor is answerable for.

Those two numbers say more than "11,000", and both can improve — which means both can be set as targets. A number that only rises cannot be a target at all.

When a vendor says "we found N leaks", ask three questions. How many are active risk right now? How do you separate repackaged old dumps? Is there an integration with the directory or IAM — is closing them your job or mine?

A fourth question is about the report: has the active-risk count fallen over the last three months? Show the chart. If it only rose, either the closure process is not working or the metric is wrong — both worth knowing.

A fifth is about the data: do you store the passwords you find? The right answer is no — a hash or a partial view only. Otherwise the vendor is accumulating your credential database, and that can leak too.

Without clear answers you are buying a feed, not a service. A feed can be useful — but turning it into a state machine will be your work, and that work is rarely priced into the purchase.