The employee who left and still has a login

A departed employee's login stays dangerous until every system that issued it is removed. Offboarding staff system access means revoking email, file shares, SaaS seats, SSH keys and VPN rights in one checkable sequence — not just disabling the directory account. One missed credential can sit open for months.

Key Takeaways

• A disabled directory account does not revoke SaaS seats, SSH keys or app-specific logins.
• Offboarding is a revocation sequence across every credential store, not a single toggle.
• Build the access inventory before the person leaves, and rebuild it after.
• Group-based access and SSO shrink the number of places a credential can outlive a leaver.
• Verify by attempting the old login, not by trusting the admin console.
• Re-check thirty days later; restoration errors and forgotten keys surface slowly.
• A written checklist turns a panic into a repeatable thirty-minute job.

Why does a departed login stay dangerous after the directory account is disabled?

A directory disable stops future sign-ins through that identity provider, but it does not reach systems that keep their own credentials. Long-lived tokens, API keys, SSH keys and SaaS passwords keep working until individually revoked. Offboarding staff system access is therefore a revocation sweep across every credential store, not one directory action.

The risk is not only a resentful former employee. A login that outlives a departure becomes an orphaned account: nobody owns it, nobody watches it, and its password stops being rotated. If that password was reused — and most are — a breach at an unrelated service later hands an attacker a working key to your systems. This is also a compliance question. SOC 2, ISO 27001 and client contracts usually require access removal within a defined window, often 24 hours for privileged accounts. The mechanism is simple: every identity layer must be told separately that the person no longer works here. Until each one is updated, the old identity stays partly alive.

Where do the leftover logins actually hide?

Start the sweep with an inventory of every system the person touched. The usual hiding places are the directory itself, email, file shares, SaaS seats, source repositories, CI/CD credentials, SSH keys, VPN profiles and shared password vaults. A checklist of ten categories catches more than any single admin page shows.

Email is the obvious first stop, but the dangerous ones are quieter. Shared entries in a password manager survive unless someone edits the item. Deploy keys in GitHub or GitLab stay valid after the directory account is gone. A leftover API token in a CI/CD pipeline can keep pushing code under a name that no longer maps to a human. MFA backup codes on a personal phone are effectively impossible to revoke once the person leaves, which is why MFA should be reset before the account is disabled. Keep a per-employee access list in the directory description or a wiki page, updated whenever a new tool is adopted. When someone hands in notice, that list becomes the offboarding checklist.

What does a proper offboarding sequence look like?

A reliable offboarding sequence starts before the last day, with a list of every credential the person holds. Then you revoke access in order of external reach: VPN and remote access first, then SaaS and email, then directory and keys. Finally, you verify each system rejects the login.

The order below assumes a typical small or mid-size business with Microsoft 365 or Google Workspace, a few SaaS tools, a git repository and a server or two. Adapt it to your own estate, but keep the principle: cut external reach first, then data access, then the identity itself.

1. Trigger on notice. Start the process the moment resignation or termination is confirmed, ideally 24 to 48 hours before the last day. Freeze new access requests at the same time.
2. Build the inventory. List directory groups, SaaS apps, repositories, SSH keys, API tokens, devices and shared vault entries the person holds.
3. Disable VPN and remote access first. Revoke VPN profiles and remote desktop rights so the person cannot reach internal systems during the notice period.
4. Revoke SaaS seats and transfer data. Remove app access, delegate the mailbox, and move Drive or file-share ownership to a manager.
5. Disable the directory account and reset MFA. Disable the identity provider account and remove enrolled MFA devices before the final day.
6. Remove keys and tokens. Delete SSH keys from servers, revoke API tokens, remove deploy keys and CI/CD credentials, and retire any personal service accounts the leaver owned.
7. Reclaim devices. Collect laptops and phones, and wipe them where policy requires before reuse.
8. Log and verify. Record every revocation in one place, then test that the old login paths now fail.

Which configuration choices actually matter?

Group-based access and SSO turn offboarding from a manual hunt into a few group removals. Assign apps by role group, not by individual account, and issue SSH through short-lived certificates rather than permanent keys. These choices shrink the number of places a credential can outlive an employee.

SSO is the single biggest lever. When applications authenticate through an identity provider like Microsoft Entra ID, disabling the directory account also blocks those apps, provided they were onboarded to SSO. SCIM provisioning goes further: when you remove a user from a group, the identity provider tells Slack or Salesforce to deprovision the seat automatically. For SSH, prefer short-lived certificates from a bastion or identity-aware proxy over long-lived keys scattered across servers. Password managers should use per-team vaults so a leaver's access disappears with vault membership, not when someone remembers to edit ten shared items.

How do you verify the offboarding actually worked?

Verification is a login attempt, not a console confirmation. Have a second person try to sign in to email, VPN and one or two SaaS apps using the departed person's known path. If the identity provider logs the attempt as denied, the revocation held. Repeat the check thirty days later, because restoration errors happen.

