Employee Offboarding Best Practices for HR, IT, and Security Teams

Your auditor picks 25 people who left last year and asks for two timestamps on each one: when HR recorded the departure, and when the last account closed. The first column takes a minute to export. The second takes your team two weeks of screenshots and Slack threads, and for four of the 25 there's an app where the honest answer is "not yet."

Employee offboarding best practices are the routines that end a departing person's access everywhere it exists, starting from the HR record before the last day and finishing when every app agrees with HR, with proof of each removal. Most programs treat the single sign-on (SSO) disable as the finish line. The risk sits on either side of it, in the days before IT hears about a departure and in the apps, sessions, and roles your identity provider never touches.

Offboarding is one of the few processes every company runs, and one of the easiest to get quietly wrong. The employee offboarding best practices in this article apply at any size and in any industry, and they make the leaver step of your joiner-mover-leaver program something you can rely on and prove. HR, IT, and security each own a piece, and most of the work starts well before anyone’s last day.

Start offboarding from the HR record before the last day

Start offboarding the moment HR records a departure, and schedule access to end at the separation time, because every hour between a person's last day and IT hearing about it is an hour their accounts outlive the job. In plenty of companies, IT still learns about departures from a manager's email or a ticket filed after the fact, which ties offboarding to whoever remembers to pass the news along.

The Texas State Auditor's Office documented the gap in a November 2025 audit of offboarding at the Texas Historical Commission. For 21 of 22 sampled employees, IT learned of the departure 1 to 47 days after the last day, and one former employee's access stayed active for 357 days without the commission's quarterly access reviews catching it. The auditors' first recommendation was to tell IT before the last day, which is why the HR-to-IT notice belongs at the top of your offboarding communication plan.

The fix starts upstream of IT. Ask HR to enter each separation with its date and time when the decision is made, so a resignation logged three weeks early schedules removal for the last day without anyone setting a reminder. The employee offboarding process should start from that record, with no forwarded message in the chain, and the fields your HR team agrees can move access decide what the record is allowed to trigger.

Involuntary exits run on a tighter clock, with the termination entered before the conversation is on the calendar, flagged to take effect when the meeting starts, and privileged and remote access cut first. The IT offboarding process lays out timing by type of departure, so write yours down with HR and legal before you need it.

Of all the employee offboarding best practices, this is the one the others depend on, because a late trigger delays every step after it. With Lumos Lifecycle Management, the leaver workflow starts when the HRIS event fires, through a live HRIS sync, and every action it takes is logged. Offboarding automation earns its name at that handoff, where no ticket sits between HR's record and the first removal.

Measure the lag before you change anything. For each departure last quarter, compare when HR recorded it with when IT first acted on it, and the longest gap is how long a departure can sit unnoticed today.

Reassign a leaver's approvals, reviews, and app ownership before the last day

A departing person often holds jobs inside your access process, as an approver, app owner, reviewer, or manager of record, and each one needs a new name before their account goes away. These are easy to miss because none of them is an account, so a list built from what the person can sign in to never shows them. When they're missed, the work routed to that person stops.

The failure is quiet. Requests routed to a departed approver stall until a frustrated requester complains, review items assigned to them sit unanswered until the campaign deadline, and their direct reports lose the manager who would have certified their access.

The more you delegate, the more this matters. Chegg used Lumos to delegate administration to managers, so managers and business units handle approvals themselves, with audit logs that make each request easy to track. Delegation like that is the right call as a company grows, and it means every manager who leaves takes a set of approval duties with them. Those duties are a big part of how to offboard an employee who manages people or approves spend

Run the check before the last day. Pull every place the person is a named owner or approver. That means app ownership in your identity provider or governance tool, approval routes in your request workflow, open items in review campaigns, and the manager field on their direct reports' HR records. Reassign each one to a person, never a team alias.

A backstop catches what the check misses at the next request. When an app's approval workflow includes Lumos's Approval by Entitlement Owner, each request goes to the owner of that permission, and org admins are notified when no owner resolves and no other approver exists.

What the person built needs a new owner too. Service accounts, tokens running workloads, and OAuth integrations tied to their account should change hands before their identity goes dark, because an automated non-human identity lifecycle renews or retires an identity with confidence only when someone owns it. Agents running on the person's access pause or move to a new owner as part of AI agent lifecycle management.

Put end dates on elevated access so offboarding has less to remove

Every standing grant is a removal you'll owe on someone's last day, so the cheapest offboarding starts at the moment elevated or temporary access is granted. Access that expires on its own never shows up on a leaver's list, while a role nobody has touched in three years shows up on every one.

Admin rights and project access are the worst offenders. Someone gets admin during an outage or a migration, the work ends, and the role stays, which is how privilege creep builds a leaver's list far longer than the job ever needed.

Set a default end date by the kind of access, and let app owners shorten it. As a starting point, let admin and production rights expire within a working day and project tools at the project's end date, while birthright apps stay tied to the HR record. Contractors and vendors need the rule most, since many have no HR record to fire a leaver event, so contractor offboarding starts with a sponsor and an end date set when the account is created.

GitLab used Lumos to remove unneeded admin access and set up just-in-time access for critical entitlements. Lumos's Access Request Agent grants that kind of access for a set time and revokes it on its own when the window closes.

Start with the access that hurts most to leave behind. List the current holders of your most powerful entitlements, and flag anyone who got theirs more than 90 days ago as a candidate for time-bound access.

