What to do when an employee's credentials are leaked

An alert confirms what nobody wanted to read on a Tuesday afternoon: an employee's corporate credential is circulating in a public breach dump. The account is still active, it receives legitimate emails and approves access. The question is no longer how it happened, but what you do in the next few hours, because from that moment the problem stops being the leak and becomes everything that happens while the credential is still alive.

The conclusion is direct: when an employee's credential leaks, the clock runs in hours, not days, and the first step is not to change the password but to confirm the real scope of what was exposed. More than 90 percent of successful cyberattacks start with a phishing email, according to CISA, so the way in is almost always a person and their credentials. Containing fast, cutting off access at the root and validating that the behavior does not fail again is what separates a controlled exposure from a bigger breach.

The conclusion in one sentence: the clock runs in hours, not days

A live credential is exploited almost immediately. According to Mandiant's M-Trends 2026 report (Google Cloud), the hand-off time between initial access and the actor who executes the intrusion collapsed from more than eight hours in 2022 to 22 seconds in 2025. When the attacker moves in seconds and the company still reacts in weeks, the defensive window belongs to whoever acts first.

That is why the response cannot be a ticket for the next team meeting. The moves that matter fit in one sentence: confirm the scope of the credential, strip its power (password and sessions), address the person behind the access and validate that the change holds. The rest of this guide develops each of those moves, in the order it makes sense to run them. If you are still in the previous stage, knowing who is exposed before they show up in a dump, that is a different problem we cover in early detection of compromised accounts.

First, confirm the scope of the leaked credential

Before touching anything, you have to understand what exactly leaked. A stale password the person already changed is not the same as the key they still use today to sign in to corporate email. The first question is which account we are talking about and how far it reaches: if that credential opens single sign-on (SSO), the scope is not one application, it is every app hanging off it.

In practice, confirming the scope means answering five things: which credential surfaced, in what service it is used, whether the password is still valid, whether the person reused it between their personal and corporate life, and when it leaked so you can estimate how long it was exposed. That picture defines the blast radius and, with it, the urgency. Acting without that diagnosis leads to changing a password that was not the one that mattered and to calling closed something that is still open.

Reset and session revocation: why changing the password is not enough

Here is the most common mistake of a rushed response. Changing the password blocks a future sign-in, but it does not evict whoever is already inside: open sessions and live tokens keep working even though the new key already exists. If an attacker got in with the leaked credential, they stay in until those sessions are invalidated.

A proper cleanup has several layers. You force the password change, yes, but you also close active sessions, revoke live tokens and OAuth grants, and review what the attacker could have planted to keep access: mail auto-forwarding rules, MFA methods added to the account, app passwords and delegated permissions. Evicting matters as much as blocking the next entry. All of this runs in the company's identity provider, whether Google Workspace or Microsoft 365, and it is the job of the IT team that administers that environment, not of an outside tool.

The person behind the credential: why it repeats if the behavior does not change

A credential does not leak on its own. Behind it there is almost always a behavior: a reused password, a phishing email someone clicked, a weak habit that repeats. Cisco's 90-5-5 framework estimates that close to 90 percent of breaches involve a human factor, and a credential exposed through reuse or a click is that factor in its purest form. Resetting the key fixes today's symptom and leaves intact the pattern that exposed it. We talk about the human factor, not blame: the person is the target of the attack, not the weak link, and treating them as guilty guarantees that next time they will report nothing.

The uncomfortable point is that training for the sake of training does not change behavior either. There is peer-reviewed evidence (Ho et al., IEEE S&P 2025; Lain et al., IEEE S&P 2022) that completing training does not by itself predict a reduction in real failures. What does prove the change is putting the person back into a similar situation and observing how they react. That is why the response to a leaked credential does not end when the account is secure: it ends when the person who exposed it stops being the easiest door.

The first-hours checklist

When the alert comes in, it helps to have the order clear so you do not improvise. These are the first-hours steps, from the most urgent to the one that closes the loop:

Confirm the exposure and its origin: which credential surfaced, in what service it is used, whether it is still valid and when it leaked.

Force a password change on that account and on any service where the same key was reused.

Close active sessions and revoke the tokens and OAuth grants still open, to evict anyone who already got in.

Review what the attacker could have planted: mail forwarding rules, new MFA methods, app passwords and delegated permissions.

Confirm MFA is active and clean, with no methods the person does not recognize.

Review the account's recent activity (sign-ins, sent emails, approvals) in the window from the leak until now.

Log the event with time and owner, and set a remediation deadline for each pending action.

Close the loop with the person: training in the moment and a date to retest their behavior.

The first five steps contain; the last three keep the same gap from reopening next month. The temptation is to stop at step five, when the account already looks safe, and that is exactly where the response is left half done.

How to validate that the response worked (and does not repeat)

Closing the reset ticket is not validation. A response worked when you confirm two different things. The first is technical: that no active session with the old credential remains, that there are no suspicious rules or MFA methods, and that the account no longer shows up as vulnerable in continuous monitoring. The second is behavioral, and it is the one almost nobody measures: that the person who exposed the credential does not fall for the same kind of deception again.

Reacting fast also has a value you can measure. According to IBM's Cost of a Data Breach 2025, the global average cost of a breach was 4.4 million dollars, and that average fell 9 percent from the prior year precisely because organizations identified and contained incidents faster. The honest reading is not that breaches cost less, it is that containing in hours moves the final bill more than almost any other variable. Validating behavior with a fresh test, rather than a course certificate, is what confirms the risk actually went down; that logic of testing again is what we explain in what a retest is and why it proves behavior changed.

This is how human risk management (HRM) applies to a leaked credential: in Fensivo's design, continuous monitoring checks more than 680 public breach databases and the dark web 24/7, and when it detects an exposed credential it triggers an automated response with remediation deadlines, cutting reaction time from months to hours. The reset and session revocation still run in the client's own identity provider; what the platform adds is seeing the exposure early and closing the loop on the person, validating the change with a retest rather than a course completion. You can see how that flow connects in use cases.

How long would it take your company today to learn that an employee's credential is already circulating, and how much longer to make it useless?

Sources and references

CISA (Cybersecurity and Infrastructure Security Agency): more than 90 percent of successful cyberattacks start with a phishing email. https://www.cisa.gov/news-events/news/4-things-you-can-do-keep-yourself-cyber-safe

Cisco, "The 90-5-5 Concept: Your Key to Solving Human Risk in Cybersecurity", May 27, 2025. https://blogs.cisco.com/security/the-90-5-5-concept-your-key-to-solving-human-risk-in-cybersecurity

Mandiant (Google Cloud), M-Trends 2026 Report. https://cloud.google.com/security/resources/m-trends

IBM, Cost of a Data Breach Report 2025. https://www.ibm.com/reports/data-breach

Ho, G. et al., "Understanding the Efficacy of Phishing Training in Practice", 2025 IEEE Symposium on Security and Privacy. https://ieeexplore.ieee.org/document/11023357

Lain, D., Kostiainen, K. and Čapkun, S., "Phishing in Organizations: Findings from a Large-Scale and Long-Term Study", 2022 IEEE Symposium on Security and Privacy. https://ieeexplore.ieee.org/document/9833766