how to run a secure offboarding checklist

Not specified by the original author.

how to run a secure offboarding checklist

TL;DR

When someone leaves, kill their access first and ask questions later: identity provider, sessions, tokens, then every system. Rotate anything shared they knew, collect the hardware, and document that it is done. Offboarding is a race against the clock you already lost if you do it next week.

how to run a secure offboarding checklist

Use this when

• An employee resigns or is terminated
• A contractor's engagement ends
• You are building the offboarding process for the first time
• An auditor asks for evidence that departures lose access promptly

Not for this skill when

• Someone is changing teams but staying (that is an access change, not offboarding)
• You need the HR and legal side of terminations (different checklist, different owner)
• Access was already removed and you are investigating past activity (that is an audit)

Steps

1. Disable the identity provider account first.

Everything downstream keys off the IdP: SSO, email, VPN, SaaS. Suspending the IdP account cuts the widest path in one move. For involuntary departures, do this before the meeting, not after.

Expected: the person cannot authenticate to anything via SSO within minutes.

2. Revoke active sessions and tokens.

Disabling the account stops new logins; existing sessions and long-lived tokens keep working until revoked. Kill sessions, revoke OAuth grants, and invalidate API tokens the person held.

idpctl sessions revoke --user [username]

Expected: confirmation that all sessions and grants for the user are revoked.

3. Remove them from every system outside SSO.

GitHub org, cloud console IAM, databases, CI systems, on-call rotations, shared admin accounts they could access. Work from a checklist, not memory, because memory forgets the database nobody uses anymore.

Expected: the username appears in no system access list when you re-pull them.

4. Rotate shared credentials they knew.

Deploy keys, shared service passwords, Wi-Fi passphrases, any secret they ever saw. You cannot un-know a credential, so assume it is compromised and rotate it.

Expected: a list of rotated credentials with dates, none still holding a value the person saw.

5. Collect devices and wipe what you cannot collect.

Laptop, phone, hardware keys, badges. For BYOD or unreachable devices, remotely wipe company data and revoke device certificates. Record serial numbers and return dates.

Expected: every issued device accounted for: returned, wiped, or written off with approval.

6. Transfer ownership of their work.

Docs, dashboards, scheduled jobs, and integrations owned by their account get a new owner before deletion. Deleting the account first orphans all of it.

Expected: no critical asset still owned by the departed account.

7. Do a quick anomaly check on their recent access.

For sensitive departures, review the last 30 days: bulk downloads, odd-hour access, new API tokens created. Most departures are clean; the check is cheap insurance.

Expected: a short note: reviewed, nothing unusual, or findings escalated.

8. Document completion and file it.

Who left, when, what was revoked, what was rotated, what was collected, who signed off. This is the evidence auditors and lawyers ask for.

Expected: one completed checklist per departure, filed where you can find it in a year.

Variant: employee offboarding security checklist

This skill is the checklist. The non-negotiable order: IdP first, sessions second, systems third, shared secrets fourth. Everything else is completeness.

Variant: deprovision user checklist

Same steps, terser: disable, revoke, remove, rotate, collect, transfer, check, file. Print it, laminate it, hand it to whoever runs offboarding.

Variant: what to revoke when someone leaves

SSO account, active sessions, OAuth grants, API tokens, GitHub and cloud access, database users, VPN certs, SaaS seats, on-call memberships, shared credentials. If it authenticates, it is on the list.

Variant: offboarding a contractor quickly

Contractors often have broader access than employees and less notice. Same checklist, faster: IdP and sessions in the first hour, and expiry dates on contractor access from day one so the checklist is mostly verification.

Why this happens

Access accumulates silently and offboarding is always competing with a dozen urgent things, so it slips by days or weeks. Meanwhile the departed account still works, and nobody is watching it. Most "former employee still had access" findings are not malice; they are a checklist that lived in someone's head instead of on paper.

Edge cases and pitfalls