Verification has two parts: confirm the user cannot get in, and confirm the team can still reach the data they owned. For the first part, attempt the old login paths and expect a denial. Check the identity provider's audit log for that attempt; "user disabled" or "account not found" is the outcome you want. For the second part, open the mailbox delegation, confirm shared drives transferred, and check for mail-forwarding or auto-reply rules that might still route client mail to a personal address. Forwarding rules are a classic gap: the mailbox is disabled, but a forward set a week before departure keeps working.

What breaks first when an offboarding slips?

The first visible failure is usually a mailbox still receiving mail, or a SaaS seat still billing. The more dangerous failure is silent: an SSH key or API token that never gets revoked. When you find a slipped access, check whether it was used since departure before you revoke it — that tells you the blast radius.

When something slips, the symptoms depend on where it slipped. A SaaS app still shows the person as active in its own admin page. A server accepts the old SSH key and the auth log shows a successful login from a home IP. An API token keeps returning 200s from a CI job. Debug in this order: check the directory first, then group memberships, then each SaaS admin panel, then the server's authorized_keys or credentials files. Pull the relevant audit log — AWS CloudTrail for IAM changes, sign-in logs for Microsoft 365, the GitHub audit log — and confirm whether the credential was used after the departure date. That determines whether you are cleaning up an oversight or responding to a breach.

What does a dependable offboarding process cost to run?

The cost is mostly engineer time, not licence fees. A standard checklist takes an experienced person thirty to sixty minutes per departure once the inventory exists. The real cost driver is sprawl: every additional SaaS app and non-SSO login adds time and risk. Confirm any tooling costs with the vendor's current pricing.

Building the inventory the first time is the expensive part, and it scales with SaaS sprawl: twenty apps take longer than five. SSO and SCIM reduce the per-departure effort but carry their own setup and licence overheads. The hidden cost of doing nothing is far larger: an orphaned credential involved in a data breach costs more in investigation, notification and lost trust than the hour it would have taken to revoke it. If you have no in-house IT time, our DevOps and cloud team can run the sequence for you as part of managed access control.

What mistakes do teams make repeatedly?

The most common mistake is treating the directory toggle as the whole job. Close behind are revoking access too late, forgetting the password manager shared vault, leaving forwarding rules that redirect mail, and never checking whether anyone else used the departed person's shared account. Each one is fixable with a checklist.

• Treating the directory disable as the finish line.
• Revoking access after the last day rather than before it.
• Forgetting shared accounts, the password vault, and test logins the person created.
• Leaving mail-forwarding rules in place.
• Never auditing whether the old credential was used after departure.
• Keeping the person's MFA enrolled, so recovery flows still reach their phone.
• Failing to reclaim company devices and wipe them where policy requires.

A realistic scenario: the contractor who still had a key

A design agency offboarded a part-time contractor by disabling the Microsoft 365 account. Six weeks later, the contractor's SSH key to a staging server still worked, because it had been added directly to the server's authorized_keys file and never audited. The fix took an hour; the exposure had lasted forty days.

The agency had followed what looked like a complete process: HR notified IT, the Microsoft 365 account was disabled, email was delegated. What they missed was the staging server, where the contractor had been given a direct SSH key months earlier to debug a deployment. The key sat in the deploy user's authorized_keys file on a cloud instance and was never on any inventory. The contractor, now working elsewhere, never used it — but the agency discovered this only by luck during a server migration. The lesson: the inventory is only as good as the sources it was built from. Servers, repositories and CI/CD systems must be part of the offboarding sweep, not just the applications HR can see. This is exactly the kind of gap our team checks for when we take over ongoing security and maintenance.

Which option fits: checklist, spreadsheet, or identity tool?

A shared-document checklist is right for small teams with a handful of SaaS apps and low turnover. A spreadsheet works when you need history across many leavers. An identity provider with SSO and SCIM is worth the setup once departures are frequent or the app list is long.

The same principle behind this decision applies when a team resists using a new system after launch: the tool only works if the human process around it is real. And the question of who actually holds the keys on shared hosting versus a VPS matters here too — offboarding is only as complete as the deepest access layer you can reach.

In short: offboarding staff system access is a revocation sequence, not a button. Inventory before the person leaves, revoke in order of external reach, verify with real login attempts, and re-check after thirty days. The hour you spend now is the cheapest insurance against the quietest kind of breach.

People also search for

• Why do staff resist using a new system after launch?
• Who actually holds the keys on shared hosting versus a VPS?
• Does off-the-shelf software create more orphaned logins than custom systems?
• What does a web project quote include for access control and handover?
• How do booking systems manage staff access for seasonal workers?
• Which app accounts outlive a contractor on cross-platform projects?

If a departed employee has already left a login behind, or you want a repeatable offboarding process your own team can run, our engineers can help you build the inventory, close the gaps and document the sequence. Talk to us about offboarding and access control, or see how we handle ongoing security and maintenance.