Credential exposure monitoring is the practice of continuously searching data that attackers hold or trade for your organisation's credentials, and reporting what is found in a form your security team can act on. The definition is unglamorous. The reason the category exists is more interesting, and it has changed in the last two years.
Until recently the pitch was simple, and it was also slightly dishonest. Free breach notification services, the argument went, only know about publicly disclosed breaches, so they miss the credentials stolen by malware. That is no longer true, and a buyer who hears it should push back.
Have I Been Pwned now carries stealer log data. In February 2025 it added an entry for 23 billion rows of stealer logs obtained from a Telegram channel known as ALIEN TXTBASE, covering 284.1 million unique email addresses, with the websites those addresses were entered into and the passwords used. The entry was added on 25 February 2025. Separately, from January 2025, an organisation that has verified control of a domain and holds an appropriately sized subscription can call an API that returns the domains an email address appeared next to in stealer logs. At the time of that announcement the dataset behind it held about 220 million domain pairs covering 69 million of 71 million addresses.
So the coverage argument has largely collapsed. What has not collapsed is the gap between knowing and acting, and that gap is where the category earns its keep.
The three sources, and why they are not interchangeable
Breach corpora are the contents of a specific organisation's compromise. A company was breached, a database left, and your users' credentials are in it because they had accounts there. The useful property is that the source is known, which tells you when it happened and which service the password was for. The limitation is that the password may be years old and may never have been reused anywhere that matters to you.
Stealer logs are the output of infostealer malware running on a specific machine. These do not come from a company's breach. They come from an endpoint, usually a personal one, and they contain whatever the browser had saved, which is often dozens of credentials at once alongside session cookies, autofill data and sometimes the machine's own details. The useful property is that the credentials were live on a real device very recently. The limitation, and it is a serious one, is that the device belongs to a person and may not be a device you manage.
Combolists are aggregated and reshaped credential pairs, assembled from the other two and from older lists, prepared for bulk use against login endpoints. The useful property is that their existence tells you a credential is in active circulation for credential stuffing. The limitation is that provenance is usually destroyed in the aggregation, so a combolist entry rarely tells you where the credential came from or when.
These three demand different responses, which is the first reason the source of a finding matters more than the finding. A breach-sourced credential needs a password reset. A stealer-log-sourced credential needs the device dealt with before the reset, because a reset performed on a machine that is still infected produces a new credential in the same browser profile the malware is reading. A combolist appearance needs the authentication endpoint looked at, because somebody is going to try the pair in volume.
What a notification gives you, and what it leaves out
Take the HIBP stealer log API as the honest best case for a free or low-cost service, because it is unusually well documented about its own limits.
It returns the domains an address appeared next to. Not the password. Passwords live in Pwned Passwords, a separate service, searched separately and by hash.
It does not identify the machine. Nothing in the feature exposes details of the infected device, which means nothing tells you whether the endpoint belongs to your estate or to a contractor's teenager.
It does not tell you whether the infection is live. A stealer log is a snapshot of a moment. Whether that machine is still exfiltrating today is a different question and not one the record answers.
It warns you the data may be wrong. Troy Hunt's own framing is that the data is prepared and sold by criminals who provide zero guarantees as to its accuracy, and that the owner of an address may never have actually visited the indicated website. The feature was described as experimental.
And it does not surface by default. Results are not shown automatically on a domain search. The API design makes it, in his words, easy for an organisation not to see these results, and manual per-individual lookups are explicitly not provided.
None of that is a criticism of the service. It is a free public good being unusually candid. It is simply a description of the distance between a notification and a decision, and every item on that list is a question somebody has to answer before anything gets fixed.
What makes a finding actionable
The useful test for any exposure monitoring, bought or free, is whether a finding answers the questions that determine the response.
Which credential, and for what. The username alone starts an investigation. The username plus the service it authenticated to starts a remediation.
Where it came from. Breach, stealer log or combolist. This single field decides whether you reset, reimage or rate-limit, and a report that omits it is handing you a guess.
When it surfaced, and when it was taken. These are different dates and both matter. The interval between them is how long somebody else had the credential before you knew.
Whether the password is still in use. A credential that was rotated out two years ago is noise. A credential that matches a live password is an incident. Distinguishing them is most of the work of triage.
What else arrived with it. A stealer log that included session cookies is a different problem from one that did not, because cookies let an attacker resume an authenticated session without the password and without the second factor.
Whether the device is yours. Managed endpoint, unmanaged personal device, or third party. This determines whether you can act directly or have to ask somebody else to.
Why the timing argument is the strongest one
Exposure does not arrive evenly, which is the practical case for monitoring continuously rather than checking occasionally.
In SphereTI's own observation of Remus stealer activity, 63,770 detections arrived across eight days, and 85 percent of them landed on two of those days. If your routine is a monthly check, a burst like that is on average two weeks old before anybody looks, and in the worst case nearly a month. The credentials in it were live on real machines the whole time.
This is also what connects the category to the current standard. NIST SP 800-63B-4 section 3.1.1.2 states that verifiers and credential service providers shall not require subscribers to change passwords periodically, and in the same item that verifiers shall force a change if there is evidence that the authenticator has been compromised. Scheduled rotation is now prohibited. Change on evidence is required. That pairing only functions if evidence reaches you, which makes detection the load-bearing part of a requirement most organisations currently satisfy by doing nothing until an annual reset.
What this is not
It is not a password manager. Monitoring tells you a credential is exposed. It does not store or generate credentials.
It is not dark web search as a product. A search is a moment. Monitoring is a standing query against sources that change, and the difference matters because the thing you most want to know is what appeared since you last looked.
It is not a substitute for phishing-resistant authentication. An exposed password matters much less where the second factor cannot be replayed. Monitoring reduces the window; it does not remove the need.
It is not a guarantee of completeness. Nobody sees everything. Any provider claiming otherwise is describing an ambition. The honest question to a vendor is which sources they cover, how often those refresh, and what they will tell you they do not see.
Check your own exposure
SphereTI monitors credential exposure across breach corpora, infostealer logs and credential lists, and reports which of your domains appear, where the credential came from and when it surfaced. If you want to see what is already out there, request a free exposure report. No password is needed.