According to Verizon's 2026 Data Breach Investigations Report — the annual study that analyzed more than 22,000 confirmed data breaches across 145 countries between October 2024 and November 2025 — exploiting technical vulnerabilities is now the most common way attackers get in. But the report also isolates a category of its own, privilege misuse: someone using an access they already had inside the organization, not breaking in from outside. It accounted for 3% of confirmed breaches in the 2026 dataset.
The number looks small next to others. But it describes exactly the most common situation when a company treats offboarding as an HR matter: the badge goes back at the front desk, the paperwork is signed, and nobody tells anyone that access to email, the sales system, the hosting panel, or the team's messaging group is still standing. Sometimes for weeks. Sometimes for years.
A salesperson who left in March and could still open the price sheet through the old account in July isn't a rare case or an exotic misconfiguration. It's the normal result of a process that never existed on paper: nobody decided who gives notice, when, and exactly what needs to be cut off. For the person who approves the budget and for whoever handles IT without much experience, that's the question worth more than any new tool: if someone left today, who would know how to list everything that person can still reach?
Accounts nobody remembered to close
Microsoft, the maker of the system most companies use as their directory of users and passwords, describes the moment someone leaves as its own phase in the lifecycle of any account inside an organization — alongside joining and changing roles. According to the product's official documentation, the goal of that phase is easy to state and hard to meet: making sure that people no longer tied to the company, whether through termination, resignation, or retirement, have their access revoked in a timely way.
The problem is that "revoking access" is never a single action. At a small or mid-sized company, the same person typically has an account in the directory of users and passwords, their own email inbox, a login to the sales or management system, access to the website or hosting panel, membership in messaging groups with clients, and often, knowledge of at least one password the whole team shares. Each of those systems has its own off switch — when it has one at all.
Without a list drawn up beforehand of which systems each role reaches, nobody can revoke "everything": the phrase has no reference to be checked against. That's why offboarding, in practice, turns into an attempt to remember by heart — and memory is the worst place to keep a list of critical access.
The hardest case on that list is usually the team's shared password: the one for the company's social media profile, for a vendor's system, for the router. It doesn't belong to one person, so "revoking" it isn't switching off an account — it's changing a password that several people still use every day, and changing it always inconveniences whoever stays.
Offboarding treated as an HR-only matter
The common way of handling this splits one conversation into two that should be a single one. HR handles what's theirs: notice period, severance, badge and equipment return. IT — when there's someone dedicated to it — finds out about the departure whenever someone remembers to mention it, sometimes days later, sometimes only when a client or coworker notices something odd.
That split makes sense at large companies, where HR systems and identity systems talk to each other. At a small company without that integration, it turns into a gap: the formal process ends, but the technical one stays incomplete. The account in the directory of users and passwords keeps working because nobody asked to disable it; remote access to the server stays open because it was on a list only one person ever saw.
There's also a bias that makes things worse: calm departures get less attention than messy ones. When someone leaves on good terms, the sense of urgency disappears — "they wouldn't do anything wrong" — and cutting off access gets pushed to later, which often never comes. The risk, though, doesn't depend on the intentions of the person who left: an active account can be used by anyone who finds the password, including someone who never worked there at all.
What has to be in place
Safe offboarding rests on verifiable mechanisms, not on the goodwill of whoever remembers to give notice.
A per-person access list, built the day someone joins, not the day they leave. Each role has a predictable set of systems — the directory of users and passwords, email, the sales system, hosting, messaging groups. Recording that at hiring is what makes it possible to check everything at departure, instead of trying to reconstruct it from memory.
A departure notice that reaches HR and whoever handles IT at the same time. The trigger is a single event, communicated both ways at the same moment — not an HR email that someone will forward along "whenever."
System-by-system revocation, with a checklist, not one single switch. There's no button that turns everything off at once across a structure with several vendors. What exists is a short, specific list, checked one item at a time until it's done.
The team's shared password changed the same day, not just crossed off a list. If the person who left knew a shared login, the only way to close that access is to generate a new password and hand it to whoever still needs it — giving notice beforehand, so no one gets locked out mid-task.
A second confirmation step beyond the password on the most critical systems. It doesn't replace revocation, but it limits the damage if an old password leaks out for any reason, because it demands a second confirmation the deactivated account can no longer give.
Periodic review of who still has access to each system, not just when someone leaves — to catch what was left behind from old departures before it turns into an unpleasant discovery during an audit.
This is how Skills IT works: a departure notice comes in as a single ticket for the support team, revocation follows a per-system checklist, and a shared team password gets changed the same day — never just crossed off a list nobody checks again.
What the company gains when offboarding becomes a process
The most immediate gain is the easiest to explain: a price list, a customer base, or a contract doesn't circulate through the account of someone who no longer answers for anything at the company. That holds whether the person left on good terms or in conflict — and it's precisely in the second case that the process matters most, because that's where the goodwill of "they wouldn't do anything" stops working as a guarantee.
There's also a time gain for whoever handles IT. Without a prior list, every departure turns into an investigation: figuring out which systems the person had an account in, hoping nothing gets missed, checking afterward whether anything was left over. With a checklist ready, the same departure turns into a ten-minute review.
And there's a gain in audits. Microsoft's own identity governance documentation points out that excess, unused access is by itself grounds for an audit finding — a sign of a lack of control over who has access to what, regardless of whether any incident ever happened. A company that reviews this periodically walks into those conversations with an answer ready, instead of discovering the problem alongside the auditor.
None of this depends on assuming former employees act in bad faith. It depends on treating access as something that needs an owner and a deadline — because a forgotten account is a risk even when no one ever uses it for anything.
A checklist for the next departure
Before the next departure happens — friendly or not — it's worth having this agreed between leadership, HR, and whoever handles IT:
- Get the list before announcing the departure. Before communicating the departure, list what that person accesses: email, the sales system, hosting, messaging groups, any shared team password they know.
- Set the exact cutoff time, not just the day. Deciding "today" without deciding "at 5pm sharp" leaves an open window — usually the weekend or overnight — during which the account keeps working and nobody is watching.
- Change, don't just remove, the shared password. If the team uses a collective login, this is the moment to generate a new one and notify whoever still needs it, rather than hoping the person who left won't use it anymore.
- Confirm system by system, one at a time. Email, the directory of users and passwords, the sales system, the vendor's panel, remote access. If that list doesn't exist yet, this departure is the time to start writing it.
- Use the moment to ask who else has that same access. Departures often reveal a generic account or a shared password nobody remembers the reason for anymore — worth reviewing while the subject is already on the table.
