The failure
You disable the identity on the last day, the way every offboarding checklist says to. Three weeks later nobody can log into the domain registrar, because the only enrolled authenticator was on a phone that walked out the door. The revoke step ran before the transfer step, and now an account the company still pays for is locked. This is not rare. The Google Workspace admin help community carries a standing thread on exactly this.
The checklist
Six columns. The three rows below are examples of what an enumeration looks like before the last day: one account per row, and what unlocks it.
| Account / service | Authenticator held | Where it lives | Their role | Recovery codes seen? | Transfer step |
|---|---|---|---|---|---|
| Domain registrar (example.com) | TOTP app | Personal phone | Sole owner | Yes | Enroll a team factor, verify a login with it, then remove theirs |
| GitHub org owner (acme) | Hardware key | Issued key | Admin | Unknown | Add a second org owner, then rotate the recovery codes |
| AWS root account | TOTP app | Personal phone | Sole admin | Yes | Enroll a team factor, verify, remove theirs, then rotate codes |
The Transfer step column is the whole point. It lists the work in the only order that does not lock you out.
Column definitions
1 · Account / service
The account plus a stable identifier. The registrar, the GitHub org, the AWS root account. A bad entry is “the phone” or “his logins”, because neither resolves to a login you can act on. This column is what ties the row to the transfer step.
2 · Authenticator held
What actually unlocks the account: a TOTP app or a hardware key. A bad entry is “2FA” with no detail. The factor type changes the transfer step, because a hardware key is handed back while an authenticator app is re-enrolled from scratch.
3 · Where it lives
Personal device, issued key, or shared. A bad entry is leaving this blank, which hides the one fact that matters most: whether the factor leaves the building with the person.
4 · Their role
Sole owner, sole admin, or shared. A bad entry is “user” when the person was actually the only admin. This column is how you catch accounts that have no second person able to recover them.
5 · Recovery codes seen?
Yes, No, or Unknown. Codes bypass MFA, so any code the person saw has to be treated as compromised and regenerated. A bad entry is leaving Unknown unresolved when the answer decides whether Phase 2 applies.
6 · Transfer step
The work in the only order that does not lock you out: enroll a factor held by the team, verify a login with it, and remove theirs only after that works. A bad entry is “remove theirs” written first, which is how the lockout in this article happens.
The procedure, in order
Every offboarding checklist says to revoke access. The lockout happens because revoke runs before transfer. Ordering is the entire content here, so the phases are written in the order you must follow.
Phase 0 · Enumerate
Before the last day, write down what this person held. That means authenticators on personal devices, hardware keys you issued, shared authenticators in their custody, every account where they are the sole owner or sole admin, and any recovery codes they were ever shown. This is the table above. You cannot transfer what you never wrote down.
Phase 1 · Transfer
Still before revoke. Per account, enroll a second authenticator held by the team, verify a login with it, then remove theirs. Never the reverse order. Removing the old factor first is how a working account becomes an unrecoverable one in the gap between the two steps.
Phase 2 · Rotate
Regenerate recovery codes on every account they could have viewed. Codes bypass MFA, so a code the person memorised or photographed survives every other step in this list, including the transfer.
Phase 3 · Revoke
Only now disable access. Start with the IdP identity, then move to the accounts outside the IdP. Revoke last so there is never a moment where access is gone before the replacement is in place.
Phase 4 · Attest
Write a dated record of which authenticators were held, which accounts they covered, and when each was transferred. This is the offboarding evidence an auditor asks for and most companies cannot produce. If you did Phase 0, this is a copy of the table with dates added. If you skipped it, this is where you reconstruct and guess.
They've already gone and won't help
If the person has already left, the transfer phase is over and you are in recovery. Split the accounts before you spend time, because the two groups recover at very different speeds.
Recoverable through an admin
Some accounts have an admin escape hatch. A Microsoft 365 admin can turn off the account's legacy MFA settings, and a Google Workspace super admin can reset a user's 2SV. These recoveries take minutes once you are in as admin.
Genuinely hard
The rest have no admin reset. Registrars, banks, the AWS root account, and a GitHub org owner all route recovery through the vendor's identity verification, with business documents and often a notary. Plan for days to weeks, not hours, and start the slowest vendor first. These are the accounts that belong in the break glass and root account register, with two named custodians each.
Where it breaks
Phase 0 only works if the enrollment map existed before the resignation. If you are building it during the notice period, you are guessing: you cannot enumerate what you did not record, and a gap shows up later as a locked account. The map has to be maintained continuously, not assembled on the way out. RecoveryCodes keeps the enrollment map current as accounts and authenticators change, so Phase 0 is a read instead of a reconstruction.
Frequently asked questions
What happens to two-factor authentication when an employee leaves?
The account stays protected by whatever factor the person enrolled, but that factor is now gone with them. If the authenticator lived on a personal phone and no second factor was enrolled, the account becomes unrecoverable by anyone. The fix is to enroll a factor held by the team before the person’s access ends.
Can an admin remove MFA from a departed employee’s account?
It depends on who controls the account. A Microsoft 365 admin can turn off the account’s legacy MFA settings, and a Google Workspace super admin can reset a user’s 2SV. For a registrar or a GitHub org owner, there is no admin reset. Recovery goes through the vendor’s identity verification and can take days to weeks.
How do I transfer an authenticator before offboarding someone?
Enroll a second factor held by the team, verify a login with it, then remove the departing person’s factor. Doing it in the other order removes the only working factor and locks everyone out.
Do recovery codes need to be rotated when an employee leaves?
Yes. Recovery codes bypass MFA, so a code the person saw is still a valid backdoor after every other step is done. Regenerate them on every account they could have viewed, including the ones where access was already revoked.
Download the checklist
No email gate, no form. The spreadsheet has the same columns plus tabs for the procedure and these column definitions.