Secure offboarding: the human risk of the departing employee

The conclusion in one sentence: the risk does not end on the last day

Secure offboarding is settled on the day someone leaves, in three moves: revoke every access the person held, review whether their credentials were already exposed before they left, and confirm afterward that no access stayed alive. The first step is the inventory, not the farewell party. Before the person hands back the laptop, someone has to know exactly which systems they logged into, with which accounts, and from which devices. Everything else hangs off that list.

We say "the same day" because the risk window opens the instant the relationship ends and the account is still active. This is not an administrative errand that can wait for month-end close. It is a security task with a clock, and the clock runs in favor of whoever wants to use an account that should no longer exist.

Why the departing person's credentials are still your problem

The uncomfortable part of offboarding is that the biggest risk is not created by the departure; the departure only reveals it. Many of those accounts were already compromised before the person announced their resignation, because their email or password had shown up in some third party's breach months earlier. The day they leave, that credential loses the one person who was watching it and becomes a key left in the lock.

This connects to the root of the problem. Cisco's 90-5-5 framework estimates that close to 90 percent of breaches involve a human factor, and a reused credential from a former employee is exactly that: not a technical flaw, but a human surface left open. We prefer not to talk about anyone's "mistake" here, because the person who left did nothing wrong. What failed, if anything failed, is the process that was supposed to close the door behind them.

There is a detail that makes this worse: the password the person used at work is usually the same, or a close cousin, of the one they use across dozens of personal services. If that credential ever leaked, revoking only the corporate access is not enough. That is why offboarding starts before the departure, by checking which of that person's credentials are already circulating, something you only know with dark web and breach-database monitoring.

Seen this way, offboarding is the mirror of onboarding. If a new hire's first 30 days define the exposure they walk in with, the last ones define the exposure they leave behind. We are careful about the entrance and careless about the exit, and yet the exit is the one that happens in silence, with no one new to welcome and no announcement email to remind anyone of the task.

The access nobody revoked: the window the attacker looks for

The account that survives the departure is the prize, because it arrives with trust built in. An attacker who gets in with the credentials of someone who "works here" does not trip the same alarms as an unknown intruder, and moves through systems that person had permission to use. Email is still the most common way to reach that credential: according to CISA, more than 90 percent of successful cyberattacks begin with a phishing email, and that email does not tell the difference between an active employee and an account that should have been closed last week.

Speed is what makes this urgent. According to Mandiant's M-Trends 2026 (Google Cloud), the time between initial access and the actor who executes the attack collapsed from more than eight hours in 2022 to twenty-two seconds in 2025. Translated to offboarding: if a departing person's credential is alive and exposed, there is no room for "we will review it Monday." It is exploited almost immediately. The window we think we have does not exist.

The favorite orphan accesses are the ones nobody remembers: the account for a tool a team signed up for on its own, access to a code repository, the key to a cloud service shared in a chat a year ago, the login of an external vendor still holding permissions. None of them shows up in the main directory, which is why none of them gets revoked in the standard exit.

High-exposure roles: what to test before the departure

Not every departure carries the same weight, and treating them all the same wastes effort where it is not needed and skimps on it where it is. Whoever administers systems, handles finances, has access to customer data, or can authorize payments leaves with the keys to the most expensive rooms in the house. Their offboarding deserves a deeper review than that of someone with access to an inbox and a couple of documents.

The question that sets the priority is not "what was their title" but "what could they reach and what could they authorize." An analyst with no flashy title but access to the customer database is a high-exposure role. A manager with a big title but no critical access, not so much. Exposure is measured by what the account could do, not by the org chart.

For these roles, it is also worth looking at behavior before the departure, not only after. If the person who administers the servers falls for a phishing email in their last few weeks, that compromised credential leaves with them and keeps working. Testing how high-exposure roles respond under pressure, while they are still in the company, is part of an offboarding that thinks about risk and not only about paperwork.

The secure-departure checklist

A secure departure is executed in concrete steps, in order, with someone responsible for each one. This is the minimum sequence:

Build the access inventory before the last day. List every system, application, cloud account, repository, and external service the person could enter, including the ones that do not go through single sign-on. What is not on the list does not get revoked.

Check whether their credentials were already exposed. Before closing anything, verify whether that person's email or passwords appear in known breaches. An already-leaked credential is not solved by deleting the corporate account, because it stays alive in other services.

Revoke access the same day, not later. Disable the accounts, close open sessions, and rotate the shared keys the person knew. Closing the main account does not close sessions already open, nor the keys that lived in a shared document.

Reassign, do not delete blindly. The person's data, email, and files move to an owner before the account is disabled. Deleting first and searching later is how information gets lost and how someone "needs to reactivate the account for a bit," which is exactly what opens the window again.

Close physical and third-party access. Cards, office badges, vendor-platform accounts, and any permission granted in the person's name on an external service.

Keep a record of who revoked what and when. The record is what lets you confirm, weeks later, that the process was completed and no loose end remained.

How you validate that the process worked

Running the checklist is not the same as being sure it worked, and that difference is where breaches live. Ticking every box on an exit form gives a sense of control that reality does not always back up: the account thought to be disabled was still active in a secondary system, the shared key was never rotated, the vendor's access was overlooked. The only way to know is to look again.

Validating means confirming, some time after the departure, that none of that person's credentials still work in any system, that their access did not reappear through a temporary reactivation nobody reversed, and that their exposed credentials stopped being an entry point. It is the same logic peer-reviewed evidence applies to training: there is research (Ho et al., IEEE Symposium on Security and Privacy 2025) showing that assuming a change is not the same as verifying it. Completing the process does not prove the risk was closed; checking it again does.

And that validation is not a one-time event. An account can be disabled today and reappear tomorrow because someone reactivated it to "recover a file." Secure offboarding does not end when the form is signed; it ends when you confirm, more than once, that the door is still closed.

At Fensivo we work on two pieces of this problem. We continuously monitor whether the credentials of a company's people, including those who already left, show up exposed in data breaches, so a leaked credential does not remain an open entry point. And we test how high-exposure roles behave under pressure while they are still in the company, with email phishing simulations and a follow-up validation that confirms behavior changed. You can see how we approach this case in our use cases.

Could you say, right now, how many accounts belonging to people who no longer work at your company are still active, and how many of their credentials are circulating out there with nobody watching them?

Sources and references

• CISA, "4 Things You Can Do To Keep Yourself Cyber Safe": 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", 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
• 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