Offboarding done right: a technical checklist

Someone leaves your organisation. HR closes the ticket. IT disables the Active Directory account. The laptop gets wiped. Done?

Not quite. In most organisations, that workflow handles the visible surface area — SSO, email, the laptop — while leaving behind a quieter category of access that nobody owns: shared credentials stored in a password manager that the departing employee could read, copied to clipboard two days before they left.

This isn't a theoretical risk. Post-employment credential abuse is one of the most common causes of data breaches involving insiders, and it's almost entirely preventable. The problem isn't malice — most departing employees aren't planning to do anything with your AWS root credentials. The problem is that the access window stays open long after the employment relationship ends, and that window occasionally gets exploited.

The anatomy of a credential leak on departure

To understand what needs to happen on offboarding, it's worth tracing exactly how a shared credential stays accessible after someone leaves.

Most teams use a shared password manager. The departed employee had a vault with org-level access. They could view, copy, and in many cases export every shared credential they had permission to see. When their account is deactivated, they lose access to the interface — but anything they copied, screenshotted, or remembered is still valid. The underlying credentials haven't changed.

The access window has three layers, and they need to be closed independently:

• Interface access — the ability to open the vault and read credentials. Closed by deactivating the account. Most teams do this.
• Derived knowledge — passwords the employee memorised, copied to a personal notes app, or exported. Closed only by rotating those credentials. Most teams skip this.
• Cryptographic access — in zero-knowledge systems, the employee's device may hold encrypted blobs decryptable with their master password. Closed by re-encrypting with a new org key that excludes the departed member. Almost no teams think about this.

The technical checklist

