Credential leak monitoring: what it can and cannot tell you

What credential leak monitoring is

Credential leak monitoring checks whether your people's logins appear in data that has already leaked. A service takes an email address, a username or a domain and looks it up in collections of breached and leaked records. When it finds a match, it reports what came with it: a password in plaintext or as a hash, a phone number, a username, the name of the breached service.

Credentials are still a common way in. Verizon's 2026 Data Breach Investigations Report found credential abuse as the first step in 13% of breaches, down from 22% a year earlier, partly because the report now counts pretexting as its own entry point. Counted at any point in a breach, credential abuse still sits on top at 39%. Verizon's additional 2025 research on credential stuffing adds that, in the median case, only 49% of an infostealer victim's passwords across different services were distinct from each other. Reuse is what turns one old leak into a working login somewhere else, a pattern explained in our glossary entry on credential stuffing.

Leaders are worth checking first, because their accounts open the most doors. Nisos analyzed 72 executive vulnerability assessments for its 2026 Executive Digital Exposure Trends findings, and every executive in that sample had breach data linking their name to at least one current email address. The public summary does not say how the executives were chosen. Our article on executive personal accounts covers why the personal side matters.

What a match can tell you

A good result answers a short list of factual questions. The table sets out what each signal supports and where it stops.

Two of these rows carry most of the weight. Plaintext passwords are the most urgent finding, because anyone holding the file can try them. Repeat appearances across many breaches are a strong sign of reuse, and reuse is what makes an old breach dangerous. Our page on the difference between combolists, stealer logs and database dumps explains why the same pair keeps resurfacing.

What it cannot tell you

Five questions sit outside what a breach lookup can answer.

Whether the password still works. A breach record is a snapshot. A password exposed years ago may have been changed since. A match tells you what to check, not what is true now.

Whether a session is already hijacked. Microsoft's token theft playbook describes attacks in which threat actors replay tokens issued to a user, "even if that user has satisfied multifactor authentication." A stolen session token is not a password and will not show up as one. See session cookie theft for the mechanics.

Whether a device is infected. Infostealer malware takes saved passwords, cookies and form data from a browser. Detecting the infection is endpoint work. Breach lookups see the result only if and when the stolen data appears in a source they read. What such a log can give away beyond the password, down to a company's suppliers, is the subject of our article on stolen credential paths.

What never surfaced. A lookup can only find data that reached the corpora and databases it searches. Data sold privately, or never leaked at all, leaves no trace there.

Intent. A record in a breach corpus says nothing about whether anyone plans to use it against your company.

How to act on a finding

A match is a lead. Work it in this order.

1. Confirm the account. Is the address still in use, and which systems does it sign in to? Old aliases and forwarding addresses count.
2. Rotate where the evidence is real. NIST's current SP 800-63B says verifiers "SHALL force a change if there is evidence that the authenticator has been compromised." The same document says verifiers "SHALL NOT require subscribers to change passwords periodically." Rotation should follow evidence, not the calendar.
3. Block known-bad passwords. NIST requires that new passwords be compared against a blocklist that can include "passwords obtained from previous breach corpuses." If your identity provider supports this, switch it on.
4. Chase the reuse. If a leader's leaked password matches a pattern they still use, change it everywhere that pattern appears, starting with email and the password manager.
5. Check sessions, not only passwords. Where infostealer activity is suspected, revoke active sessions and review new devices and mailbox rules, as the Microsoft playbook sets out.

Our step-by-step guide on what to do when an executive's password is in a breach goes further on this sequence.

How WebThreat covers credential leaks

CEM covers the executive side of this problem. You enter a company name, it finds the leadership team, and it checks each person against breach corpora and leak databases. For each scanned executive you see the breaches and exposed fields, with findings ranked by what to reset first. Ranking draws on published factors such as likely password reuse, breaches across many platforms, severity and recency, and the methodology lists every factor. Nothing is installed on your systems.

Stealer logs and the forums, marketplaces and chat channels where leaked data is traded are the ground of EDG3, WebThreat's threat intelligence for leaked data. It watches the channels and communities where stolen data, stealer logs and combolists are posted and sold, links reposted copies of a leak back to its first post and profiles the sellers behind it. Where an executive's personal information sits on people-search or data broker sites, WebThreat's information removal specialists file the opt-outs and takedown requests and verify each removal.

For the market view of where leaked data travels, read dark web monitoring for executives: what it can and cannot tell you.

Questions to ask any vendor

Use these in a demo, whichever vendor you are talking to.

• Which sources do you read, and are they breach corpora, leak databases, stealer logs, forums or a mix?
• How often is each person checked, and what triggers a new check?
• What happens when you find something: a dashboard entry, an email, a ticket?
• Do you show the plaintext password, a masked version or only a flag?
• How do you tell a fresh exposure from a repost of an old one?
• What do you not cover?

WebThreat's answers: CEM checks each executive against breach corpora and leak databases from a company name; EDG3 covers dark web forums, Telegram and leak databases.