--- title: "Shared MFA offboarding: a practical access checklist" description: "Offboard people from shared MFA and SMS accounts. Review team access, service sessions, old setup keys, recovery codes and the final handover." canonical: "https://sharedmfainbox.com/blog/shared-mfa-offboarding-checklist" author: "The Shared MFA Inbox team" published: "2026-09-23" updated: "2026-09-23" --- # Shared MFA offboarding: a practical access checklist > Offboard people from shared MFA and SMS accounts. Review team access, service sessions, old setup keys, recovery codes and the final handover. _By The Shared MFA Inbox team, Product. Published 2026-09-23, updated 2026-09-23. About 6 minutes to read._ When someone leaves a team that shares login codes, remove their access to Shared MFA Inbox and review each outside service they could reach. Those are separate tasks. Removing a team member stops future access here, but it does not close their sessions elsewhere or revoke a setup key copied before the shared account was created. Use this checklist for a leaver, a contractor finishing work, a client handover or a change in role. The scope may be smaller for a role change, but the question is the same: which routes still let this person reach the account? Have the account owner lead the work. Record what changed, but keep passwords and keys out of the notes. ## 1. List the accounts and the ways in Start with the services the person used, including tools they set up for the company. Check shared authenticator accounts, SMS numbers, saved passwords, recovery email addresses, recovery codes and security keys. Ask about client and regional accounts that may not appear on a central list. For each service, write down the owner, whether the person had their own login, and which shared method they could use. Name who still needs access after the change. Do not put actual passwords, setup keys or recovery codes in this list. Link to the safe place where they are kept. An account absent from the list is easy to miss on the last day. Use expense records, handover notes and the service’s member list where you are authorized to inspect them. Find all the ways they can still sign in. Do not rely just on the tools they recall using this week. ## 2. Make sure someone staying can get in Ask a colleague who will stay to sign in. Check that they can reach the service’s access settings. If the leaver is the only person who can change a method, finish the handover while they are available. Do this while their company login still works. Save or replace recovery methods through the service’s approved process. Make sure the recovery location can be reached by someone staying with the company. A recovery email that belongs to the outgoing person, or a code stored only on their device, leaves the company dependent on them after the handover. If a service needs a named owner, use its process to change that name. Shared MFA is not a way around that requirement. If an account may be at risk, follow your company’s response plan. Do not delay removing access just to make the handover easier. ## 3. Remove access in Shared MFA Inbox Review every team the person belongs to and remove them from teams they should no longer use. Authenticator access is team-wide: a member can use all authenticator accounts in that team. There is no per-account authenticator grant to remove while leaving that person in the same team. Someone may stay for one job but need to lose access to a saved MFA account. In that case, review who belongs in the team. Use the source service’s own access rules, or a team whose full member list fits the account. A new name or label does not hide a saved MFA account. Removing an SMS grant does not hide it either. Review SMS number grants as well. A role change may require removing one grant while keeping access for their other work. Team admins can see all numbers, so a number grant alone is not a way to restrict an admin. Check their role and team list against the work they still need to do. ## 4. Revoke access at each outside service Open the service’s own people or access settings. Remove the person’s named user or role if they have one. Check active sessions and saved devices. Review the other sign-in methods that the account owner can change. End sessions that should no longer remain active. For a shared login, review whether the password was known to the outgoing person and change it where needed. A successful sign-in may have created a session that no longer asks for a code on each visit. Removing access to codes here will not close those sessions. If you cannot find the controls, use the provider’s support or recovery process. Write down what is still open and who will fix it. Do not mark the account complete just because the person was removed from a team here. That service controls who can stay signed in to its account. ## 5. Review setup keys and recovery codes A setup key can keep producing valid codes wherever a copy is held, until the source service replaces or revokes that setup. Moving the same key from a phone into Shared MFA Inbox does not make the phone’s copy stop working. This matters if the leaver originally set up the account or imported it from a personal device. If an old copy may remain, use the service’s supported process to replace the authenticator setup. Save the new supported setup in the correct team and test it. Do not assume deleting and recreating an entry here changes the key used by the source service. The change must happen at that service. Review recovery codes and backup methods too. Replace or remove those the outgoing person could still use, using the service’s steps. Keep the new recovery route in a safe place the account owner can reach. Leave it out of the offboarding ticket, which may be visible to people who should not be able to sign in. ## 6. Keep SMS numbers while accounts still need them Removing a teammate does not require releasing a company number that the remaining team still needs. Keep it active and adjust access. A number may receive codes from several services, so cancelling it can break more accounts than the one named in the handover. If you plan to stop using a number or move it, list the services that use it first. Change each service to a supported replacement, check that a new code works, and check recovery details. Only then decide whether the old number can be released under your company’s process. For a client handover, agree which number and methods will remain under the client’s control. Do not promise that deleting access at the agency changes the client’s account settings. Test the client’s route with an authorized client contact before the work ends. ## 7. Test from the remaining team’s own logins Ask a remaining teammate to find the account and request a fresh code from their own login. Have them complete a sign-in at the source service. Choose a harmless read-only task so the test does not make a purchase, approve a payment or change a live campaign. If the service has an admin view, check the member list after the change. Check the session and sign-in method lists too. Do not ask the outgoing person to send you a working code as proof. That creates a new copy and does not prove that all their ways in are closed. If the test fails, stop before removing the last recovery route. Use the account owner and the service’s recovery process to repair the setup. Record the failed check as open work with a named owner, even if team access has already been removed. ## 8. Keep a clear record of what changed Record which accounts you checked and whose access changed. Note which sessions or methods you removed at each service. Name who ran the final sign-in test. Date the note and name who will fix each open item. Someone reading it later should know what changed. They should not find a means to sign in. The log here shows account changes and who made or copied a code. It cannot show every action inside the outside service, and a code request alone does not prove a successful sign-in. Use that service’s records to check what someone did after they signed in. Do not save a code, setup QR or password as a screenshot in the completion record. Link to the relevant policy or secure location instead. The checklist is evidence that the access work happened; it should not become another place where old keys and passwords are shared. ## Make the next handover easier Give each shared account an owner and a review date while everyone is still on the team. Keep names clear enough that another person can find the right entry. Review the team list when a contractor joins, a client changes scope or a colleague moves roles, instead of waiting until they leave. Use the [shared MFA guide](https://sharedmfainbox.com/blog/shared-mfa-for-teams) when deciding the right team boundary, and the [migration guide](https://sharedmfainbox.com/blog/move-authenticator-to-team) when replacing a setup. A good offboarding plan closes the old routes while proving the remaining team can still do its work. Both results matter. ## Try shared authenticator codes with your team Create a free team and test one account your team is allowed to share. No phone number is needed for authenticator codes. - [Create free account](https://app.sharedmfainbox.com) _No credit card required. Your first authenticator account is free._ --- Canonical: https://sharedmfainbox.com/blog/shared-mfa-offboarding-checklist Every page of this site is also available as Markdown. Site map: https://sharedmfainbox.com/llms.txt