What breach monitoring can and can't catch before a client account is compromised

Breach monitoring works on a simple mechanism: security researchers and threat intelligence services aggregate credential dumps that surface from prior breaches — sometimes months old, sometimes years — and index them by email address or domain, so a platform can check whether a client's known email addresses appear in that corpus and flag the ones that do. It is a genuinely useful signal, and it is also a fundamentally reactive one, and the gap between what it catches and what it implies deserves more scrutiny than 'we monitor the dark web' usually gets.

What it actually catches

• Credentials that were already stolen and have surfaced in a dump some researcher or service indexed — this is the core, legitimate use case, and it's real.
• Reused passwords, indirectly — if an employee's personal account password shows up in a breach and they reused it anywhere on a monitored domain, that's a real, actionable warning.
• Pattern data across an organization — several employees appearing in the same breach corpus over time is a decent signal for where to prioritize password-hygiene conversations.

What it structurally can't catch

• A credential that was phished yesterday and hasn't been resold, dumped, or indexed anywhere yet — breach monitoring has no visibility into an attacker's private access before it becomes public or semi-public data.
• A password that was never reused and never previously breached, compromised via a method other than a known dump — keylogger, infostealer log not yet indexed, session token theft — none of that shows up in a breach database.
• Timing — even for credentials that do eventually surface, there is a lag between compromise and indexing that can run from days to months, during which the account is exposed and breach monitoring alone says nothing.

This is why breach monitoring is a detective control, not a preventive one, and treating it as sufficient defense against credential stuffing specifically is a category error. Credential stuffing attacks work by taking a breach dump and testing those same username-password pairs against other services in bulk — the defense that actually stops that is unique passwords per service plus multi-factor authentication, not knowing after the fact that a password was in a dump. Breach monitoring tells you where the fire already started; it doesn't fireproof the building.

Where this fits in an MSP's actual practice: it's one input alongside enforced password policy, MFA coverage tracking, and account lockout tuning — not a substitute for any of them. If a vendor's breach monitoring pitch stops at 'we'll tell you if your email was in a breach,' ask the harder follow-up: what's the median time between a credential appearing in an indexed dump and your system flagging it, and what happens automatically when it does — does anything actually force a password reset, or does it just generate an alert someone has to notice and act on. The honest answer for most tools, Nexus included as this capability matures, is that the alert-to-action gap is exactly the place to keep pushing, and it's worth asking any vendor to be specific about where their own gap currently sits rather than accepting 'we monitor for breaches' as a complete answer.