Dark web monitoring does one narrow job: it tells you when a password, session or piece of personal data tied to your company shows up where criminals trade it. That is genuinely useful. It is also the point where most businesses stop, and an alert nobody acts on protects nothing.
Stolen credentials remain one of the most common ways attackers get into a business, a finding Verizon’s Data Breach Investigations Report has repeated year after year. Most of those credentials did not come from a dramatic hack of your systems. They came from somebody else’s breach, a reused password, or malware on a laptop your team uses to check email from home.
This guide covers what monitoring actually watches, how to sort the alerts it produces, and what a business should do in the first hour after one lands.
Where the Stolen Data Actually Lives
“The dark web” makes it sound like one place. In practice monitoring services collect from several different sources, and they are not equally dangerous.
Breach compilations. Large dumps of usernames and passwords from breached websites, merged and resold. These are the bulk of what any monitoring service finds. Most entries are old, and many passwords were changed long ago.
Infostealer logs. Malware on an individual computer quietly copies everything the browser has saved and uploads it. A single log can hold dozens of passwords, autofill data and live session cookies. These are recent by nature and far more dangerous than an old breach entry.
Forums, markets and chat channels. Where access is bought and sold, including “initial access” to specific companies. A mention here is rare and serious.
Paste sites. Public text dumps, often used to prove a leak is real. Useful as an early signal, and sometimes the first place a breach becomes visible.
Sorting Alerts by How Urgent They Are
Not every hit deserves the same reaction. A sensible triage looks like this.
A work device in an infostealer log
The most serious finding. Assume every saved password and every signed-in session on that machine is compromised, including ones that sit behind MFA. Isolate the device, revoke sessions and reset everything it touched.
A current company password for sale
A corporate login that still matches the live password, or was reused somewhere that still works. Reset it, check the sign-in history for the account, and look for new mailbox rules or forwarding.
Executive or finance details exposed
Names, personal email addresses and phone numbers for the people who approve payments. Nothing to reset, but this is the raw material for invoice and wire fraud. Brief those people and tighten payment verification.
An old password from a third-party breach
A years-old entry for an address that has since changed its password. Confirm it is not reused anywhere, record that it was checked, and move on. Most alerts fall in this group.
Monitoring Is a Smoke Alarm, Not a Sprinkler
The weakness of dark web monitoring is that it detects rather than prevents. Its value depends entirely on what happens after the alert, and on the controls already in place.
The control that matters most is strong authentication. With multi-factor authentication enforced everywhere, a leaked password on its own gets an attacker very little. The exception is the stolen session cookie, which is why infostealer findings sit at the top of the triage list and why short session lifetimes and sign-in risk policies in Microsoft 365 are worth the configuration effort.
The second control is visibility. Knowing that a password leaked is only half the question. The other half is whether anyone used it, and that needs sign-in logs someone actually reads.
What the Common Options Cover
| Option | What it covers well | What it tends to miss |
|---|---|---|
| Free domain breach search | Large public breaches tied to your domain | Infostealer logs, forums and anything recent |
| Identity provider leaked-credential checks | Flags users whose passwords match known leaks, where your licence includes it | Personal accounts, session cookies and context |
| Commercial monitoring service | Breach data plus infostealer logs and underground sources, with alerts | Response: it tells you, it does not act |
| Monitoring inside a managed security service | Alerts routed straight to the team that can reset, revoke and investigate | Only as good as the runbook behind it |
A useful test for any service: ask for a sample alert. If it cannot tell you where the data came from, when it was collected and whether it included session cookies, you will not be able to triage it.
When an Alert Lands: The Response Order
- Confirm the account and the source. Is this a current employee, a live password, a recent infostealer log or an old breach? The triage above decides everything that follows.
- Kill the access, not just the password. Reset the password and revoke all active sessions and tokens for the account. A password reset alone leaves stolen session cookies working.
- Read the sign-in history. Look for logins from unfamiliar locations, new devices or impossible travel since the data was collected. Check the mailbox for new rules, forwarding and OAuth app grants.
- Find the machine. For an infostealer finding, identify the infected device and clean or rebuild it, because the malware may still be running. If there are signs the account was used, treat it as an incident rather than a password problem.
- Close the gap it came through. Reused password, missing MFA, a personal device used for work? Fix the cause so the next alert is less likely.
Dark Web Monitoring Questions, Answered
Related reading: What Is EDR? · Employee Offboarding: What IT Must Do · Writing an AI Acceptable Use Policy
Curious What Has Already Leaked?
We run a dark web exposure check for your domain and walk you through what it finds, including which results matter and which do not. It is part of how we scope Advanced Shield, and there is no obligation.