What follows is the complete sequence in the order it should happen. Each item is marked by urgency: critical (do before the employee's last day if possible), important (do on the day), and good practice (do within the grace period).

The zero-knowledge problem nobody talks about

If your team uses a zero-knowledge password manager — one where credentials are encrypted on-device and the server holds only ciphertext — offboarding has an additional cryptographic dimension that most documentation glosses over.

Here's the issue. In a zero-knowledge team vault, the org's credentials are encrypted with a shared org key. Each member holds a copy of that org key, wrapped with their individual public key. When a member is removed, their wrapped key copy is deleted from the server. They can no longer authenticate and receive new credentials.

But anything they decrypted before departure remains in their memory, their clipboard history, their browser's autofill cache, or their local storage. The cryptographic access revocation closes the forward window — they can't read new credentials added after they leave. It does nothing about credentials they've already seen.

This is why credential rotation is non-negotiable. Access revocation and credential rotation are not alternatives — they close different things.

Org key rotation — when and why

The scenario above assumes the departing employee's key copy is simply deleted. In most implementations, the org key itself doesn't change — only that member's wrapped copy is removed. This means:

• Future credentials (added after departure) are safe — the departed member has no key copy to decrypt them with
• Any credential the member could access before departure remains recoverable if they retained a copy of the org key from before their account was deactivated

For most departures, this is acceptable. The risk window is small: to exploit it, the former employee would need to have exfiltrated not just credential values but the raw org key material — which is never transmitted in plaintext and would require active memory extraction at the time of access.

For sensitive departures — a disgruntled administrator, a termination for cause, or a departure involving potential IP conflict — full org key rotation is the right call. This involves:

1. Generating a new org vault key
2. Re-encrypting every org credential with the new key
3. Distributing the new key to all remaining members
4. Invalidating the old key

This is computationally expensive (re-encrypting hundreds of credentials in the client) and requires all remaining members to be online to receive the new key. It's not a routine operation. But for high-risk departures, it's the only operation that gives you cryptographic assurance of forward secrecy.

-- Member removed, key copy deleted, deactivated
SELECT u.email, om.deactivated, om.deactivated_at,
       omk.wrapped_org_key  -- should be NULL after offboarding
FROM org_members om
JOIN users u ON u.id = om.user_id
LEFT JOIN org_member_keys omk
  ON omk.org_id = om.org_id AND omk.user_id = om.user_id
WHERE om.org_id = :org_id
  AND om.deactivated = TRUE;

-- Credentials accessed by this member in last 90 days
-- (everything here needs rotation)
SELECT cal.credential_id, op.name, cal.action,
       cal.accessed_at, cal.ip_address
FROM credential_access_log cal
JOIN org_passwords op ON op.id = cal.credential_id
WHERE cal.user_id = :departed_user_id
  AND cal.accessed_at > NOW() - INTERVAL '90 days'
  AND cal.action IN ('copy', 'view')
ORDER BY cal.accessed_at DESC;

The credential access log query is the most important one. If you run this on departure day and get a list of 40 credentials, those 40 credentials need to be rotated. If you run it and get zero rows, either your logging isn't working or the employee never actually decrypted anything — both worth investigating.

The grace period problem

Many offboarding processes include a grace period: the employee's account remains active for a few days after their nominal last day to allow for knowledge transfer, file retrieval, or transition support. This is reasonable from an HR perspective and a security nightmare from a technical one.

The grace period is when most credential exfiltration happens, not because departing employees are malicious, but because it's when they're doing the most active cleanup — accessing old documents, checking what they've shared, forwarding things to personal email "just in case." Credentials accessed during this period are the highest-risk ones because the window between final access and rotation is typically the longest.

The practical recommendation: if you're going to have a grace period, treat it as a monitored window rather than a trusted one. Increased logging, alerts on bulk credential access, and a defined rotation trigger at the moment the grace period ends rather than when it begins.

What breaks when you get this wrong

The failure mode isn't usually dramatic. It's six months later, during an incident investigation, when you're trying to trace how an attacker got credentials that weren't in any external breach. You pull the access logs and realise the last legitimate access was by someone who left in October.

The other failure mode is more mundane: a CI/CD pipeline breaks because it was using credentials tied to a personal account, and the team creates a new service account with wider permissions than the original because they're in a hurry and don't want to scope it down manually. Six months later, that broadly-scoped service account is in a breach that a properly scoped one would have contained.

Both of these are preventable with a disciplined offboarding checklist executed every time without exceptions. The challenge is that offboarding is procedurally boring, happens infrequently enough that it's easy to forget, and the consequences of doing it carelessly are delayed enough that the connection to the original gap is rarely obvious.

Automating the undramatic parts

The checklist above has two kinds of items: decisions (which credentials need rotation, who owns them, is key rotation warranted) and mechanical operations (deactivate account, revoke sessions, delete key copy). The decisions need human judgment. The mechanical operations should be automated and verified.

What automation should cover:

• Generating the access report automatically on offboarding initiation — before anyone has to remember to ask for it
• Deactivating the vault account and revoking sessions as a single atomic operation on a specified date, not manually on the day
• Creating rotation tasks for each credential in the access report, assigned to the credential's owner or the team admin, with a due date
• Sending the completed audit record to a designated location (HR system, compliance store) when the grace period closes
• Alerting if rotation tasks remain incomplete after the due date

What automation should not try to cover:

• Deciding which credentials are sensitive enough to warrant immediate rotation versus end-of-grace-period rotation — this requires context about what the credential accesses
• Executing the rotation itself — the credential's value lives client-side in a zero-knowledge system; rotation must be performed by an authenticated user with access to the new value
• Making the call on org key rotation — this has operational impact for all remaining members and should be a conscious decision, not an automated one

How platforms handle this

The comparison is intentionally unflattering about the alternatives — not to dismiss them, but because the offboarding workflow is genuinely underdeveloped across most commercial password managers. It's treated as a UI convenience (remove the member, they lose access) rather than as a security operation with cryptographic properties that need explicit handling.

The takeaway

Offboarding is not a single operation. It's a sequence of operations across three distinct layers — interface access, derived knowledge, and cryptographic access — and all three need to be closed, in roughly that priority order, on a defined timeline.

The single most common failure is treating account deactivation as equivalent to access revocation. It isn't. Deactivation closes the interface. Rotation closes the access. If you only do the first, you've created a false sense of completeness while leaving the underlying risk open.

The checklist in this post isn't exhaustive — every organisation has IdP-specific steps, cloud-provider-specific steps, and application-specific steps that aren't generic enough to list here. But the structure — identify, rotate, revoke, audit, monitor — applies universally. If your current offboarding process doesn't do all five, it's incomplete, and the gaps will show up eventually.