A finance director opens a laptop at home, logs into the company's cloud accounting platform, and lets the browser remember the session. Months later that same browser profile turns up in an infostealer log: no corporate password in sight, just a personal webmail address and a folder of cookies. Domain-level monitoring stays silent, because nothing matching @yourcompany.co.uk was ever in the dump. The attacker imports the cookies, resumes an authenticated session and starts reading supplier payment details.
That is the shape of the problem with most leaked credential monitoring. The feed is working exactly as designed. It is watching one corporate domain, matched against aggregated breach data, and it is blind to the identity that actually got you compromised.
Below are five coverage gaps that standard monitoring leaves open, and what closing each one looks like in practice.
Why Most Leaked Credential Alerts Change Nothing
The typical setup is a single corporate domain checked against a pile of aggregated breach dumps. It produces a long list of email and password pairs with no indication of where the record came from, when it was captured, or whether the password still works. Teams triage it once with enthusiasm, then stop opening it.
The split that matters is between recycled combolists and fresh stealer output. A combolist is old breach data re-stitched, deduplicated badly and reposted, often across several Telegram channels in the same week. Stealer output comes off a live device: browser-stored passwords, cookies, autofill, sometimes the full list of installed software and the machine name. One is history. The other is an active foothold, and if your feed treats them identically, your analysts spend their week resetting passwords that were rotated in 2021.
A finding worth acting on carries five things: the source collection, the capture date, the host or malware family where it can be determined, the identity type, and whether the credential is internal, external or personal. Without those, you cannot prioritise, and you certainly cannot tell a board that the exposure has been contained.
Stop counting alerts. Count time to confirmed reset, re-exposure rate for the same identity, and the number of identities the programme surfaced that you did not previously know existed. That last number is usually the uncomfortable one.
Gap One: Executives, Assistants And Personal Identities
Attackers targeting a named individual do not start with the corporate login that sits behind conditional access and MFA. They start with the personal Gmail, the reused password from a 2019 retail breach, the home router admin account, the spouse's shared streaming login that shares a password pattern with everything else. None of it matches your domain.
Executive monitoring is usually scoped to the board and stops there. The people with the most useful access are often one layer down: the executive assistant with delegated mailbox rights, the finance approver who releases payment runs, the IT administrator whose personal device also holds a saved VPN profile. Those identities deserve the same treatment, and they need to be handled discreetly. A spreadsheet called "VIP watchlist"circulating internally is its own exposure.
Routing matters as much as detection. A chief executive's personal webmail appearing in a stealer log is a people-risk conversation, not a service desk ticket, and it should land with whoever owns that relationship rather than in a shared queue. Separating internal identities from external and personal ones in the finding itself is what makes that routing possible.
Agree the rules before the first alert. Ownership verification for each monitored identity, written consent where you are watching personal accounts, a defined purpose, and sign-off from HR and legal. UK GDPR Article 32 obliges you to secure personal data you process, and monitoring an individual's personal identity is itself processing. Proportionality is the test: monitoring for credential exposure linked to a role with privileged access is defensible, general surveillance of someone's online life is not.
Gap Two: Suppliers, Contractors And Shared Logins
Credential exposure reaches you through other people's estates. A managed service provider's engineer with standing remote access. A marketing agency holding CMS and ad platform credentials. An outsourced helpdesk running your ticketing queue. The breach is theirs, the account takeover is yours, and your monitoring covers none of their domains.
The worst case is the unowned account. A shared supplier mailbox like support@ or projects@, used by six engineers across two shifts, with standing access to your ticketing system. When it appears in a leak, nobody resets it, because no individual is responsible for it and rotating it breaks three workflows. Service accounts and generic admin logins behave the same way: long-lived passwords, no MFA, no owner, no reset.
Pair credential findings with the public security signals you can see on key suppliers, from exposed services and expired certificates to accreditation status, so you can tell which third party is genuinely the weak link rather than the one with the best questionnaire responses. Our write-up on auditing vendor access after the ConnectWise supply chain breach goes into how that access mapping works in anger.
A practical ask for this week: list your top 20 suppliers by access level, not by spend. Then check how many of their domains your current monitoring actually covers. For most organisations the answer is zero.
Gap Three: The Secrets That Are Not Passwords
This is the gap that turns a contained incident into a protracted one. Infostealers take session cookies and OAuth tokens alongside saved passwords. A valid session cookie lets an attacker resume an already-authenticated session, which means multi-factor authentication is never challenged. You reset the password, feel finished, and the intruder stays logged in.
The same logs routinely carry API keys, cloud access keys, SaaS integration tokens, SSH keys and VPN configuration files. Password-only matching walks straight past all of it. If your feed only returns email and password pairs, the most dangerous line in the log never reaches you.
Remediation has to say so explicitly. A credential finding should instruct: reset the password, revoke active sessions across the identity provider, force re-authentication, rotate any keys present in the same capture, and check for persistence such as new mail forwarding rules or added MFA methods. The NCSC's password guidance is clear that resets alone are a blunt instrument, and in a stealer context they are often the least effective part of the response.
Speed matters most with machine credentials. Stolen cloud and AI service keys get resold in chat channels quickly and consumed quickly, because compute billed to someone else has immediate resale value. We covered how that market works in LLMjacking and how stolen AI keys get found. For those findings, rotation speed beats everything else you could do.
Gap Four: Identities On Assets You Forgot You Owned
Credential monitoring inherits the limits of your asset inventory. If discovery has never found the acquired subsidiary's domain, the staging environment from a 2022 project, or the marketing SaaS tenant someone bought on a company card, then no volume of dark web and Telegram collection will surface the identities sitting on them. The collection is fine. The scope is wrong.
Shadow IT produces credentials that look legitimate to an attacker and invisible to you. A forgotten SaaS tenant still accepts logins, still holds data, and still has an admin account with a password from the day it was provisioned. Continuous external asset discovery, geographical mapping and drift tracking keep the monitored domain list and the real estate in step, rather than letting them diverge quietly for three years.
Then there are the domains that create leaked credentials rather than hold them. Typosquats and lookalikes are often the harvesting mechanism behind the credentials you later find in a dump, so detection, evidence collection and registrar takedown belong inside the same programme as monitoring, not parked in a separate brand protection workstream. Removing the harvesting site stops the supply at source; resetting passwords afterwards only cleans up behind it.
A reconciliation exercise you can run in an afternoon: export your monitored domain list, then compare it against your DNS zone records, certificate transparency entries for your organisation name, and the software lines in last year's expense reports. The gaps between those four sources are your unmonitored identity estate.
Gap Five: No Provenance, So You Cannot Tell New From Old
Recycled records resurface constantly. The same breach reappears in a Telegram channel under a new name, a leak site reposts it with fresh branding, and an aggregated feed treats it as a new event. Your team runs a second round of resets that achieves precisely nothing, and trust in the feed drops another notch.
Deduplication matters more in credential work than it does in vulnerability management. One identity can appear across four collections with three password variants and two capture dates, and it should arrive as one finding with the newest capture on top and the older sightings listed beneath it. Auto-resolution should close findings that have already been remediated rather than reopening them when the data is reposted. Without that, you are generating noise, which is a problem we have written about more broadly in the context of reducing security alert fatigue.
Keeping the history for each identity is what makes repeat appearances diagnostic. If the same user shows up in three separate stealer collections over six months, that is rarely three breaches. It is one unremediated device still beaconing out, and the fix is endpoint work, not another password change.
The records that matter still need a human. Confirming whether the account exists in your directory, whether it is in scope, what access it holds, and whether the capture is genuine is analyst work, and it is where a domain check with several thousand hits usually collapses to a few dozen recent records and a handful of live accounts worth urgent action. Understanding the full path from exposure to account takeover is what separates a prioritised finding from a row in a spreadsheet.
How To Pressure-Test Your Current Monitoring
Put these to your existing or prospective provider and listen for specifics rather than reassurance:
- Which collections are searched, and how are Telegram channels, leak sites and stealer log sources handled differently from aggregated combolists?
- How often is the data refreshed, and what evidence of capture date accompanies each record?
- Which identity types beyond employee email are covered: personal identities, supplier domains, service accounts, API keys, session artefacts?
- How are duplicates merged, and what happens to a finding when the same record is reposted?
- Where does human analysis sit in the process, and what gets escalated to an analyst rather than published automatically?
Ask about handling, too. Ownership verification before monitoring begins, customer-controlled scanning boundaries, organisation-level data separation so sensitive findings are never pooled across clients, and clear limits on where automated analysis is used. Our approach to responsible EASM sets out what those controls look like in practice.
Remember what your provider is holding on your behalf: plaintext passwords and personal data relating to named individuals. That makes them a processor under UK GDPR, needing a data processing agreement, a documented retention period, defined access controls and a route to notify you fast enough that you can meet the ICO's 72-hour reporting window if a confirmed compromise turns into a notifiable breach. Document the lawful basis for monitoring named individuals before you start, not after the first alert.
Finally, group the output. Twenty findings pointing at one infected contractor laptop are one remediation project with one owner and one closure date, not twenty tickets. Current Cyber Essentials requirements on multi-factor authentication and separating administrative accounts from day-to-day ones remove a large share of what credential exposure can be used for, so pair monitoring with those controls rather than treating it as a standalone feed.
Leaked credential monitoring earns its place when it tells you about identities, secrets and assets you did not know you had. If you want to see which of these five gaps is open in your own estate, start by mapping what attackers can already see of your external attack surface.
Frequently Asked Questions
What does leaked credential monitoring actually cover?
At minimum it matches your corporate email domains against breach data and infostealer collections. Done properly it extends to personal and executive identities, supplier and contractor domains, service and shared accounts, and non-password secrets such as session cookies, OAuth tokens and API keys. The breadth of identity types covered is the main difference between a free checker and a managed capability.
How do I tell a fresh infostealer record from a recycled combolist?
Look at the metadata rather than the credential. Stealer output usually arrives with device context such as hostname, installed software, cookie files and an identifiable malware family, and it comes from a dated collection. Combolists are flat email and password pairs with no device context, frequently reposted, and often reconstructed from breaches you have already remediated.
Is a free domain checker enough for credential exposure?
It is a reasonable first look and a poor ongoing control. A domain checker sees only identities on the domains you type in, gives you little or no capture date or source, does not deduplicate across collections, and ignores tokens and keys entirely. The exposures that cause incidents tend to sit outside the domain you checked.
Can we monitor employees' personal accounts legally in the UK?
Often yes, with the right groundwork. You need a lawful basis, a clear and proportionate purpose tied to the individual's role and access, transparency with the person involved, and usually consent for genuinely personal identities. Agree the scope with HR and legal, document it, and keep the findings tightly access-controlled. This is general guidance rather than legal advice, so take your own counsel on your circumstances.
What should we do first when a leaked credential alert comes in?
Confirm the account exists and check the capture date and source before touching anything. If the record is recent and the account is live, reset the password, revoke active sessions, rotate any keys or tokens in the same capture, and check for persistence such as mail forwarding rules or newly registered MFA methods. Then establish whether the source was an infected device, because if it was, the device is the real finding.
