terminated employee still has access: emergency offboarding checklist

Not specified by the original author.

TL;DR

Disable the accounts first (AD, Entra, Okta, Google), revoke sessions and tokens, then work through the full inventory: VPN, SaaS apps, email forwarding, shared credentials, physical access. Verify each one; "probably revoked" is not revoked.

The error

(Urgent: terminated employee may still have access. Time-sensitive.)

Steps

1. Immediately disable the core identities: AD account (disable), Entra ID (block sign-in), Okta (deactivate), Google Workspace (suspend). Expected: all four done within minutes. Do this before reading further.
2. Revoke sessions: in each IdP, revoke all active sessions and refresh tokens for the user. Expected: sessions killed. A disabled account with a live session token can still act.
3. Reset shared credentials the person knew: shared admin passwords, Wi-Fi PSK if shared, safe combinations. Expected: rotated. This is the step most often skipped.
4. Work the app inventory: VPN access, SaaS apps (check SSO assignments and any non-SSO accounts), email delegation and forwarding rules, distribution lists, code repo access, cloud console access. Expected: each confirmed removed.
5. Physical: collect badge, laptop, and keys; disable badge in the access system. Expected: confirmed with facilities. Then verify: attempt a test login to the main systems and confirm failure.

When to use

• Termination missed by the normal workflow
• Involuntary termination requiring immediate containment
• Suspected malicious ex-employee

When not to use

• Planned offboarding with lead time (use the standard checklist)
• Contractor end dates (use the contractor lifecycle)

Compatibility

• Any identity stack; adapt the system list to your environment

Variants

Employee was remote

Prioritize session revocation and credential rotation; physical collection happens by mail.

Termination happened weeks ago

Assume the worst: rotate everything they touched and review audit logs for post-termination activity.

Why it happens

Offboarding touches a dozen systems owned by different teams. Any gap (a missed SaaS app, a live session, a shared password) leaves real access, and attackers know ex-employee accounts are rarely watched.

Edge cases

• Email forwarding rules the ex-employee set: check for auto-forwarding to personal addresses; remove them.
• Legal hold: preserve the mailbox and files before deleting anything.

Provenance

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

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

Thread query: terminated employee still has access: emergency offboarding checklist

TL;DR: Disable the accounts first (AD, Entra, Okta, Google), revoke sessions and tokens, then work through the full inventory: VPN, SaaS apps, email forwarding, shared credentials, physical access. Verify each one; "probably revoked" is not revoked.

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 Rippling by acting on the exact problem first: in Rippling, open the terminated user and their application list, revoke each application that still shows active access rather than trusting the offboarding summary, check for applications connected outside the Rippling integration, revoke those in the application itself, and save the per app revocation list on the exit record. 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.

Rippling app revocation error saas access remains for terminated user

Use this when

• The operation in Rippling fails with this exact problem: Rippling app revocation error saas access remains for terminated user.
• 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 Rippling 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 Rippling, open the terminated user and their application list, revoke each application that still shows active access rather than trusting the offboarding summary, check for applications connected outside the Rippling integration, revoke those in the application itself, and save the per app revocation list on the exit record. 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 Rippling 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

Rippling app revocation error saas access remains for terminated user

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 - Rippling app revocation error saas access remains for terminated user

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

Rippling 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

Rippling revokes the applications it manages through its integrations, and an app connected by a direct sign in or an older integration stays active while the summary screen already reads complete.

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: Rippling 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_QqjExjc6PwNEqivOFCSdRg

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

Thread query: Rippling app revocation error saas access remains for terminated user

TL;DR: Fix this in Rippling by acting on the exact problem first: in Rippling, open the terminated user and their application list, revoke each application that still shows active access rather than trusting the offboarding summary, check for applications connected outside the Rippling integration, revoke those in the application itself, and save the per app revocation list on the exit record. 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 re