How to Share TOTP Codes Without Sharing the Secret

The secret and the current time are the only inputs a TOTP code has, so you cannot compute one without the secret. The trick is not to share the secret differently, it is to stop each person’s device from needing it: something holds the secret and hands out codes on request. That distinction is the whole subject of how to share 2FA codes with your team securely; this article is about the mechanics.

Why the difference matters so much

A code is worth about thirty seconds. Sending one to a colleague is roughly as sensitive as reading out a parcel tracking number: by the time it leaks, it is already invalid, and it was only ever good for one login attempt.

A secret is worth everything the account is worth, for as long as 2FA stays configured. It is typically 16 to 32 characters, it is what the QR code contains, and copies of it are invisible: nothing in the account’s security page will ever tell you that four people scanned the setup screen in 2024.

That asymmetry is why “we share the codes” and “we shared the QR code once” are completely different security postures, even though both feel like sharing 2FA.

Three ways to hand out codes, not secrets

A shared vault that displays codes

The secret is entered once, by whoever administers the account, and stored encrypted. Teammates who have been given access open the entry and see the current code with its countdown. They never see the string behind it, and they cannot enrol their own app from it.

This is the general-purpose answer, and the one that survives people joining and leaving, because access is a list you edit rather than a secret you cannot recall.

In product terms this is a shared authenticator app: the vault holds the secret, the people hold nothing.

An API call from your own tooling

If the login is performed by a script, such as a nightly export, a CI job or a bot that posts to a client account, the code does not need to reach a human at all. Your tooling requests the current code at the moment it signs in, and the secret stays on the server side.

The rule of thumb: whatever credential your script uses to request the code must be as protected as the account itself, and scoped to the one account it needs.

Reading it out loud, deliberately

Someone with access reads the code to a colleague on a call. This is worth naming, because it is what most teams already do, and it is not wrong. It shares exactly the short-lived thing and nothing else.

Its limits are practical rather than cryptographic: it needs both people awake at the same time, it leaves no record of who signed in, and it makes one person the bottleneck for everyone else.

What you give up by sharing the secret instead

If the secret does go out, whether pasted in a channel, screenshotted or dropped into a shared note, three things become true at once, and stay true until 2FA is reset:

• You lose the count. There is no way to know how many devices hold it.
• You lose revocation. Removing someone from a channel does not remove the secret from their authenticator app.
• You lose the second factor’s independence. Anywhere the secret sits next to the password, an attacker who reaches that place has both factors.

None of this is theoretical, and none of it shows up in an audit of the account itself. It shows up months later, when someone who left the company still has a working code generator.

A short checklist

• The secret is entered once, in one place, by an account administrator.
• Everyone else has access to codes, granted per person and per account.
• Code views are logged, so “who signed in on Tuesday” has an answer.
• Recovery codes are stored with the secret, not distributed with it.
• Any secret that has been posted anywhere is treated as burned: reset 2FA on that account and re-enrol.