Map how each app removes a leaver before anyone leaves

Disabling someone's single sign-on account blocks new sign-ins and starts removal in apps wired for deprovisioning, so before anyone leaves, you need to know how every other app gives up an account. The usual way to learn is one app at a time, after an access review turns up a former employee. A map built in advance turns those surprises into a list with owners.

The Disney World menu case shows how many doors a departure can leave open. A menu production manager fired in June 2024 later changed allergen information on menus in an app and file servers that a third-party vendor hosted. According to The Register, he got in through an administrative account, an access route set up for contractors, and admin access to the vendor's file servers. In April 2025 he was sentenced to three years in federal prison and ordered to pay $687,776.50 in restitution.

Shared admin logins and vendor-side access stay open until someone resets them, and they're easy to miss because an SSO disable does something different in every kind of app. The map starts with how each app connects.

‍

The bottom six rows are where employee offboarding security breaks down, because each one needs a removal path somebody designed ahead of time. Write each app's user deprovisioning route into the map, whether it runs through a connector, a named owner, or a vendor who confirms in writing.

The more of the map a connector covers, the fewer tasks wait on a person. Lumos's leaver workflow revokes access across identity providers, local accounts, custom apps, SaaS, cloud, and on-premises apps from the same HR event, which leaves owner tasks for the apps no connector reaches. Each of those apps still needs its row in the map.

Sort your app inventory by the seven rows above and count the apps in the bottom six. Each one needs a named owner and a removal deadline in your leaver workflow.

Test that a disabled account stops working everywhere

A disabled account can keep working through sessions and tokens it already holds, so the only way to know your offboarding works is to test it on an account you control. A runbook that ends at the disable never checks the sessions, tokens, and app-level logins that outlive it.

Microsoft's guidance on revoking access in Entra ID spells out the gap for its own identity provider. Disabling an account and revoking its sessions stops new tokens, but existing access tokens stay valid until they expire, about an hour by default, unless the app supports Continuous Access Evaluation and can reject them sooner. Entra ID also can't end a session token that an app issued itself, so that app has to end the session on its own.

Apps that keep their own sessions behave the same way under any identity provider, unless they accept a logout signal from it. That's why access revocation has to reach sessions, tokens, and grants, and why the only reliable proof is trying to use them after the disable. We'd rather a team find that gap in a drill than in an access review.

Run an offboarding drill each quarter with a test account that holds the kinds of access a real employee would. Give it SSO apps, an app with its own login, a personal API token, an OAuth grant to a third-party tool, and a signed-in mobile app, then offboard it through your normal process. The next morning, try each one, and put anything that still works on your list of manual steps, with an owner.

Run the drill again after any change to your identity provider, your device management, or an app's login settings, since each can quietly reopen a path you closed last quarter. For involuntary exits, the drill also tells you which manual steps have to happen while the meeting is still going.

Trace each missed account back to the cause that let it survive

Reconcile every app against HR on a schedule, and treat each account it turns up as a symptom whose cause you fix before you close the finding. Reconciliation is the only step in offboarding employees that finds accounts nobody knew to remove, and deleting just the account guarantees another finding next quarter.

Match every app's account list against active HR records, plus a sponsor list for the contractors and vendors who have no HR record. Run it at least monthly for every app and weekly for the most sensitive ones, because a quarterly access review asks reviewers to notice someone missing, which is the hardest thing for a reviewer to see. Orphaned accounts, the ones whose owner is no longer active in HR or on the sponsor list, are the misses your workflow never reported.

Usage is the second signal. Check every app for sign-ins after each separation date, since an account in use after the last day is either a missed removal or someone using a departed person's login. A paid seat nobody has touched in months often points to the same thing.

The removal records that feed reconciliation also measure the program. The IT offboarding process sets out how to track time to last revoke, from the separation time to the last confirmed removal, and the worst case is the number your auditor will find first.

Misses come from a short list of causes. The app was never on the map, a connector failed and nobody saw the error, an owner closed a task without acting, the account used a personal email or an old username, or HR's record arrived late. Each cause has its own fix, whether that's a new connector, an error alert with an owner, confirmation read back from the app, a better matching rule, or an earlier trigger.

Log each miss like a small incident, with the cause, the fix, and the date the fix shipped, and review the log every quarter. When the same cause shows up twice, the first fix didn't hold.

The late HR record deserves its own line on that log, because no connector can fix it. If departures keep reaching IT after the last day, the fix is a conversation with HR about when separations get entered, and the log is the evidence that keeps that conversation short.

Make each departure close faster than the last

The single sign-on disable will always feel like the finish line, and the findings in this piece sit on either side of it. The teams that close the gap don't work harder on each departure. They change the program one miss at a time, until the last account closes on the same day as the first.

This week, measure how long departures sit before IT hears about them. This month, map your apps by how they let go of an account, give every app outside automation an owner, and run the first drill. This quarter, start the reconciliation and the miss log, the two records that turn offboarding best practices into something an auditor can test. Your offboarding is only as fast as its slowest app.

Lumos starts each leaver workflow from your HRIS and revokes access across identity providers, local accounts, SaaS, cloud, and on-premises apps. It grants elevated access that ends on its own and can route each access request to the owner of the permission. See how Lumos Lifecycle Management would handle your next departure, and book a demo.

‍

‍