What we look for

Credential Exposure Monitoring, Verified

Most of what we find on your attack surface is infrastructure: a forgotten host, an exposed service, a vulnerability someone is already exploiting. This group is the exception. It is about people — the logins belonging to your employees and executives that have ended up in someone else’s hands and still work.

This is the People group, one of the six exposure groups we look for. It is not a separate product and cannot be bought on its own.

Where credential exposure sits in attack surface management

Credential exposure is one of six exposure groups we check across your external attack surface, alongside things you didn’t know were online, things anyone can reach, things that leak, things being exploited right now, and things already compromised. On the What we look for page it is the People group: logins that still work, employees and executives.

It is included on Standard ($100 a month, up to two domains) and Business ($250 a month, up to six domains). It is not part of the Free tier — the free check covers one domain, counts every host and examines five of them, and its findings arrive unverified. If leaked logins are what you came for, you need a paid plan.

We do not sell this as a standalone subscription, and we would rather say plainly why: on its own it is a feed, and a feed is work rather than an answer. It earns its place when it sits next to the hosts and services it could be used against.

Where exposed logins come from

The main source is malware that sits on a device and copies what the browser has saved. Microsoft Threat Intelligence, writing about Lumma Stealer in 2025, described it plainly: the malware “extracts saved passwords, session cookies, and autofill data” from Chromium, Mozilla and Gecko-based browsers.

A joint FBI and CISA advisory in 2025 described the same class of malware collecting “personally identifiable information, financial credentials, cryptocurrency wallets, browser extensions, and multifactor authentication (MFA) details”. The output is then packaged and sold: the same advisory cited more than 21,000 marketplace listings for one malware family’s logs over a single quarter in 2024.

The scale of what is in circulation is reported mainly by vendors who sell credential products, so treat the numbers as their telemetry rather than as an industry census. Flashpoint reported over 11.1 million machines infected during 2025; SpyCloud, measuring a different footprint, reported 13.2 million infostealer infections over the same year. The two are not reconcilable and we do not average them.

Credentials also reach the same markets through ordinary breaches of other companies — a service your staff signed up to with a work email, which is later compromised. That is why reuse matters, and why this is not only a question of whether your own systems have been broken into.

Why a leaked password may still work

A password appearing somewhere is not the same as a password working. The useful question is the second one, and it is harder.

Two things keep old credentials alive. The first is reuse. Verizon’s 2025 Data Breach Investigations Report found that among users infected by infostealer malware, the median user had only 49% of their passwords distinct from one another across services. SpyCloud, measuring its own recaptured data for 2026, put reuse at 65% among consumer accounts and 42% among corporate accounts. Those are different populations measured differently; we report them separately rather than blending them into one number.

The second is that a stolen session can skip the password entirely. MITRE ATT&CK describes it directly: an adversary may steal session cookies “and use them to gain access to web applications or Internet services as an authenticated user without needing credentials”, and notes that session cookies can be used to bypass some multi-factor authentication protocols. Mandiant’s M-Trends 2026 reported attackers “bypassing standard defenses by harvesting long-lived OAuth tokens and session cookies”. This is why “we have MFA” is a weaker answer than it sounds.

Our view, and we want to be clear it is a view rather than a finding: a credential that still opens something is a different kind of problem from a credential that merely appears in a corpus, and deserves to be treated as such. The closest hard evidence we have found is Cloudflare’s 2025 research, which reported that 41% of successful human logins across the sites it protects used a password already known to be leaked, and that 76% of login attempts on WordPress sites using a leaked password succeeded. That measures login success across the web, not the state of any one company’s accounts — but it is enough to show that leaked does not mean dead.

How often stolen credentials actually cause breaches

You will find a lot of marketing claiming stolen credentials are the number one way companies get breached. As of the most recent reports, that is no longer what the data says, and we are not going to tell you otherwise to sell a feature.

Verizon’s 2025 Data Breach Investigations Report put credential abuse first, at 22% of breaches, ahead of vulnerability exploitation at 20%. The 2026 edition reversed it: vulnerability exploitation moved to the top with 31% of breaches starting there, beating stolen passwords, and credential abuse fell to 13% as an entry point.

