How to Offboard an Employee Based on Their Role and Access

Say a controller and a platform engineer give notice in the same week, and both get the same offboarding ticket. A month after they leave, the bank still lists the controller as an authorized signer on the operating account, and a cloud access key the engineer created two years ago is still signing requests in production. Both tickets closed on time, and neither one asked what the person's job had given them.

To offboard an employee, open the leaver record when the departure is decided, set the cutoff, hand off what they owned, close every account and session, reclaim licenses and devices, and verify each removal, scoped to their job. The steps don't change from one person to the next. What each step has to reach does, and the person's job is the first place to look. The shared steps come first below, followed by the five roles that leave the most behind: engineering, sales, finance, IT and security, and the executive office.

The sequence every offboarding shares

Offboarding an employee runs on the same six steps every time, and the first one starts the day the departure is decided. For a planned departure, they run in this order:

1. Open the leaver record when the departure is decided.
2. Set the cutoff time for this departure.
3. Hand off what the person owned.
4. Close sign-in, active sessions, and every app account.
5. Reclaim licenses and devices.
6. Verify each removal and keep the record.

Each step also carries HR and facilities tasks, from final pay to badge return, that belong on an employee offboarding checklist. The one exception to the order is an involuntary exit, which swaps steps 3 and 4: sign-in, sessions, and privileged access end as the conversation starts, and the manager runs the hand-off afterward. That means the inventory of what the person owns has to be finished before the meeting.

Step one can fail quietly at scale, as the Treasury Inspector General for Tax Administration found in an evaluation published in August 2026. At the IRS, recording a separation in the HR personnel records removes network access automatically. Employees who accepted a deferred resignation offer went on administrative leave instead of separating, so nothing fired. As of June 2025, nearly 17,000 of the roughly 21,500 people who took the offer still had network access, and TIGTA found no business reason for them to hold it.

The automation did what it was built to do. It listened for one status, and these employees were leaving under another.

A manual trigger closes that gap. In Lumos, a leaver workflow starts from a termination event in the HRIS or from a manual deactivation, so an admin can start it the day someone goes on leave instead of waiting for a separation record. Scheduled departures disable accounts automatically on the person's designated last day, which for garden or administrative leave should be the day the leave begins.

The rule underneath holds whether you run offboarding by hand or with employee offboarding software. Every status that means "leaving but not gone" should open the leaver record the day it's set, whether that's accepted notice, garden leave, administrative leave, or a negotiated exit date.

Scope the offboarding by what the job gave them

Start scoping an offboarding from the person's job, which tells you where to look before you open a single admin console. In workforce identity and access management, access arrives in layers: birthright access from department and title, the apps requested along the way, and the keys, tools, and outside accounts the person set up themselves. A standard offboarding list covers the first layer, while people in the same job tend to pick up the same second and third layers. The department, title, and manager in your HRIS tell you which row below to start from.

‍

Other roles earn their own row, such as support agents who can sign in as customers, HR staff with HRIS admin rights, and contractors whose access no HR record tracks. Whatever the row, the person's own access fills in what the role didn't predict, from a live list for connected apps and from their manager and expense reports for everything else.

For connected apps, you won't have to assemble that list by hand. Lumos is adding an Entitlements tab to each person's identity view that lists every active entitlement they hold across connected apps, leaving out accounts already deactivated. Put the role row next to that list before the cutoff, and the gaps show while you can still act on them.

Pinterest's Roger Lim describes Lumos as "the de facto software inventory for the entire company," where more than 8,000 employees discover the apps their roles need (Pinterest). An inventory like that pays off at departure too. An app nobody has inventoried can't make it onto anyone's offboarding list.

Tag your next five departures with a role row before their leaver records run. Add a line for anything the person's own access shows that the row missed.

Engineers leave behind whatever runs as them

An engineer leaves behind whatever runs as them, and most of it lives in keys, tokens, and agents your identity provider never issued. The engineering row above says where to look, and the order you work in decides whether production keeps running.

Inventory what authenticates as the person, move each workload onto a credential the service owns, revoke the keys and tokens, and then disable the account. Disabling the identity provider account usually leaves long-lived cloud keys and SSH keys working, which is how a two-year-old key ends up signing requests a month after its owner left. Revoking a key before its workload moves is how you find out what depended on it, usually in production. Checking what a disabled account can still reach belongs among your employee offboarding best practices for every engineer who leaves.

An involuntary exit compresses all of that into the hours before the meeting. The keys go at the cutoff whether or not every workload has moved, because a broken job is cheaper to fix than a live key that belongs to someone who no longer works for you.

For engineers whose agents run through Claude Code or Codex, you can see which tool servers they've been calling instead of guessing from a laptop. Lumos MCP Governance, in beta, logs each MCP server and tool call against the person who made it, approved or not, including servers employees add locally. Once it's running, that log is where the hunt for an engineer's agent tokens starts.

The service accounts, integrations, and agents an engineer owned need new owners the same day. The hand-off rules for non-human identities a departing person owned cover the first two, and AI agent lifecycle management sets out the leaver steps for agents.

Pull 90 days of cloud API calls and agent tool calls made under the engineer's name, which is long enough for quarterly jobs to show up. Give each recurring job a new owner before the cutoff.

Protect the customer relationship while a salesperson works out their notice