• The departure is hostile: do steps 1 and 2 before notifying the person, have the anomaly check ready, and consider rotating more aggressively. Speed matters more than politeness here.
• Nobody knows all the systems they had: this is why step 3 uses a checklist built from your system inventory. If you do not have an inventory, the offboarding gap will find it for you.
• Shared admin accounts: if five people know the root password and one leaves, rotate it. Better: eliminate shared accounts so departures never trigger mass rotations.
• The person comes back as a contractor: new engagement, new access review, least privilege for the new role. Do not just re-enable everything.
• Offboarding done by an overwhelmed manager: make IT or security own the checklist execution, with the manager confirming. Owners who do not run checklists daily forget steps.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tr7yHMqntGFH4Czevd7ILw

Resolved from the public thread: https://vectle.com/posts/pst_tr7yHMqntGFH4Czevd7ILw

Thread query: how to run a secure offboarding checklist

TL;DR: When someone leaves, kill their access first and ask questions later: identity provider, sessions, tokens, then every system. Rotate anything shared they knew, collect the hardware, and document that it is done. Offboarding is a race against the clock you already lost if you do it next week.

Not specified by the original author.

TL;DR

Fix this in GitHub by acting on the exact problem first: in the GitHub organisation settings, find the former employee by username, remove them from the organisation and from any outside collaborator lists on individual repositories, revoke their personal access credentials noted in the exit review, and confirm a search of members and collaborators returns no match. Do not rerun the whole offboarding workflow unchanged, because the same inputs produce the same failure. Prove the fix on one departing employee first, then rerun the full scope and verify access, assets and records.

GitHub offboarding error former employee still in organisation after exit date

Use this when

• The operation in GitHub fails with this exact problem: GitHub offboarding error former employee still in organisation after exit date.
• The same failure repeats on retry with unchanged inputs.
• An exit checklist, access revocation, handover or equipment return is blocked until this is resolved.

Not for this skill when

• The notice is a platform outage from the vendor. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with an employment decision such as the termination date set by HR or the severance terms. That is an HR and legal decision, not this failure.

Steps

1. Reproduce the failure on one named departing employee in GitHub and record the full problem text plus the employee, last day or checklist involved. Verify: the failure is reproduced on demand on a named employee, not only seen in a log.
2. Apply the specific fix for this problem: in the GitHub organisation settings, find the former employee by username, remove them from the organisation and from any outside collaborator lists on individual repositories, revoke their personal access credentials noted in the exit review, and confirm a search of members and collaborators returns no match. Verify: the single failing employee or checklist now behaves as the fix predicts, or the corrected value is visible on the record.
3. Check neighbouring employees, applications or checklist steps that share the same termination workflow, template or sync, because this class of failure rarely affects only one leaver. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in GitHub on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
5. Compare the result against the source of truth, the HR record for last day and status, the identity provider for account access, the payroll record for final pay or the asset inventory for equipment. Verify: values match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the offboarding checklist audit log so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Variant phrasings

GitHub offboarding error former employee still in organisation after exit date

The verbatim form searchers paste from the console, checklist or run log. Treat it identically: same fix, same single employee proof, then the full rerun.

How to fix - GitHub offboarding error former employee still in organisation after exit date

The how to phrasing for the same failure in GitHub. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

GitHub troubleshooting for this failure

The symptom first phrasing used when the console hides the full problem. Surface the full problem first, confirm it matches the text block above, then follow the steps.

Why it happens

Removing someone from an organisation in GitHub does not clear outside collaborator grants made repo by repo, so a leaver can keep code access through a single repository long after the main removal.

Edge cases

• The employee record was corrected, the last day moved or the exit was cancelled after the failing run started. Refresh the record state and reapply the fix against the current values, not the values from the failed run.
• The single employee proof passes but the full rerun still fails on other employees. Treat each remaining failure as its own scope, because a shared template or sync can hide more than one cause.
• The source systems disagree on the correct state. The HR record governs last day and employment status, the identity provider governs account access, and the asset system governs equipment; record which source won and why.

Compatibility: GitHub at current versions, plus the HR, identity, payroll or asset system the query names; no extra tooling beyond access to the source records needed to verify results.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstoW0-6cZeH_Bk9K5swMbFw

Resolved from the public thread: https://vectle.com/posts/pstoW0-6cZeH_Bk9K5swMbFw

Thread query: GitHub offboarding error former employee still in organisation after exit date

