The Offboarding Gap: Why Ex-Employees Still Have Access to Your Systems

Ask a business owner how they'd feel about a former employee still holding a key to the office, and you'll get a straight answer. Nobody's relaxed about that.

Now ask them whether the person who left in March still has a working login to the CRM. The answer usually starts with "well, probably not, I'd have to check" — and that pause is the whole problem.

Offboarding is the most consistently neglected part of IT security in small and mid-sized businesses, and it's neglected for a boring reason: nobody owns it. Onboarding has urgency built in. A new hire can't work until they've got accounts, so somebody makes it happen on day one. Offboarding has no such pressure. The person is gone. Nothing breaks. The accounts sit there, quietly live, indefinitely.

That gap is where a surprising share of incidents start.

Why dormant accounts are worse than they sound

There's a tendency to treat this as a tidiness issue — housekeeping, something to get round to. It isn't. A dormant account is a genuinely dangerous asset for four separate reasons.

Nobody's watching it. An active employee notices when something's wrong with their account. Weird login alerts, password reset emails they didn't request, mail marked read that they never opened. A dormant account has no such immune system. An attacker can sit inside it for months and there's nobody to raise a hand.

The credentials outlive the job. People reuse passwords. That's not a moral failing, it's just what happens. When a former employee's personal password shows up in a breach dump two years later — and it will, eventually — anyone running that dump against your login page gets in, assuming the account still exists and MFA was never enforced.

Departures aren't always friendly. Most people leave without incident. Some don't. Someone let go in a difficult conversation on Friday who still has database access on Monday is a scenario that has ended companies. And the legal position afterwards gets murky fast when you can't demonstrate that access was revoked promptly.

It quietly breaks your compliance story. If you're subject to GDPR, working toward ISO 27001, handling health data under HIPAA, or filling out a cyber insurance questionnaire, "we revoke access on departure" is something you will be asked to prove. Not describe — prove, with dates and logs. Most businesses discover they can't during an audit, which is a bad time to find out.

The accounts everyone forgets

The obvious ones get handled. Email usually gets shut off, sometimes the same day. Where things fall apart is everywhere else — and the list is longer than most people expect.

Identity and email. The Microsoft 365 or Google Workspace account is the front door, and it's the one most likely to get closed. But closing it isn't quite enough on its own. Active sessions can persist even after a password change, so you need to force a sign-out across all devices. Check for app passwords and OAuth tokens the person generated at some point, because those can survive a password reset entirely. Look at mail forwarding rules — a rule quietly copying everything to a personal Gmail is one of the most common ways data leaves a company, and it keeps working long after the account is disabled if you forward the mailbox instead of closing it properly.

Single sign-on, and everything behind it. If you run SSO, disabling the identity provider account kills a lot of downstream access at once, which is exactly why SSO is worth having. But be honest about what's actually behind it. Most SMBs have a mix: some apps in SSO, others with standalone logins created ad hoc by whoever needed them first. Those standalone accounts are invisible to your central process and have to be handled individually.

Business systems. CRM, accounting software, project management, the helpdesk, HR platforms, e-signature tools, the internal wiki. Each of these can hold customer data, financial records, or contract history. Each was probably set up by a different person at a different time.

Cloud infrastructure. If the person touched anything technical, this is the highest-stakes category. AWS, Azure, or GCP console access. IAM users and — crucially — any access keys they created, which authenticate independently of their login and don't care that the human is gone. SSH keys on servers. Database credentials. VPN certificates. Deleting the console user while leaving an active access key in place is the classic version of this mistake, and it's one an automated scan will happily find later.

Code and deployment. GitHub, GitLab, or Bitbucket organisation membership. Personal access tokens. Deploy keys. CI/CD pipeline access. And check whether any pipeline, cron job, or integration was authenticating as that person rather than as a service account — because removing them will break production, and you'd rather learn that on your schedule than at 2 a.m.

Communication tools. Slack, Teams, Zoom. Beyond the obvious access question, there's a data question: what's in their DMs, and do you have a retention policy that covers it? Also worth checking whether they set up any external integrations or webhooks that will keep running.

Shared and service accounts. This is the ugly one. The generic logins — info@, the shared social media account, the account the whole team uses for a vendor portal because the vendor charges per seat. Removing an individual doesn't touch these. If a departing employee knew the password, the password has to change, and everyone still there needs the new one. Yes, it's a hassle. It's also the single most commonly skipped step in the entire process.

Third-party and vendor portals. Bank and payment processor access. The domain registrar. Your DNS provider. Certificate authorities. Ad platforms. Anywhere they were listed as a contact, an admin, or an authorised user. Losing control of a domain registrar account is one of the few IT problems that can be genuinely existential, and registrar access is very often held by exactly one person who eventually leaves.

Physical and device. Building access cards and door codes. Company laptop, phone, and any hardware security keys. Remote wipe capability if the device doesn't come back. And check whether any company data sits on a personal device under a BYOD arrangement.

