What breach monitoring actually does – and what it cannot tell you

What breach monitoring is

Breach monitoring is the continuous matching of identifiers you own – email addresses, a whole email domain, sometimes password hashes – against collections of leaked data, with an alert when a new match appears. Consumer services watch one address. Corporate services watch every address at a domain and usually add infostealer logs, where the interesting field is not the address but the password sitting next to it.

Nothing about that is detection in the security-operations sense. Monitoring does not watch your systems, your logins or your network. It watches a third party’s copy of stolen data and tells you when your name shows up in it. That is a genuinely useful signal, and it is a narrower one than the marketing implies.

The scale is easy to underestimate. Have I Been Pwned alone lists 17.8 billion pwned addresses drawn from 1,035 breached websites, and an address that appears in several breaches is counted each time. A monitoring service is a query against that kind of corpus, kept running.

Where the data actually comes from

Three sources feed almost every service, and they behave very differently.

• Disclosed breaches. A company announces an incident, the dump circulates, and the addresses are indexed. Slow, well-attributed, and by the time you are alerted the data has usually been public for a while.
• Combolists. Aggregations of old and new leaks, recompiled and redistributed. Large, duplicated and often undated – which is why an alert can fire on a password you rotated in 2019.
• Infostealer logs. Credentials harvested straight off infected machines, including sessions and cookies. The freshest and most dangerous tier, and the hardest to buy access to legally.

The Verizon 2025 Data Breach Investigations Report describes the distribution economy behind the last two: marketplaces that post logs for sale with the associated domains, paid premium channels inside private chat rooms, live backend access to infostealer databases, and free samples dropped on Telegram to advertise the paid tiers. A monitoring vendor’s coverage is a function of which of those tiers it can reach – and no vendor reaches all of them.

That is the whole coverage question in one sentence: you are not monitoring the breach, you are monitoring a supplier’s access to the resale market. How the pairs get replayed once they are out there is covered in how credential stuffing works.

What a result does not prove

A clean report is the most misread output in this product category. It means the sources your provider indexes do not currently contain your identifier. It does not mean your credentials are safe.

Timing is the other gap. Monitoring is inherently downstream: the credential is stolen, used, traded, and only then indexed. The DBIR 2026 measured the co-occurrence directly – of ransomware victims that had a credential or infostealer leak in the year before they were named, 50% saw that leak within 95 days of the attack. The signal exists, but the window between it and the incident is short and you have to be watching it.

And the alert says nothing about validity. A hit tells you a string associated with your address appeared somewhere. It does not tell you whether the password still works, whether the account was accessed, or whether the record was simply recycled from a 2016 dump. Every alert needs the same three checks: is it current, was it reused, and did anything happen.

In-house checks versus a paid service

Plenty of what a service sells can be done without one. The honest comparison:

Ways to find out that credentials have leaked

Approach	What it gives you	What it costs you
A free breach-notification service	Alerts on disclosed breaches for one address, or for a domain you can prove you control.	Disclosed breaches mostly; little or no infostealer-log coverage, and no help interpreting a hit.
Provider-native alerts	Your identity provider already flags leaked-credential matches, impossible travel and new-device logins.	Only accounts on that provider, and only if someone reads the alerts and acts on them.
Blocklisting at password set	Stops a known-compromised password from being chosen in the first place.	Preventive only. It does nothing about a password already in use and already leaked.
A paid monitoring service	Broader source coverage, infostealer logs, whole-domain watch, dashboards and enforced resets.	Subscription cost, plus an owner who triages alerts. Coverage is still bounded by the vendor’s sources.
Nothing at all	You find out when a customer, a regulator or an attacker tells you.	The detection gap becomes the incident.

The order matters more than the shortlist. Unique passwords and phishing-resistant MFA reduce what a leaked pair is worth; monitoring only tells you that one exists. Buying the alert before fixing the reuse is paying to watch a door you left open.

What to do with an alert

An alert is an input to an investigation, not a verdict. NIST SP 800-63B-4 is the useful anchor here: verifiers SHALL NOT require periodic password changes, but “verifiers SHALL force a change if there is evidence that the authenticator has been compromised”. A credible monitoring hit is exactly that evidence.

1. Establish what the hit actually is: which address, which source, which date, and whether a password or only an address was exposed.
2. Force a reset on the affected account and anywhere the password was reused. Reuse is the vulnerability; the source of the leak is only where it surfaced.
3. Revoke sessions and tokens. A password change does not always invalidate a session an attacker already holds.
4. Check for use: logins from new devices or locations, mailbox rules, MFA enrolments, changed recovery details.
5. If it is a corporate account, hand it to whoever owns incident response before you tidy it away – the notification clocks may already be running.
6. Record the decision either way. GDPR Article 33(5) requires the controller to document any personal data breach, including the ones assessed as low risk and not notified.

The ordered response for an individual account is in what to do after a data breach; if you are not sure whether what you are looking at counts as a breach at all, start with what is a data breach.

Is it worth paying for?

For an individual: usually not. A free breach-notification service plus a password manager plus MFA on email and banking covers the realistic risk, and the paid consumer bundles mostly resell the same index with an identity-theft insurance wrapper.

For an organisation the calculation changes, for three reasons. Employees reuse work passwords on personal services you do not control. Infostealer logs are where corporate credentials actually surface, and free tools do not carry them. And a domain-wide watch with an enforced reset is an operational control, not a notification.

Judge a vendor on the parts that are hard to fake: which source tiers it reaches, how fast a leak is indexed after it appears, whether it returns the password material or only the fact of a match, and what it does when it finds something. Contract language about “the dark web” is not a coverage statement.

What monitoring does not replace

Monitoring is a detection control with a known blind spot, and it sits on top of prevention rather than instead of it.

• Unique passwords in a manager, so one leak cannot travel. This is the control monitoring cannot substitute for.
• Phishing-resistant MFA on email, banking and work logins, so a valid password is not enough on its own.
• Blocklisting compromised passwords at the point they are set, per NIST SP 800-63B-4.
• A response plan with an owner. GDPR Article 33(1) starts its 72-hour clock at awareness, and an alert nobody triages is awareness you cannot defend.

Used that way – as a short-notice warning on top of controls that already limit the damage – breach monitoring earns its place. Sold as proof that your credentials are safe, it is the one thing it can never be.