How to Give Employees Access to 2FA Without Giving Them the Secret

Give staff access to the codes and keep the secret with whoever administers the account. In practice one person enters each secret once, grants access per person and per account, and removes that access when someone changes job or leaves. Nobody enrols their own authenticator app, so nobody carries an access you cannot take back.

This article is about the employer’s side of that arrangement: who gets what, and how to run it. The reasoning behind the split is in how to share 2FA codes with your team securely, and the mechanics of handing out a code while the secret stays put are in how to share TOTP codes without sharing the secret.

Start by deciding what the unit of access is

Most teams grant 2FA access the way they grant office keys: someone asks, someone else says yes, and nothing is written down. That works until the fourth hire. Pick a unit instead and stick to it; three hold up.

Per account. The default. Each shared login is something people are either authorised for or not: payments, cloud, the registrar, the main social profile, each client dashboard.

Per role. Instead of granting to Amira, you grant to whoever does Amira’s job. “Finance” gets the payment provider and the accounting tool. “Social” gets the two profiles and the scheduler. When Amira moves teams, the list her replacement inherits is already defined.

Per engagement. Agencies need a third axis: the client. Access to a client’s accounts ends when the engagement does, regardless of who is still employed.

Combining role and account needs no ceremony. A short table, one row per role and one column per shared account, is the document you will use during onboarding and reviews.

Least privilege, applied to codes

Two questions decide each grant. Does this person sign in to this account as part of their job? And if their laptop were stolen tonight, would you want this account on the list of exposures?

The first rules out speculative access. “It’s easier to give everyone everything” is true on the day you set it up and false every day after, because the cost arrives later, at an incident or an offboarding. The second is a sanity check on seniority, since founders and technical leads accumulate every account by default and become the most valuable target in the company.

What least privilege does not mean is making people ask each time. If someone needs an account weekly, grant it. Access that is awkward to use gets routed around, usually by someone reading codes out over chat.

What a new starter’s first ten minutes look like

Enrolment should be a task, not a project. If it takes an afternoon, it will be done badly.

Before their first day

Look up their role in the table and note the accounts it comes with. If the role is new, decide the list now, not during their induction.

On the day

The administrator grants those accounts. The new starter signs in, sees the accounts they are authorised for, and can produce a code for each. There is no QR code to scan and no secret to store, so there is nothing for them to lose or copy.

The part worth saying out loud

Tell them two things. First, that they will never see the secret behind a code, and that this is deliberate. Second, that if they need an account that is not on their list, the answer is a request rather than a workaround. Teams that skip the second sentence get shadow access: someone screenshots a setup QR code for a colleague, and the count of copies becomes unknowable. Why that copy can never be recalled is covered in how TOTP secrets work and why you should not share them.

Joiners, movers, leavers

The word most teams forget is movers. Joining and leaving get attention; changing role rarely does, and that is how access accumulates.

Joining. Grant the role’s list. Nothing more, even if the person is senior.

Moving. Grant the new role’s accounts and remove the old role’s. The removal is the step that gets skipped, and skipping it is how a support agent who moved to marketing two years ago still has the payment provider. Grant per role and a move is one comparison of two lists.

Leaving. Remove the person from every account, on their last day, in one action that changes nothing for anyone else. If offboarding instead means resetting 2FA on nine accounts and asking eight remaining colleagues to re-enrol, that is the tell: your staff hold secrets, not access.

Contractors belong in this flow too, with an end date written down when the access is granted. Nobody remembers to revoke access for a three-week engagement that finished quietly.

What an employee sees, and what an administrator sees

Being explicit about this asymmetry prevents a lot of suspicion.

An employee sees the accounts they are authorised for and, for each one, the current code and how long it has left. They cannot see the secret, accounts they were not granted, or the means to grant access to anyone else.

An administrator sees every account, who has access to each, and the record of which codes were viewed and when. Administrators are also the people who enter secrets and store the provider’s recovery codes.

The sensitive material therefore sits with a small number of named people, and “who can sign in to the ad account?” has a real answer rather than an estimate.

How to present this without it sounding like surveillance

The access log is the part people react to, and the reaction is fair: nobody enjoys learning after the fact that their reads are recorded.

Say it upfront, at enrolment, and explain what it is for in operational terms. When a shared login does something nobody can account for, the first question is who was signed in, and the platform’s own log says only that the account was used. The code log is the only place that distinguishes between five colleagues. It also protects the people using it: a log that shows who did view a code equally shows who did not.

What does not help is framing it as a trust measure. Describe it as plumbing, because that is what it is.

“We trust our people”

The objection deserves a straight answer, because its premise is usually correct: most teams do have trustworthy staff. But trust is not the property being managed. Two others are.

Counting. You should be able to say how many devices can currently produce a code for an account. If people have enrolled their own apps, that number is unknown and stays unknown; nothing in the account’s security page reports it.

Revocability. You should be able to end someone’s access without touching the account. If ending it requires resetting 2FA and re-enrolling everyone else, you will avoid doing it, and the access will persist.

Neither depends on anyone behaving badly. A completely honest team still has phones left in taxis, people leaving on good terms, and contractors whose engagement ended in March. Those are the events this design is for.

One version of the objection is worth conceding, though. If two people share one login, no permission model makes them two identities. Where the account supports proper per-person accounts, that beats any sharing arrangement, and it is the first thing to check when sorting your accounts. See shared account 2FA: how should teams handle it.

Review access on a schedule

Once a quarter, read the list for each shared account and remove the names that should not be there. Add a review whenever someone changes role and whenever an engagement ends.

This takes minutes if access was granted per account. If your only record is a shared vault folder that a dozen people can open, there is nothing to review; the answer is always “everyone”. Accounts nobody has viewed in months usually do not need to be shared at all.

Mistakes that come up repeatedly

Everything to everyone by default. Usually justified as avoiding bottlenecks. It turns every lost laptop into a full-company exposure.

Granting to the person rather than the post. Access follows a name, the name changes job, and nobody knows which grants were tied to the old role. Grant to the role and the move becomes mechanical.

No named administrator. If nobody owns an account’s secret, nobody stores its recovery codes and nobody notices when access drifts.

Treating offboarding as a security project rather than a checklist item. It belongs beside the laptop and the door badge, with the same deadline.

Choosing the mechanism before sorting the accounts. Compare mechanisms only for the logins that genuinely have one set of credentials, as in the best ways to manage 2FA for shared accounts.

Where Share Auth fits

Share Auth is built around this shape. You enter each account’s secret once and it is encrypted at rest. The people you invite see the current code and its countdown, not the string it comes from, so there is nothing for them to enrol elsewhere.

Permissions are granted per member and per account, which is what makes the role-based table above expressible rather than aspirational. Every view is written to an access log. Removing a member removes their access on every account at once, so a departure is one action rather than a migration. There is an API if your onboarding is already scripted.

The free plan covers three secrets and three members with no card, enough to run one team’s real accounts and see whether the permission design holds up.

What this does not solve

A shared login remains a shared identity. Codes granted per person tell you who retrieved one; they do not make the platform’s own audit trail distinguish between your colleagues, and they give you no per-person permissions inside the account. Where a provider offers real user accounts or SSO, that is still the better answer, and this arrangement is for the accounts that offer neither.

It also does nothing about the password. If that sits somewhere everyone can read, keeping the secret separate has bought you the independence of the second factor and nothing else. Worth having, but not the whole of access control.