How to Share Microsoft Authenticator Codes With a Team

Before choosing how to share anything, work out which of two different things your account actually uses. Microsoft Authenticator does both, and they have opposite answers.

If signing in produces a prompt on a phone asking someone to match a number shown on screen, there is nothing to share, by design, and the fix is on the identity side. If it produces a six-digit code counting down in the app, it is ordinary TOTP, and the fix is to keep the secret in one place while your team reads the codes.

Two products in one app

Push approvals are for Microsoft work, school and personal accounts. The account is registered to a device; at sign-in, the app asks the holder to approve and, since number matching became the default, to type in a number from the login screen. No code is displayed for someone else to relay.

TOTP codes are for everything else. The app stores standard secrets and shows six digits with a countdown, exactly like any other authenticator. Everything true of TOTP elsewhere is true here.

Teams get confused because both live behind the same icon. A colleague says “send me the code from Authenticator” and, depending on the account, that request is either impossible or a bad idea for entirely different reasons.

Why a push approval cannot be shared

Number matching removed the old workaround. When the app only asked “approve or deny”, one person could tap approve while a colleague signed in from anywhere, and any attacker who had a password could spam prompts until someone tapped by reflex. Requiring a number from the screen ties the approval to whoever is actually looking at the login page.

The consequence for a team is that the phone is the factor. There is no string to copy into a vault and no code to read out. Someone can still read you the number so you can approve their sign-in, and that is worth naming as a thing not to normalise: it puts the account holder in the position of approving prompts on request, which is exactly the reflex real attacks are built on.

So for these accounts, stop looking for a sharing mechanism. There isn’t one, and its absence is the feature.

If it is a Microsoft 365 account: fix the identity

Almost every “we all need to sign in to this account” problem inside Microsoft 365 has an answer that removes the shared sign-in. The reason teams miss them is that they look like billing questions.

Per-person accounts. Each person signs in as themselves and registers their own device in their own Authenticator. Administrators keep per-user control, and the audit trail names people rather than an account.

Shared mailboxes. A mailbox several people work out of does not need a login of its own. Access is granted to individual accounts, everyone opens it beside their own mail, and there is no password or second factor to distribute.

Delegated access and groups. Calendars, sites and distribution addresses follow the same pattern: grant the people, not a shared credential.

Emergency access accounts are the one legitimate shared credential in this picture. Microsoft’s own guidance is to keep one or two, held outside the normal policies so an administrator lockout is recoverable. Whatever you decide for them, treat them as a documented exception with sealed credentials and monitoring, not as the template for how the marketing team gets into an account.

If a licence cost is what pushed the team to one shared login, price the alternatives before accepting it: shared mailboxes and delegation exist partly to make that unnecessary.

If it is a TOTP code: the usual three options

For the third-party accounts stored in the app (the registrar, the payment provider, the client dashboard) Microsoft Authenticator is just an authenticator app, with the same three options as any other:

1. Per-person access on the platform, if it offers it. Then nothing is shared.
2. One custody of the secret, with per-person access to the codes and a record of who read them.
3. Someone reads the code out, which works until they are unreachable.

The trade-offs are laid out in best ways to manage 2FA for shared accounts, and the same ground for the other big app is in how to share Google Authenticator codes with a team. Which accounts belong in which bucket: shared account 2FA: how should teams handle it?.

Diagnosing what you have

The last row is worth checking. An approval that requires nothing but a tap is the configuration that made prompt-bombing work.

What not to do

• Restore the app’s backup onto a colleague’s phone. For TOTP entries it duplicates secrets permanently; for Microsoft accounts it does not even work as a shortcut.
• Share one Microsoft account across the team so everyone can use its Authenticator. That concentrates every second factor you own inside one account, which then needs its own protection.
• Screenshot the setup QR code for a third-party account. It is the secret in visual form, and the only way to take it back is to reset 2FA and re-enrol everyone.
• Turn off number matching to make approvals easier to hand around. That trades a real control for convenience you can get properly with per-person access.

Where Share Auth fits

Only in the second half of this article. For third-party accounts that genuinely have one login, the secret is entered once and encrypted at rest, invited members see the code and its countdown rather than the secret, permissions are per member and per account, and every view lands in an access log.

That is what a shared authenticator app does, for the accounts that cannot be split into individual identities.

For Microsoft accounts with push approvals, there is nothing for us to hold. The work there is giving people their own identities, and that is a better outcome than any sharing tool, ours included.