An alert lands on your inbox: 5 corporate logins found in a stealer log, one of them an admin account. Your team does what the playbook says. Reset the passwords. Force MFA re-enrollment. Send the security awareness reminder.
Three days later, data leaves the network from an IP nobody recognizes.
The passwords were changed. The session cookies on the laptop that leaked them were not. Neither was the laptop.
This is the part most advice about compromised credentials skips. The industry treats them as an identity event, so the response lives entirely in the identity stack: reset, revoke, re-enroll, enable conditional access. All of that is necessary. None of it touches the endpoint where the credential was harvested, which is usually still checked in, still enrolled, and still holding everything the attacker needed in the first place.
What are compromised credentials?
Your monitoring tool says fourteen credentials; it doesn't say whether anyone has used them. A compromised credential is a username and password pair an unauthorized party controls and can use to authenticate. A leaked credential has been exposed (breach dump, paste site, stealer log) but not yet weaponized. Leaked means a clock is running. Compromised means it already ran out.
The distinction sounds academic until you're triaging forty alerts with two people. Leaked credentials for a decommissioned SaaS account and a compromised credential for an account with access to your file server are the same row in most dashboards and completely different incidents in practice. If your triage process doesn't separate them, everything gets treated as urgent, which in a lean team means nothing does.
Telling them apart is usually fast. Pull the sign-in logs for the account in your identity provider and look for authentications you can't attribute: unfamiliar IP ranges, sign-ins outside working hours, impossible travel, new device registrations, MFA prompts the user didn't answer. If the credential appears in a dump and the account shows no unattributed activity, you're containing an exposure. If it shows activity, you're running an incident.
One more thing worth naming early: credentials rarely leak alone. A stealer log typically contains the saved passwords from a browser profile, the autofill data, and the active session cookies from the same machine. That bundle is why "just change the password" is incomplete advice, and it's a thread that runs through the rest of this article. If you want the longer version of how that data moves once it's out, we covered how stolen credentials travel through the dark web separately.
How do credentials actually get compromised?
Ask ten IT teams where credentials come from and nine will say phishing; the logs often say otherwise. Corporate credentials get compromised four main ways: infostealer malware harvesting saved logins and cookies directly from a device, phishing and business email compromise, third-party breaches combined with password reuse, and credentials that were weak or shared from the start.
Infostealer malware
This is the vector that has changed most. A user installs a cracked utility, a fake browser extension, or a "codec" from a search ad. The malware runs once, dumps every credential saved in the browser profile, grabs the session cookies, exfiltrates the lot, and often removes itself. There is no ransomware note, no locked screen, no ticket. The first signal is a monitoring alert weeks later. And because it harvests cookies alongside passwords, the attacker can frequently skip authentication entirely.
Phishing and business email compromise
Still effective, particularly against finance and HR. The modern versions proxy the real login page in real time, which means one-time MFA codes get relayed along with the password. If you want the anatomy, we broke it down in the piece on phishing and spear phishing.
Third-party breaches and password reuse
The quiet one. A marketing coordinator used her work email on a design tool that got breached two years ago, with a variation of her corporate password. Attackers don't test the exact string; they test permutations. Services like Have I Been Pwned will tell an individual whether their address appears in a known dump, but they won't tell you which of your 400 employees reused a password afterward.
Weak and shared credentials
The service account nobody owns, the shared vendor login in a spreadsheet, the local admin password that's identical across the fleet. These never had protection to lose, and they are the ones that survive every rotation policy because nobody remembers they exist.
What compromised credentials cost an organization
The cost isn't the password. It's everything the password was standing in front of. Account takeover is the immediate outcome, but it's rarely the end of the attack: a single valid credential turns an outsider into an insider, and from there the work becomes lateral movement, looking for the next set of credentials cached on the machine.
Then there's the exposure question, which is where legal gets involved. If a compromised credential could reach personal data, you may have a notification obligation on a short clock: GDPR Article 33 gives you 72 hours from awareness, and HIPAA has its own timelines when PHI is reachable. The practical problem is not the deadline. It's that the IT manager on the call cannot answer "what could this account actually see?" fast enough to make the call, because that answer depends on access mapping you either did in advance or didn't.
Finally there's direct fraud: payment redirection through a compromised finance mailbox, invoice manipulation, fraudulent purchases. These get caught by accounting rather than by IT, which usually means weeks have passed. A compromised credential is one of the most common entry points for a data leak, not a separate category of problem, and the same reasoning drives broader data breach prevention.
How do you detect compromised credentials?
Most organizations find out from someone else: a partner calls, a vendor's breach notice arrives. Detection works in three layers. Dark web and stealer-log monitoring tells you what leaked. Identity provider anomaly detection tells you whether it's being used. Endpoint telemetry tells you where it leaked from. Most programs run the first two and skip the third.
Layer one: what leaked
Credential monitoring services scan breach dumps, paste sites, criminal marketplaces, and stealer-log feeds for your domains. The useful ones score by recency, because a credential that surfaced last week is a different problem from one that surfaced in 2021. Recency is the signal that actually drives priority. If you're evaluating options, we maintain a comparison of dark web monitoring tools, plus a walkthrough of dark web monitoring for business.
Layer two: whether it's in use
This lives in your identity provider. Impossible-travel alerts, sign-ins from unfamiliar ASNs, new device registrations, MFA fatigue patterns, sudden mailbox rule creation. Turn these on before you need them; retroactive detection is not a feature.
Layer three: where it came from
This is the layer almost nobody runs. Take your list of exposed credentials and cross-reference it against devices with malware detections, devices missing recent patches, and devices that have gone quiet. When the same user shows up in both lists, you've found the source rather than just the symptom. For the individual-account version of these signals, we listed them in the warning signs of a hacked account.
Quick win: Export your last 90 days of endpoint malware detections and compare the user list against your credential exposure alerts. Any name on both lists is a device that needs to be treated as the source, not just a user who needs a password reset.
The first 24 hours: containing a credential compromise
A helpdesk tech gets the alert at 9:15 and starts resetting passwords at 9:20. Right instinct, wrong first move. Containment runs in three moves, in order: revoke active sessions and tokens, isolate the device associated with the exposure, then investigate scope. Resetting before revoking tells the attacker you noticed while leaving their existing access intact.
First hour: revoke, then reset
Revoke all active sessions for the affected accounts in your identity provider. Revoke OAuth tokens and app passwords, which survive password changes by design and are the single most commonly missed step. Then reset the credential and require MFA re-enrollment. If the account has admin rights, remove them temporarily; you can restore them after scope is clear.
Same hour, in parallel: lock the device
If the credential came out of a browser profile, that machine is evidence and it's also a live foothold. Locking it costs you an annoyed user for an afternoon. Not locking it costs you the rest of this incident.
Hours 2 to 24: scope, persistence, evidence
Pull sign-in logs for the affected accounts going back at least 90 days and flag anything unattributed. Check for persistence: new mailbox forwarding rules, new MFA methods, new app registrations, new API keys. Capture the device state before you clean it, because once you reimage, your evidence is gone. Then document the timeline: when the credential was exposed, when you detected it, when you revoked, when you locked the device, what the logs showed
That last part is what an auditor asks for and what most teams reconstruct badly from memory two weeks later. If you want the fuller response walkthrough, we covered it in how to respond to a credentials leak.
Quick win: Write down the exact click path in your identity provider for "revoke all sessions" and "revoke OAuth tokens" and pin it where your on-call can find it. Under pressure, nobody goes looking through admin menus.
Why resetting the password isn't containment
An MSP in the US put it plainly: "Even after disabling a user's account, employees can still delete data stored locally due to cached credentials." A password reset invalidates future authentication. It does not invalidate what is already running: active session cookies, OAuth tokens, app passwords, and cached domain credentials that permit offline login all survive it.
And the malware that harvested the credential in the first place is still on the device, ready to harvest the new one.
Take the offboarding version, because it's the most common. An employee leaves on a Friday. HR disables the account the same afternoon. The laptop is scheduled to ship back Tuesday. On Monday, files disappear from a locally synced folder. Nobody's account was compromised in the classic sense: the cached credential simply allowed an offline login, and the local files were never protected by the thing that was disabled.
The fix is sequencing. Account disablement and device lock belong in the same window, not in the same general week. Chris D., a mid-market IT manager, described the working version on G2: "Prey helps to protect our mobile assets not just from theft but also insider threats associated with users... We are able to lock the device as soon as we are notified." The operative words are as soon as we are notified, not when the device comes back.
The other half of this is encryption. If full-disk encryption is enforced and verified, an offline login attempt on a recovered device is a much smaller problem. If encryption status is "unknown" across part of your fleet, you don't have a control, you have an assumption. We covered the operational side of that in device encryption, and the wipe-versus-reimage decision in the complete guide to factory reset.
Quick win: Pick your last three offboardings and check the gap between account disablement and device lock. If it's measured in days, that's your exposure window, and it's the same window an attacker gets after a credential leak.
How endpoint visibility platforms close the credential gap
Once you accept that credential compromise is partly an endpoint event, the tooling question changes. You need three capabilities working together: exposure detection, so you know which credentials are out; device location and inventory, so you can reach the machine involved; and remote actions, so you can lock, wipe, or verify encryption without waiting for the device to come back.
Prey covers this span in one console. Breach Monitoring surfaces which of your organization's credentials appear in dark web sources and scores them by how recently they were exposed. Prey Tracking gives you the location and check-in history for the device tied to the exposure. Prey Protection handles containment: remote lock, remote wipe, and encryption status verification across Windows, macOS, Linux, Android, iOS, and Chromebooks.
In practice the sequence looks like this: the alert names an exposed credential, you identify the user's device, you lock it from the console while the identity team revokes sessions, and you decide from there whether it comes back for reimaging or gets wiped in place. Prey holds a 4.7 out of 5 rating across 57 reviews on G2 (2026), and Tim P., a small-business owner, put the wipe decision plainly there: "It's nice to know if a device goes rogue I can just wipe it and let the police recover them later. Our IP is worth worlds more than a phone or laptop."
Same incident, two clocks, both stopped.
How to prevent credential compromise
Prevention advice for this topic usually arrives as a list of password rules, which is roughly the least effective item on the list. The controls that actually move the number assume a credential will leak eventually: phishing-resistant MFA, a managed password manager, rotation on exposure, ownership of service accounts, and endpoint hygiene.
Phishing-resistant MFA
Passkeys or FIDO2 security keys defeat the real-time proxy phishing that beats one-time codes. CISA's implementation guidance ranks these above app-based and SMS codes for exactly that reason. Start with admins, finance, and anyone with access to customer data.
A managed password manager
This matters more than complexity rules. It kills reuse structurally rather than through policy reminders, and it gets credentials out of browser profiles, which is precisely what infostealers target.
Rotate on exposure, not on a calendar
Ninety-day forced rotation produces predictable increments and helpdesk tickets. NIST SP 800-63B explicitly recommends against periodic rotation and calls for a change only when there is evidence of compromise. Rotate when a credential appears in a dump, when someone leaves, when a device is compromised.
Fix the service and orphan accounts
Inventory every non-human account, assign an owner to each, and delete what nobody claims. When a sysadmin leaves and nobody inherits the integration account they built, that credential outlives everyone who knew the password.
Treat endpoint hygiene as credential hygiene
Restrict local admin rights so users can't install the utility that steals the browser profile. Keep browsers patched. Know which devices haven't checked in for 30 days, because a silent device is a device you can't clear. For the attack-specific defenses, we go deeper in credential stuffing attacks and in the wider taxonomy of credential-based attack techniques.
Quick win: Pull a list of accounts with local admin rights on their primary device. Anyone on it who doesn't need it for their job is an infostealer install away from becoming your next credential incident.
Closing the loop on credential exposure
Credential compromise gets handled as an identity problem because that's where the alert appears and that's where the fix feels complete. Reset, revoke, re-enroll, close the ticket.
But credentials don't leak from directories. They leak from devices: from a browser profile on a laptop, from a session cookie on a machine that's still enrolled, from a cached domain credential on a device sitting in someone's apartment. If the response stops at the account, the door you closed wasn't the one that was open.
The practical version is one line in your incident checklist. Next to "reset password and revoke sessions," add "identify and lock the associated device." Then check whether you can do that today: can you find the machine, lock it remotely, confirm its encryption status without physical access? If the answer is "it depends," that's the gap, and it's the same gap whether the incident is a stolen laptop or a stolen password.
Frequently asked questions about compromised credentials
What do compromised credentials mean?
Compromised credentials are login details (typically a username and password) that an unauthorized party controls and can use to authenticate as the legitimate user. They differ from leaked credentials, which have been exposed but not yet used. Compromised credentials frequently include session cookies and tokens harvested at the same time, which is why changing the password alone may not remove the attacker's access.
What is the most common way credentials get compromised?
Infostealer malware has become one of the largest sources of corporate credential exposure. It runs once on a device, extracts every credential saved in the browser profile along with active session cookies, exfiltrates them, and often deletes itself. Phishing and business email compromise remain significant, as does password reuse combined with third-party breaches.
How can businesses detect leaked credentials?
Use three layers together. Dark web and stealer-log monitoring identifies which corporate credentials have been exposed and how recently. Identity provider anomaly detection (impossible travel, unfamiliar sign-in locations, new device registrations) shows whether an exposed credential is being used. Endpoint telemetry identifies which device the credentials came from, which is the layer most programs skip.
How do I track compromised credentials?
Maintain a single record per exposure with four fields: which credential was exposed, where it surfaced and when, whether the identity provider shows unattributed activity, and which device it likely came from. Credential monitoring platforms handle discovery and scoring automatically; the device attribution requires cross-referencing exposure alerts against endpoint inventory and malware detections.
How do vendor credentials get compromised?
Vendor and third-party credentials are compromised through the vendor's own breaches, through shared logins stored in spreadsheets or ticketing systems, and through service accounts that are never rotated because no internal owner is assigned. Because these credentials often carry elevated or persistent access, treat them as higher priority than standard user accounts during exposure triage.
Is resetting the password enough after a credential leak?
No. A password reset prevents future authentication with the old credential but does not invalidate active session cookies, OAuth tokens, app passwords, or cached domain credentials, all of which can keep working afterward. Full containment requires revoking sessions and tokens, resetting the credential, and locking or reimaging the device the credential came from.
See which credentials are already out, and which devices they came from
Prey combines dark web credential monitoring with device location and remote lock, so the same console that flags the exposure lets you contain the endpoint behind it. Get started with Prey.
