--- title: "Shared MFA for teams: access, setup and daily use" description: "Learn how shared MFA works for company accounts, who can generate codes, what the activity log shows, and how to plan access and recovery." canonical: "https://sharedmfainbox.com/blog/shared-mfa-for-teams" author: "The Shared MFA Inbox team" published: "2026-09-23" updated: "2026-09-23" --- # Shared MFA for teams: access, setup and daily use > Learn how shared MFA works for company accounts, who can generate codes, what the activity log shows, and how to plan access and recovery. _By The Shared MFA Inbox team, Product. Published 2026-09-23, updated 2026-09-23. About 6 minutes to read._ Shared MFA lets a team obtain the extra sign-in codes for a company account without relying on one employee’s phone. In Shared MFA Inbox, teammates use their own logins to generate authenticator codes. A paid SMS number is a separate option for services that send a text. Your first shared authenticator account is free; see [pricing](https://sharedmfainbox.com/pricing) for additional accounts. The useful question is not just where the code will live. It is who should be able to use it, which account it opens, and how the company will regain access if the setup fails. Work through those questions before importing anything. They matter more than how quickly the first code appears. ## What is being shared? MFA means multi-factor authentication: a sign-in check that uses more than one kind of proof. A common example is a password followed by a short code from an authenticator app. That code comes from a saved setup key. It is not a text message, and it does not need a phone number to receive it. A shared authenticator holds that setup for a team. The service you are signing in to still sees its own account. It does not gain a list of your teammates or learn who changed a setting after sign-in. Shared MFA Inbox records who requested a code here; the service’s own records cover what happened inside that service. Think of the arrangement as access to one shared account, not a way to turn it into several named accounts. That distinction helps you choose the right setup and explain its limits to an account owner. ## Check for individual logins first Open the service’s people, members or access settings. If it can give each colleague their own login and suitable permissions, use that route. You may be able to grant someone report access without allowing them to change billing or spend money. A shared login cannot add those limits where the service has none. Some older tools and supplier portals offer only a company login. Others have a shared account that your company is permitted to use for a specific job. Confirm the service’s rules and your own policy before moving its code. Do not use a shared setup for an account that must remain tied to a named individual. Write down why sharing is needed. A useful note might say that the depot has one booking account used by two shifts. “It was set up this way years ago” is a reason to review the account, not proof that sharing is still the best choice. ## Choose a team whose whole member list fits Every member of a Shared MFA Inbox team can see and use all authenticator accounts in that team. There is no separate grant for each authenticator account. A clear label helps people find an entry, but it does not hide the entry from anyone else on the team. Review the complete member list, including contractors, client contacts and people who only use SMS. If you add an authenticator account, those members can use it too. If you invite someone later, review the account list they are gaining access to. Membership is the access boundary for this part of the product. Where different groups need different access, use teams with the right membership or the source service’s own controls. Do not place an account in a broad team while waiting for a narrower grant to appear. That control is not available. For agencies, this check should happen before the client shares a setup key. ## Understand the three things you may see during setup A service may show a QR code, a setup link or a manual key when you add an authenticator. Each can contain the secret used to make future codes. Handle that setup as a credential. It is different from the short code you enter to finish one sign-in, and it remains useful after that short code expires. Recovery codes are different again. They are issued by the service as a way back in when the usual check is unavailable. Keep them in an approved secure location that the account owner can reach. Shared MFA Inbox is not a replacement for that service’s recovery process, and a working browser session is not a recovery plan. You do not need to paste setup keys or codes into a team chat to explain the change. Share the service name, the account label and the steps teammates should follow. Use the [migration guide](https://sharedmfainbox.com/blog/move-authenticator-to-team) while an authorized person still has access to the service’s security settings. ## Make the first sign-in a small, complete test Start with one account whose use can be checked without changing a live order, moving funds or interrupting a launch. Create your team, review its members and add the service’s supported setup to MFA Accounts. Check the account name and settings before saving. Similar names are easy to confuse when several regions use the same supplier. Generate a code and finish the service’s setup flow. Then test an actual sign-in from a separate browser session. Ask another intended team member to do the same from their own Shared MFA Inbox login. That proves the handover works for someone other than the person who created it. Keep a working recovery route throughout the test. If the service forces you to replace its old method, read that step before confirming it. Do not remove the last working route based only on seeing a code in the app. The real check is whether the service accepts it and lets the right person in. ## Know what the activity log can tell you The activity log records account changes and code generation and copying, with the person and account involved. That can help answer who requested a code during a handover. The setup key and generated code are not included in those log entries. It does not prove who completed a third-party sign-in or which action they took there. Someone might request a code and never use it. Two people may reach the same shared service account. Keep the outside service’s records when you need evidence of a change to a campaign, invoice or booking. Saved setup keys are stored in encrypted form and used by the server to generate codes. The app does not return the saved key to teammates. This is not a promise that the service cannot read the key. Choose the product with that trust model in mind and review the [security page](https://sharedmfainbox.com/security) for the current boundaries. ## Keep SMS available for accounts that need it Some company services still send a text instead of offering a supported authenticator setup. For those, a shared SMS inbox receives messages at a company number. You can grant access per number, and team admins can see all numbers. Every message sent to one number shares that number’s audience. This access model differs from MFA Accounts. Giving a teammate access to one SMS number does not create a matching limit on authenticator accounts. Likewise, being a team member does not give a non-admin access to every SMS number. Review the method the account actually uses when checking permissions. Your first shared authenticator account is free; additional accounts are billed monthly or annually. See [pricing](https://sharedmfainbox.com/pricing). SMS has a per-number price listed on the [pricing page](https://sharedmfainbox.com/pricing). Number acceptance is decided by the service sending the text, so test it before relying on it. The [method comparison](https://sharedmfainbox.com/blog/authenticator-app-vs-sms-for-teams) explains the practical differences. ## Plan the next change in people Add an owner and an access review date to your account list. When someone changes role or leaves, remove access here and review the source service as well. An open session, old recovery code or a setup key copied before the move may still provide another way in. Replace exposed credentials at the source service where needed, then test the remaining team’s access. Deleting the entry here does not reset that service’s MFA. Use the [offboarding checklist](https://sharedmfainbox.com/blog/shared-mfa-offboarding-checklist) to cover both places. A shared code is most useful when setup, daily use and the eventual handover are all planned. ## 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-for-teams Every page of this site is also available as Markdown. Site map: https://sharedmfainbox.com/llms.txt