Shared Account 2FA: How Should Teams Handle It?

Handle it in this order. Get rid of the shared login wherever the tool allows it. Where it does not, delegate access per person if the tool has any notion of members. For the accounts that genuinely have one login and one second factor, keep the secret in a single place and give the team access to the codes it produces, with a record of who looked.

Most teams skip to the third case and then share the secret itself, usually as a screenshot of the setup QR code. That is the one move in this whole subject that cannot be undone.

Why teams end up sharing accounts

It is worth saying plainly that shared accounts are not a sign of a careless team. They come from four ordinary situations.

Per-seat pricing. A tool costs €19 per user per month and one person uses it twice a week. The team buys one seat and shares it. This is a budget decision, not a security decision, and telling the team to buy five seats does not change the budget.

A single billing or legal identity. Payment providers, registrars and tax portals are tied to one owner. There is often no second seat to buy.

Accounts the team does not own. Agencies work inside client accounts, with credentials handed over by email at the start of the engagement. Asking the client to restructure their access model is rarely on the table.

Accounts older than the team. Someone created it in 2019 with a personal address, it became load-bearing, and nobody has touched the login since.

None of these gets fixed by a policy that says do not share accounts. What can be fixed is what happens to the second factor once the sharing is a given.

What 2FA changes about a shared account

A shared password is an abstraction: it lives in a vault, and everyone with the vault has it. Turning on two-factor authentication gives the account a physical location: a specific phone, in a specific pocket. That produces two distinct failures, and they pull in opposite directions.

The bottleneck

One person becomes the way in. They get messaged for codes during holidays, on sick days, in meetings, and at the worst possible moment during an incident. Teams work around this by scheduling deploys when that person is awake, which is a sign the account has become a dependency on a human being.

Then the phone gets lost, or replaced, or the person leaves without handing over, and access is gone. Not locked. Gone. What follows is account recovery with a provider, on their timeline, with whatever proof of ownership they ask for.

The silent copy

Faced with the bottleneck, the natural move is to let everyone enrol their own authenticator app from the same setup QR code. It solves availability immediately and creates a problem with no expiry date.

The QR code contains the secret. Once it has been posted in a channel or a shared drive, the number of copies is unknown and unknowable: it is in message history, in search indexes, in backups, and on the phone of everyone who ever scanned it, including people who have since left. The account’s own security page will never mention this. Nothing surfaces it, ever, until someone who should not have access uses it.

The second failure is worse than the first, because the first announces itself and the second does not.

Sort the accounts before choosing a mechanism

The mistake is to pick one mechanism for everything. Sort the list first. For most teams it takes twenty minutes and cuts the real problem down to a handful of accounts.

Accounts that do not need to be shared at all

Check whether the tool supports SSO on the plan you are on, or individual users with roles. If it does, the shared login should stop existing. Each person signs in as themselves, with their own second factor, and there is nothing left to share. This is the only option in this article that removes the problem rather than managing it.

Accounts that support delegation

A large group sits in the middle: one account owns the asset, but the platform lets you add people individually. Cloud consoles let you create per-person users with their own MFA. Ad platforms and business managers grant access to individual accounts against an asset. Payment providers usually let you invite team members who each set up their own 2FA.

Here the shared login remains (the owner, the root, the thing you use twice a year) and daily work happens under personal identities. When someone leaves, you remove one person and touch nothing else. This is the least glamorous and most valuable step in the whole exercise, and it is the one most often skipped because setting it up takes an afternoon.

Accounts with genuinely one login

What is left is the real subject: the registrar, the small SaaS with no team plan, the client account whose owner will not restructure anything, the legacy account nobody wants to migrate. One login, one second factor, several people who legitimately need it.

Five ways teams run that last group

Two of these deserve more than a table row, because they are what most teams actually do.

The dedicated phone is better than its reputation. It keeps the secret off personal devices and it is easy to explain. It fails on availability, since a remote or distributed team cannot use a drawer, and on knowing anything after the fact. As a break-glass device kept with the recovery codes, it earns its place.

The shared password manager is the most common answer, and for a team of three it is often enough. Its weakness is structural rather than sloppy: the password and the TOTP secret end up in the same entry, so a single compromised vault account yields both factors. Most vaults also log that an entry was opened, which is not the same as knowing which sign-in a code was used for. Where the vault does support separating the two and restricting per entry, use that.

What good looks like, whatever you choose

Four properties. They are what separates a shared account you control from one you hope nobody misuses.

• Nobody has to hold the secret to get a code. Then a lost laptop or a departing contractor stops being an incident.
• Access is per person and per account. The person who posts to the social profile has no reason to generate codes for the payment provider.
• Views are recorded as they happen. After an incident, the first question is who had access at the time. Reconstructing that from chat history is not an answer.
• Removing someone is one action. If offboarding means resetting 2FA on eleven accounts, it will quietly not happen.

The mechanics of the first property, codes without the secret, are covered in how to share TOTP codes without sharing the secret, and the practical setup in how to share 2FA codes with your team securely.

A rule you can apply this week

1. List the shared logins that block people. Not every account you own, just the ones where somebody waits on somebody else. Usually four or five.
2. For each, check for SSO or per-user seats on your current plan. Anything that has it leaves the list.
3. For the rest, check for delegation. Members, sub-users, asset-level access. Move daily work there and keep the shared login for ownership.
4. What survives both checks is your actual 2FA problem. Decide where the secret lives, give everyone else access to codes rather than to the secret, and keep a log.
5. Reset 2FA on any account whose QR code has been posted anywhere. You cannot un-share a secret. Treat it as burned and start that account over once.
6. Write down where each secret lives, with the recovery codes, somewhere the administrators can reach without the account it protects.

Step 6 is the one people regret skipping. Storing the only copy of a recovery code inside the account it recovers is a loop that closes at the worst moment.

Where Share Auth fits

Share Auth covers step 4 and nothing else. An account is added once, by whoever administers it, and the people invited see the current six-digit code and its countdown rather than the string behind it. Secrets are encrypted at rest, permissions are granted per member, and each view is written to an access log. Removing a member removes their access across every account at once, with nothing to reconfigure for the people who stay.

It deliberately does not replace your password manager, and it does not replace SSO where SSO exists. If step 2 or step 3 solved an account, that account does not belong here.

What none of this fixes

A shared login is a shared identity, and no amount of tooling around the second factor changes that. The provider’s own audit log will show the account, not the person. A record of who viewed a code is the closest available proxy, and it is a good one, narrowing an investigation from everyone to one name and a timestamp. But it is inference, not proof.

That is the argument for spending the afternoon on step 3 rather than perfecting step 4. Managing shared 2FA well is worth doing for the accounts that have to stay shared. For everything else, the goal is to have fewer of them next quarter than this one.