How TOTP Secrets Work (And Why You Shouldn't Share Them)

A TOTP secret is a random string, 16 to 32 base32 characters, that the provider generates once and never changes. It is not derived from your password, it is not tied to a device, and it has no expiry. Any copy of it produces valid codes forever, and nothing on the account can tell you how many copies exist.

That is the entire case against sharing it. What follows is the detail behind each clause. And, because it usually comes up too late, what to do about an account whose secret has already been passed around.

What a secret is, precisely

The mechanics of turning a secret into six digits are covered in the complete guide to TOTP for teams. What matters here is what the secret is as an object.

It is symmetric. Both sides hold the same value. There is no public half, so there is nothing you can hand out that is safe to hand out.

It is high-entropy and not guessable. 80 to 160 bits of randomness. No practical attack works by computing it, which is precisely why every real incident is a copy.

It has no lifecycle. No expiry, no versioning, no revocation list, no rotation. The protocol has no vocabulary for “this copy is no longer valid”, only for “this secret is no longer configured on the account”.

It is independent of the password. Resetting one does nothing to the other. Teams reset passwords after a departure and leave the second factor in place, which is the wrong half if the secret has travelled.

The places a copy ends up

This is the list worth reading slowly, because the argument against sharing is not that a copy is dangerous. It is that copies accumulate in places nobody is watching.

• The provider’s database, where it belongs.
• The authenticator app of everyone who scanned the QR code.
• The device backup of each of those phones, wherever those backups live.
• The cloud sync of authenticator apps that offer it, which is now most of them.
• The screenshot taken during setup, in a camera roll, itself synced.
• The chat message it was posted in, plus that platform’s search index and retention.
• The shared vault entry, exported at some point into a file nobody deleted.
• The environment variable on a CI runner or a server, if anything automated signs in.

Two things are true of every item after the first. None of them appear anywhere in the account’s security settings, and none of them are removed by any action you can take inside the account.

Why “we only shared it once” is never once

A secret shared once does not stay in one place, because the systems it lands in are designed to copy things.

A phone gets backed up and restored onto its replacement. An authenticator app adds cloud sync in an update and the secret is now in an account you did not think about. A vault gets exported before a migration. A chat platform keeps history and makes it searchable to everyone who joins later, including people who were not in the team when the message was posted. A contractor’s laptop leaves with the contractor.

None of this requires anyone to behave badly. It is the ordinary operation of consumer software, and it is why the number of copies of a shared secret only ever goes up.

What sharing it costs you, in four words

Count. You cannot know how many copies exist.

Revocation. You cannot remove one. You can only invalidate all of them by reconfiguring the account.

Independence. A secret stored next to the password means one compromise yields both factors, which is one factor with extra steps.

Attribution. Any of the copies could have produced the code used at 03:12. No log anywhere will tell you which.

Everything a team wants from 2FA on a shared account, from availability without a bottleneck to offboarding that works to an answer to who signed in, follows from not distributing the secret. The mechanics of doing that are in how to share TOTP codes without sharing the secret.

If it has already been shared

Most teams reading this have already shared a secret somewhere. The useful question is not whether that was a mistake but which accounts warrant the work of a reset.

1. Decide what to reset

Reset the accounts where a former holder of the secret could do real damage: anything with money, domains, customer data, publishing rights, or cloud infrastructure. For a low-stakes account whose password you can rotate and whose access list is short, rotating the password and tightening the sharing may be proportionate. Deciding deliberately is the point; deciding by inertia is what leaves a payment account exposed for two years.

2. Reset in this order

The order matters, because two of these steps can lock you out if taken first.

1. Confirm you have current recovery codes, or can obtain them, before touching anything.
2. Disable 2FA on the account. Every existing copy of the secret dies here.
3. Re-enable it, and put the new secret in exactly one place.
4. Grant access to the people who need codes, without distributing the new secret.
5. Re-issue and store the recovery codes, outside the account they recover.

3. Then clean up what the reset did not touch

This is the step that gets skipped. Resetting the second factor does not generally end anything already in progress:

• Sign out all devices and sessions. An attacker with a live session does not need codes.
• Rotate the password, since the two credentials usually travelled together.
• Review API keys, tokens and connected apps. They authenticate without the second factor by design, and they survive its reset.
• Check the account’s own access and login history for anything from a period or a location that should not exist.

4. Write down where the new secret lives

One line per account: where the secret is, who administers it, where the recovery codes are. The absence of this note is what makes teams reluctant to reset anything, because nobody is sure what will break.

Where a secret should live

One place, reachable by at least two administrators, separate from the recovery codes, and separate from the account it protects. Whether that is a restricted entry in your password manager or a tool built for it matters less than the “one” part.

Share Auth is one answer: the secret is entered once, encrypted at rest, and never shown again. Members see codes and countdowns, access is granted per person and per account, and each view is logged. What it removes is the reason teams distribute secrets in the first place, which is that the person holding the phone is not always available.

The short version

• A TOTP secret is permanent, symmetric and unrevocable in isolation.
• Sharing it costs you count, revocation, factor independence and attribution.
• Copies multiply through backups, sync, exports and chat history, without anyone doing anything wrong.
• If it has been shared, decide account by account, reset in order, and clean up the sessions and tokens the reset leaves behind.
• Then keep exactly one copy, and give people access to codes instead.