Mandiant’s figures moved the same way. M-Trends 2025 reported that stolen credentials had risen to the second most common initial infection vector at 16%, attributing the rise to infostealers. M-Trends 2026 put exploits first for a sixth consecutive year at 32%, with stolen credentials further down the list.

What has not fallen is credential theft as an outcome and an enabler. IBM’s X-Force Threat Intelligence Index 2025 reported that nearly one in three incidents it responded to in 2024 resulted in credential theft, and that the top five infostealer families carried more than eight million dark-web advertisements in 2024. Picus Security’s Red Report 2025, from just over a million malware samples, found 25% of malware targeting credentials in password stores — three times the prior year.

One statistic deserves a caveat rather than a citation. CISA and the US Coast Guard reported that valid accounts were the most common successful technique at 41%, but that figure comes from their FY23 Risk and Vulnerability Assessments — red-team engagements where assessors deliberately seek the easiest route in. It is not real-breach telemetry, and quoting it as though it were would be dishonest.

So the honest position is this: credentials are not currently the leading way in, they still matter a great deal once an attacker has one, and anyone citing a single percentage without naming the report and the year is not telling you enough to judge it.

Why credential monitoring belongs inside attack surface management

This section is our reasoning, not a sourced finding, and we would rather label it than dress it up. We know of no standards body that rules on where credential monitoring belongs.

The argument is about what a credential is for. On its own, a leaked login is a string. It becomes a problem when there is something it opens — a VPN endpoint, an admin console, a webmail portal, a forgotten staging environment still accepting logins from the internet. Attack surface management is the discipline that knows what those things are, because finding them is its entire job.

Separating the two means someone has to rejoin them, usually under pressure. A credential feed on its own cannot tell you that the exposed account belongs to an administrator of the one host you forgot was online. An asset inventory on its own cannot tell you that someone already has the key. We would rather hold both and let the analyst make that connection before you ever see it.

There is also a plainer reason. Running a separate credential product means a second subscription, a second console and a second queue of alerts for something that, on the numbers above, is one risk among several. For most of the teams we work with, that is not a good trade.

The limits of leaked-credential data

No one holds a complete picture of leaked credentials, and anyone implying otherwise is overselling. Have I Been Pwned, which has published breach data longer than almost anyone, says of its own data that “it contains but a small subset of all the records that have been breached”, and that “many breaches never result in the public release of data and indeed many breaches even go entirely undetected”. It is equally blunt about the inverse: “just because your email address wasn’t found here doesn’t mean that it hasn’t been compromised”. We will never tell you that you are clear. We will tell you what we found.

The raw data is also mostly stale. Flare, a competitor whose entire product is built on this data, published that “just over 1% of validated credential events turned out to be true positives, meaning the exposed account and related credentials were still active”. We cite a competitor here deliberately: it is the most candid published figure we have found, and it describes the nature of the material rather than any weakness of theirs.

That raises the obvious question of how anyone knows whether a specific password still works. The only certain test is to try it, and trying a password against a live service is unauthorised access — so we do not do it, for your accounts or anyone’s. This is our policy rather than a legal opinion, and we state it because a vendor promising certainty here is promising something they should not be doing.

What we do instead is the unglamorous part. An analyst reviews each credential finding before it reaches you: what it is, how recent it is, which account it belongs to, and whether that account connects to anything we can see on your estate. You get a verdict — still needs fixing, already fixed, or doesn’t apply to you — with the reasoning recorded.

Checking an exposed password against known-compromised data is a recognised control, not an exotic one. NIST SP 800-63B requires that “verifiers SHALL compare the prospective secret against a blocklist that contains known commonly used, expected, or compromised passwords”, and names “passwords obtained from previous breach corpuses” as a source. The same standard cautions that excessively large blocklists are “of little incremental security benefit” — which is a useful corrective to vendors who advertise the size of their database as though volume were the point.

What you get, and on which plan

On Standard and Business, exposed employee and executive logins are reported alongside everything else we find on your estate, in the same queue, with the same analyst verdict and the same record of why anything was dismissed. You can ask an analyst about any finding and get a reply, usually the same working day. Alerts go to email, Slack or a webhook when something changes.

On the Free tier, you get the rest of the attack surface check on one domain — every host counted, five examined, scanned weekly, findings unverified — but not this group. We would rather say that here than let you find out after signing up.

Common questions