A salesperson works out their notice with every customer relationship still in their inbox, which makes those weeks matter as much as the last day. On the day notice lands, remove CRM bulk export and scheduled report delivery, and delete any rule that forwards mail outside your domain. Keep everyday CRM and email access so they can hand accounts off, and take them out of customer-shared channels once each account has a new owner.

After the last day, keep the mailbox instead of deleting it. CIS Controls v8 Safeguard 6.2 calls for disabling accounts as soon as someone is terminated, and it notes that disabling instead of deleting may be needed to preserve audit trails. For a salesperson, that history is also the customer record, so block sign-in, send new mail to each account's new owner with an auto-reply for a set window, and delete only after that window and any legal review. A mailbox that still receives mail still runs its rules, which is why forwarding gets checked at notice.

The mailbox hand-off can run inside the leaver workflow. For Google Workspace, Lumos offboarding can suspend a user (the license stays assigned), archive them, or delete them (recoverable for 20 days), and custom actions that Lumos Support turns on can transfer the person's data to a named user, reroute their email, and transfer group ownership. Rerouting matters here because Google blocks new mail to a suspended user, and deleting the user once the window closes frees the license.

Tools bought on a card are the last piece, and expense reports find them fastest. Prospecting, enrichment, and scheduling apps bought that way rarely get connected to your identity provider, so nothing else will surface them.

Where does a finance lead's access live outside your apps?

Outside your apps, a finance lead's access lives with banks and payment providers that keep user lists of their own. Your identity provider rarely reaches that outside half, and it's the half an offboarding is most likely to miss.

Inside your apps, the access that moves money goes first, meaning payment initiation and approval rights in the ERP and admin rights in the card program. Reassign approval routes the same day so vendor payments don't stall, and keep each approver role away from anyone who also initiates payments.

A record of who approved what makes the inside half quicker to find. As a public company, Chegg needed approval paths that kept it SOX-compliant, so its IT team set up a secure framework that delegates administration to managers and business units, and Lumos audit logs track every request (Chegg). That trail is a starting point for what to remove when a finance lead leaves, though access granted directly in a bank portal won't appear in it.

The outside half runs on requests and paperwork. Bank and payment portals keep their own admins and hardware tokens, payroll and tax platforms keep their own user lists, and authorized-signer status sits with the bank itself. Send each one a removal request at the cutoff, since payment rights held at a bank move money as surely as the ones in your ERP. Collect the hardware tokens, update the signers, and get each removal confirmed in writing.

Who offboards the people who run offboarding?

A second admin does, because the people who run your offboarding hold the keys to the process itself. A school district in Iowa found out how far those keys reach.

A senior IT support specialist at the district was fired in April 2023, and before he left he downloaded more than 300 usernames and passwords for district accounts, according to the Justice Department. Over the next year and a half, he deleted the district's social media page and data in its device management service, which cut off management of district laptops and tablets for about a week. He also used administrator accounts to delete a staff member's account in a classroom app and nine email accounts belonging to current and former staff, BleepingComputer reported.

He was sentenced to 21 months in prison in June 2026. His reach outlived his job because nobody changed the credentials he'd collected.

Name a second admin who owns the offboarding, because nobody should run the IT offboarding process on their own account. List every admin role the person holds, including the ones outside your identity provider, like the domain registrar and social media accounts. Move sole-admin consoles to a new owner before the cutoff, then rotate every credential they could read, starting from the password vault's access log. Disable any admin account that isn't tied to a named person, since no one's offboarding will ever reach it.

With agentic AI security, finding the admin rights that slipped out of daily use takes one question. In Lumos, Albus answers access questions in plain language, such as “Who has dormant admin access?”, and surfaces admin rights nobody has exercised lately. Dormant rights are the ones a departing admin is least likely to remember holding.

The time to pick that second admin is before anyone resigns. Name one for each of your admins today.

Executive offboarding runs through delegates and board portals

Executive offboarding means unwinding access that other people hold on the executive's behalf. Assistants and chiefs of staff often have send-as rights on the executive's mailbox, and board portals and deal data rooms often sit outside your identity provider, especially when a banker or counterparty hosts the room.

Board portal and data room access go first, since those rooms hold your most sensitive documents and often grant access by invitation alone. Delegate rights last only as long as the agreed handover, with an end date written down, and signing authority changes through legal and the banks in the same week. Company social accounts that carry the executive's name move to a new owner.

Legal decides what's retained before anything is deleted, since an executive's mailbox can be the record a later dispute depends on. Opening the leaver record doesn't announce anything, so this work can start the day the departure is decided while the announcement waits.

Offboard the job the person held

The six steps are the part every team can standardize. What decides whether an offboarding finishes is finding where this particular person's access went.

Start with the next departure on your calendar. Before the cutoff, put that person's role row next to what they hold today, and give everything outside your identity provider, whether it's a bank portal, the domain registrar, or a tool bought on a card, a named owner and a date. Offboard the job, not just the account.

When an auditor samples last quarter’s departures, the answer should come straight out of the offboarding, with no screenshots or ticket digging. A leaver workflow that starts from your HRIS or a manual deactivation, revokes access across every connected app at once, and records every grant and revocation gives you that answer for each departure, including the ones an app owner had to finish by hand. See the record Lumos keeps for your next departure.

‍