By the time an attacker uses a stolen login, the theft already happened somewhere you couldn't see it: an employee's home laptop, a phishing page, a breached service someone signed up to with their work email.
Credential monitoring is how you find out before they use it. This guide covers what it checks, how to read what comes back, and what a clean result does and doesn't mean.
Credential monitoring is the practice of checking external sources for your organisation's logins appearing where they shouldn't. It looks for usernames, passwords and session tokens tied to your email domains in breach data, infostealer malware logs and phishing kit captures.
It runs against sources outside your environment rather than against your own systems. That's the point: these credentials were never stolen from you, so nothing in your logs will show them.
Four sources account for most of it.
Infostealer malware. An employee installs something on a personal or work machine and it quietly copies saved browser passwords, session cookies and autofill data. The resulting "stealer log" gets sold in bulk.
Phishing kits. A fake login page captures the username and password as they're typed, often including the one-time code.
Third-party breaches. A service your staff signed up to with a work email gets breached. If the password was reused, it now works on your systems.
Combolists. Older breach data repackaged into large username and password lists, then tested automatically against popular business applications.
None of these require an attacker to touch your network first.
A credential monitoring service works from your company name and every email domain you use, then checks external threat intelligence sources for matches. There's nothing to install and no scanning of your devices.
What it returns:
Not all exposures are equally usable. Three things separate the urgent from the noise.
A credential found in an infostealer log with evidence from an infected machine is the most serious category. It means malware was running on a device with access to your systems, and it may still be. A password from a years-old breach dump is a far smaller problem.
This is the detail people miss. Infostealers take active session tokens as well as passwords, and a stolen cookie lets an attacker resume a session that has already passed MFA. The password may be useless; the cookie may not be.
Ten findings for people who left last year and hold no access matter less than one finding for a current finance administrator. The useful question isn't how many exposures you have. It's whose, and what those people can reach.
In order, because the order matters.
1. Check the device first. If a finding came from an infected machine, resetting the password while the malware is still running hands the attacker the new one. Clean or isolate the device before you touch the credential.
2. Revoke active sessions. Changing a password doesn't end sessions that are already authenticated. For anything with stolen cookies, kill the sessions explicitly.
3. Then reset the password. And check whether that password appears against other services in the findings, because that tells you whether it was reused.
4. Confirm who the person is. Current employee, contractor, or someone who left? A leaver with an exposed credential and a live account is the combination that turns a leak into an incident. Our guide to identifying and mitigating orphaned accounts covers finding those.
5. Check what they could reach. Admin rights, finance systems, customer data. This determines whether you're closing a gap or running an incident.
A one-off check tells you what external sources hold today. It's the right way to start, because most organisations have no idea what's already circulating.
It doesn't cover tomorrow. New stealer logs are published constantly, and a credential that surfaces next month won't appear in a report run this month. The gap between a credential appearing and someone using it is the window you're trying to win, and you can only win it if something is watching.
Run the one-off check to establish a baseline. Move to continuous monitoring if the baseline shows you need it, which it usually does.
Two honest limits.
A clean result isn't a guarantee. It means nothing matched in the sources checked. Exposures that haven't surfaced yet, or that sit in places those sources don't reach, won't appear.
It doesn't fix anything. Monitoring tells you what leaked. Passwords, sessions and devices still need action from your team, and that work is where the risk actually reduces.
It also won't tell you whether a credential has been used. For that you need detection inside your own environment: unusual sign-in locations, impossible travel, privilege changes. That's the detection and response side, covered in our guide to identity threat detection and response.
Josys checks infostealer logs, phishing kits and breach data for your domains, then rates each finding by severity so you know where to start. Each exposure is matched to that person's Josys profile, showing the apps and devices they hold, so you can see what a stolen login would actually reach.
From the alert you can block sign-in in Entra ID, or suspend the account in Google Workspace or Okta. Learn more about Identity Threat Monitoring.