Subscriptions and licences. Less about security, more about money — but it adds up. Seats on tools nobody reassigned, licences renewing annually for people who left two years ago. Offboarding is when you catch these.

A process that actually works

The reason offboarding fails isn't ignorance. Everyone reading the list above knows those systems exist. It fails because it depends on somebody remembering, under time pressure, on a day when there are other things happening.

So the fix isn't "be more careful." It's making the process not require memory.

Build the inventory before you need it. You cannot revoke access to systems you haven't written down. Sit down once and list every application, service, and portal the business uses, who administers each one, and how access is granted and removed. This is tedious, takes a couple of hours, and pays for itself the first time someone leaves. Keep it somewhere everyone relevant can find it.

Write role-based access templates. Rather than tracking every individual's access ad hoc, define what a salesperson gets, what a developer gets, what a finance person gets. Then offboarding becomes "remove the sales bundle" rather than an archaeology project. It makes onboarding faster too, and it surfaces the accumulated access nobody meant to grant.

Get HR and IT talking on the same trigger. The single most common structural failure is that IT finds out somebody left a week after the fact, from a conversation in the kitchen. Whatever system HR uses to record a resignation or termination should automatically notify whoever handles access. If you're small enough not to have HR software, a shared calendar and a standing rule works fine — the point is that the notification isn't optional.

Separate the timeline into three windows. Not everything happens at once, and pretending it does is how things get missed.

Before the last day, for planned departures: schedule the account actions, work out who inherits their files and their responsibilities, identify any automation running under their credentials, and arrange the handover of anything only they know.

On the last day, ideally within an hour of them leaving the building: disable the identity account, force sign-out everywhere, revoke tokens and keys, collect devices, change shared passwords, and remove building access. Disable rather than delete — you may need the mailbox or the file history later, and deletion can be irreversible in ways that cause problems.

In the following weeks: transfer file ownership properly, reassign licences, verify nothing broke, and after your retention period, actually delete what should be deleted.

Log what you did. Date, systems, who performed each action. This is the part everyone skips and the part auditors, insurers, and lawyers all ask for. A simple spreadsheet is enough. The absence of a record is functionally the same as not having done it, at least in a compliance conversation.

Handle high-risk departures differently. A junior employee leaving amicably for a new opportunity and a senior engineer being terminated for cause are not the same event and shouldn't run through the same process. For a contentious exit, revoke access first and have the conversation second — awkward, but the alternative has consequences that are much harder to undo. Consider preserving logs and mailbox contents before making any changes, and loop in legal if there's any chance of a dispute.

Contractors, freelancers, and everyone in between

Full-time employees at least go through a process. Contractors frequently don't, and that's where the longest-lived orphaned accounts tend to live.

A freelance developer given repository access for a six-week project in 2023 is often still in the organisation today. The marketing agency you stopped working with still has admin on the ad account. The bookkeeper who left has a login to the accounting system nobody thought to close because they were never technically staff.

Two rules fix most of this. Set an expiry date on every contractor account at the moment you create it — most platforms support this, and where they don't, put a calendar reminder on it. And run a quarterly review of every external account, treating anything you can't immediately justify as something to remove.

Audit what you've already got

Everything above prevents future problems. It does nothing about the accounts already sitting there from the last several years.

Start with your identity provider and pull a list of every account, sorted by last sign-in. Anything dormant for ninety days deserves an explanation. Cross-reference against your current payroll — every account should map to a person who currently works there or a documented service account, and anything that doesn't gets investigated.

Then check for the things that aren't user accounts. Cloud access keys and their age. Personal access tokens in your code platform. OAuth applications with permissions on your Workspace or 365 tenant. Mail forwarding rules across all mailboxes, which is worth doing periodically regardless. Shared passwords that haven't rotated since someone left.

Expect this first audit to be uncomfortable. Almost everyone finds something they didn't know about — usually several somethings. That discomfort is the point; better you find it than someone else.

The one control that covers your mistakes

You will miss an account eventually. The process will fail at some point, because processes involving humans always do.

Multi-factor authentication is what turns that failure from a breach into a non-event. A dormant account with a stolen password and no second factor is an open door. The same account with MFA enforced is, for the overwhelming majority of attackers, not worth the effort.

If you take one thing from this: enforce MFA on every account that touches business data, especially email, cloud infrastructure, and financial systems. It won't fix your offboarding process. It will substantially limit what a broken offboarding process can cost you.

Where to start this week

If the list in this article felt overwhelming, do three things and you'll have removed most of the risk.

Pull the last-sign-in report from Microsoft 365 or Google Workspace and disable anything dormant that you can't account for. Write down every system your business uses and who administers it. And set a rule that HR notifies IT the same day someone gives notice, with no exceptions.

That's an afternoon's work, and it closes the gap that most breaches of this kind walk straight through.

At Lunara Limited, we build and run offboarding processes for growing businesses — including the initial audit of what's currently open. If you're not certain who still has access to your systems, that's exactly the question worth answering before somebody else answers it for you.