Fired an Employee? Here's What Most Companies Forget to Revoke
An employee leaves your company. Maybe it was amicable, maybe it wasn't. Either way, IT gets the ticket: disable the account. Someone clicks the button in Active Directory or Google Workspace, the account goes dark, and everyone moves on.
Except the problem is far from solved.
Disabling an AD or Google account is step one. It is not the finish line. And treating it like the finish line is one of the most common security gaps we find during access reviews.
The Scope of the Problem
Think about how many systems a single employee touches over the course of their tenure. It is not just email and a laptop. A typical knowledge worker at a mid-sized company interacts with 20 to 50+ distinct systems, services, and platforms during their employment.
Some of those systems federate authentication through your identity provider. When the AD account dies, access to those systems dies with it. Good. But many others do not. They have their own credentials, their own tokens, their own keys. And those survive long after the employee has turned in their badge.
The uncomfortable truth: Most organizations have no centralized inventory of every system an employee has accessed. Without that inventory, your offboarding process is a best-guess exercise at best and a security liability at worst.
What Gets Forgotten
Here is the access that most companies miss when an employee departs. Every single one of these is something we have found still active during real-world access reviews.
SSH Keys on Servers
Developers and sysadmins add their public keys to authorized_keys files on production servers, jump boxes, and bastion hosts. These keys almost never get rotated during offboarding. The former employee can still SSH directly into your infrastructure from their personal machine, completely bypassing your identity provider.
API Tokens and Service Account Credentials
Engineers create API tokens for integrations, automation scripts, and internal tooling. These tokens are often long-lived, stored in config files or environment variables, and tied to the individual rather than a service account. When the person leaves, the tokens keep working. Indefinitely.
Personal Access Tokens on Code Platforms
GitHub, GitLab, and Bitbucket personal access tokens grant read and write access to your repositories. Disabling the user's SSO session does not invalidate existing PATs in many configurations. A former developer could still clone your proprietary codebase, push malicious commits, or access private repos weeks after termination.
SaaS Application Access
Slack, Notion, Figma, AWS Console, Jira, Confluence, Datadog, Sentry, HubSpot, Salesforce. The list goes on. Any SaaS platform where the employee created a direct login with a password, rather than going through SSO, will continue to work. Some of these platforms contain customer data, financial records, or infrastructure credentials.
Shared Passwords in Password Managers
If your team shares credentials through a password manager, the departed employee likely has those passwords memorized or backed up. Shared WiFi passwords, service account credentials, admin panels, vendor portals. All of it. Removing their vault access does not erase what they already know.
VPN Certificates and Configs
VPN client certificates, WireGuard configs, and OpenVPN profiles may still be sitting on the former employee's personal device. If your VPN authenticates based on certificates rather than (or in addition to) AD credentials, revoking the AD account does not kill VPN access. They can still tunnel into your corporate network.
CI/CD Pipeline Access
GitHub Actions secrets, Jenkins credentials, CircleCI environment variables, deployment keys. CI/CD systems are loaded with sensitive credentials. If the former employee had admin access to these pipelines, they may have had visibility into production database passwords, API keys to third-party services, and cloud provider credentials. Even if their access is revoked, those secrets may need to be rotated.
Personal Devices Enrolled in MDM
BYOD policies mean personal phones and tablets are often enrolled in your MDM solution with access to corporate email, internal apps, and company data. Disabling the AD account may or may not trigger an MDM wipe, depending on your configuration. You need to verify this explicitly for every departure.
Email Forwarding Rules
A disgruntled employee can set up a forwarding rule on their mailbox before they leave, sending a copy of every incoming email to a personal address. If you disable their account but do not check for forwarding rules first, sensitive communications may continue leaking to an external address. This is especially common in contentious terminations.
MFA Tokens and Backup Codes
If the employee enrolled a personal authenticator app or saved backup codes, those might still work for services that do not strictly tie MFA to the disabled identity provider account. Hardware security keys issued by the company need to be collected. TOTP seeds registered on personal devices need to be deregistered from each individual service.
Why This Matters More Than You Think
In amicable departures, residual access is a compliance issue. In contentious terminations, it is an active threat vector.
Consider the scenario: An engineer is let go during layoffs. They are upset. They still have a valid SSH key on three production servers, a GitHub PAT with write access to your main repository, and AWS credentials cached in their terminal. None of these were revoked because your offboarding checklist only covers AD and laptop collection.
This is not hypothetical. Insider threat incidents involving former employees make headlines regularly. In many cases, the access used in the attack was access that should have been revoked on day one but simply was not on anyone's list.
The risk compounds over time. Every employee who left without a thorough access review adds another layer of unmanaged credentials to your environment. After a few years of turnover, you may have dozens of former employees with some residual access to your systems, and no way to know which ones without a comprehensive audit.
What a Proper Access Review Looks Like
A real offboarding access review goes far beyond the AD disable button. It requires a systematic approach that covers every category of access an employee may have touched.
Complete Offboarding Access Checklist
Building a Sustainable Process
Having a checklist is a start, but it only works if someone actually follows it every time. The most resilient organizations we work with do three things well:
- Maintain a living access inventory. Every time a new tool, server, or service is provisioned, it goes on the list. Every time an employee is granted access to a new system, it is recorded. This turns offboarding from detective work into a straightforward deprovisioning exercise.
- Conduct periodic access reviews. Do not wait for someone to leave to discover what they have access to. Quarterly access reviews catch orphaned accounts, excessive permissions, and forgotten service accounts before they become a problem.
- Treat offboarding like an incident. Especially for contentious terminations, the offboarding process should be time-boxed and thorough. Access should be revoked within hours, not days. Logs should be reviewed. And someone should verify that every item on the checklist was actually completed.
If you are not sure whether your offboarding process covers all of these areas, or if you suspect there are former employees with residual access in your environment, an independent access review can give you a clear picture of where you stand and what needs to be fixed.
Not Sure What Former Employees Still Have Access To?
Our access review service maps every credential, token, and permission in your environment and identifies exactly what should have been revoked but was not.
