A problem that starts somewhere else entirely
When a corporate credential ends up in a breach dump, the breach itself usually has nothing to do with the organisation whose employee is affected. An employee reuses a work email address to sign up for a project management tool, a recipe site, or a forum, that third-party service is compromised eighteen months later, and the resulting dump — email address and password, sometimes both in plaintext — starts circulating.
From a corporate security standpoint, this looks like someone else’s incident. The organisation did nothing wrong; its own systems were never touched. But treating it as someone else’s problem misses what happens next, which is that the credential does not stay contained to the breached service. It becomes a candidate key for every other system that the employee touches, and testing that key against the corporate perimeter costs an attacker almost nothing.
From dump to targeted access
The path from a breach dump to an actual intrusion attempt is shorter and more automated than most security teams assume. Credential stuffing tools take large breach datasets and test them systematically against login pages — VPN portals, webmail, SaaS admin consoles, anything reachable from the internet that accepts a username and password. This is not a bespoke, resource-intensive attack; it is a commodity capability, and the datasets feeding it are traded and aggregated continuously.
Password reuse is what turns a breach at an unrelated company into a corporate access attempt. Studies of credential stuffing incidents consistently point to reused passwords as the enabling factor, and reuse rates remain high even among employees who would describe themselves as security-conscious, because remembering unique passwords for dozens of services is a genuinely difficult behavioural ask.
Why this is an availability problem
Framing breached credentials purely as an identity and access management issue — a matter of enforcing MFA and rotating passwords — understates what is actually at stake. The core issue is availability: how quickly the organisation becomes aware that a credential tied to its domain is circulating, and how quickly it can act before that credential is tested against a live login page.
This is fundamentally a race against time. A credential that surfaces in a dump and is identified by the organisation within hours can be rotated before it is ever tested. The same credential, undiscovered for weeks, has already been through automated stuffing tools many times over by the time anyone notices. The security outcome is not determined by whether the credential existed — it existed regardless — but by whether anyone was watching for it and how fast they moved once it appeared.
Where MFA helps and where it doesn’t
Multi-factor authentication meaningfully reduces the blast radius of a stuffed credential, and it should be treated as a baseline control rather than an optional one. But it is not a complete answer. MFA fatigue attacks, SIM-swapping, and session token theft all provide paths around it, and coverage is rarely uniform across an organisation — legacy systems, service accounts, and third-party integrations frequently lack MFA entirely, precisely because they are the systems least likely to be reviewed.
A credential monitoring program does not replace MFA; it addresses the part of the problem MFA cannot: knowing which of your organisation’s credentials are already circulating, before an attacker gets around to testing them.
Building continuous credential monitoring
A functional program has three components working continuously rather than periodically. First, monitoring of breach dumps and criminal marketplaces for the organisation’s domains, so exposure is identified as it surfaces rather than during an annual review. Second, a fast rotation path — a lightweight process that lets IT force a password reset for an exposed account within hours, not the days it typically takes when the request has to move through a change ticket. Third, visibility into where reused credentials would actually grant access, meaning an accurate map of every externally reachable login surface, since a monitoring program is only useful if it is paired with knowledge of what an attacker could authenticate into.
None of this eliminates the underlying behaviour of password reuse, which is a human factor that security teams have limited ability to control directly. What it does is compress the window between exposure and detection, which is the one part of this problem that is genuinely within the organisation’s control — and, in practice, the part that determines whether a breach at an unrelated company stays a footnote or becomes a corporate incident.
Written by Jamal Hashi, CyberPost Advisory.