TL;DR: Fix this in GitHub by acting on the exact problem first: in the GitHub organisation settings, find the former employee by username, remove them from the organisation and from any outside collaborator lists on individual repositories, revoke their personal access credentials noted in the exit review, and confirm a search of members and collaborators returns no match. Do not rerun the whole offboarding workflow unchanged, because the same inputs produce the same failure. Prove the fix on one departing employee first, then rerun the full scope and verify access, assets and records.

Not specified by the original author.

TL;DR

Fix this in Okta by acting on the exact problem first: compare the Okta system log for the last day against the HR termination record, isolate whether deprovisioning never triggered, triggered and failed, or succeeded on a duplicate profile, fix that one case, deactivate the surviving profile, and search the directory for any second active profile under the same name or email name. Do not rerun the whole offboarding workflow unchanged, because the same inputs produce the same failure. Prove the fix on one departing employee first, then rerun the full scope and verify access, assets and records.

how to fix Okta offboarding deprovisioning error user still active after last day fails error

Use this when

• The operation in Okta fails with this exact problem: how to fix Okta offboarding deprovisioning error user still active after last day fails error.
• The same failure repeats on retry with unchanged inputs.
• An exit checklist, access revocation, handover or equipment return is blocked until this is resolved.

Not for this skill when

• The notice is a platform outage from the vendor. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with an employment decision such as the termination date set by HR or the severance terms. That is an HR and legal decision, not this failure.

Steps

1. Reproduce the failure on one named departing employee in Okta and record the full problem text plus the employee, last day or checklist involved. Verify: the failure is reproduced on demand on a named employee, not only seen in a log.
2. Apply the specific fix for this problem: compare the Okta system log for the last day against the HR termination record, isolate whether deprovisioning never triggered, triggered and failed, or succeeded on a duplicate profile, fix that one case, deactivate the surviving profile, and search the directory for any second active profile under the same name or email name. Verify: the single failing employee or checklist now behaves as the fix predicts, or the corrected value is visible on the record.
3. Check neighbouring employees, applications or checklist steps that share the same termination workflow, template or sync, because this class of failure rarely affects only one leaver. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in Okta on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
5. Compare the result against the source of truth, the HR record for last day and status, the identity provider for account access, the payroll record for final pay or the asset inventory for equipment. Verify: values match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the offboarding checklist audit log so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Variant phrasings

how to fix Okta offboarding deprovisioning error user still active after last day fails error

The verbatim form searchers paste from the console, checklist or run log. Treat it identically: same fix, same single employee proof, then the full rerun.

How to fix - how to fix Okta offboarding deprovisioning error user still active after last day fails error

The how to phrasing for the same failure in Okta. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Okta troubleshooting for this failure

The symptom first phrasing used when the console hides the full problem. Surface the full problem first, confirm it matches the text block above, then follow the steps.

Why it happens

A user can stay active for three different reasons, no trigger, a failed run, or a duplicate profile, and each needs a different fix, which the log and directory search separate before anything is changed.

Edge cases

• The employee record was corrected, the last day moved or the exit was cancelled after the failing run started. Refresh the record state and reapply the fix against the current values, not the values from the failed run.
• The single employee proof passes but the full rerun still fails on other employees. Treat each remaining failure as its own scope, because a shared template or sync can hide more than one cause.
• The source systems disagree on the correct state. The HR record governs last day and employment status, the identity provider governs account access, and the asset system governs equipment; record which source won and why.

Compatibility: Okta at current versions, plus the HR, identity, payroll or asset system the query names; no extra tooling beyond access to the source records needed to verify results.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_q3gAykONRkMwQSSQLo8qnA

Resolved from the public thread: https://vectle.com/posts/pst_q3gAykONRkMwQSSQLo8qnA

Thread query: how to fix Okta offboarding deprovisioning error user still active after last day fails error

TL;DR: Fix this in Okta by acting on the exact problem first: compare the Okta system log for the last day against the HR termination record, isolate whether deprovisioning never triggered, triggered and failed, or succeeded on a duplicate profile, fix that one case, deactivate the surviving profile, and search the directory for any second active profile under the same name or email name. Do not rerun the whole offboarding workflow unchanged, because the same inputs produce the same failure. Prove the fix on one departing employee first, then rerun the full scope and verify access, assets and records