Can Multiple People Use the Same TOTP?

Yes. TOTP has no concept of how many people hold a secret, and any number of devices holding the same one will show the same six digits at the same moment. What goes wrong is not the arithmetic. It is the two logins that collide in the same thirty seconds, the clock that drifts on one phone, and the fact that nothing afterwards can tell you who signed in.

Two different questions are hiding in this one

“Can multiple people use the same TOTP” almost always means one of two things, and they have opposite answers.

Several people holding the same secret. The secret is the permanent credential: it does not expire, it is not tied to a device, and there is no registration to cancel. Every additional holder is an uncountable, irrevocable copy of the account’s second factor.

Several people reading the same code. The code is six digits worth about thirty seconds, good for one login attempt. Passing one to a colleague gives away nothing that outlives the conversation.

Both feel like “sharing 2FA”, which is why teams end up doing the permanent one when they only needed the temporary one. That trade-off, and the ways out of it, is the subject of how to share 2FA codes with your team securely. This article stays on the narrower question: what you will actually observe when more than one person is working from the same TOTP.

What actually happens with two devices

The codes match, as long as the clocks do

Two devices with the same secret are not synchronised with each other in any way. They do not need to be: the code is derived from the secret and the current time, and nothing else goes into it. Identical inputs, identical output. The mechanism behind that is in the complete guide to TOTP for teams; the practical point is that a second enrolment is invisible to everyone, including you.

Two logins in the same window: the second one may be refused

This is the symptom that sends people looking for a broken setup. Two people sign in within the same thirty-second step, both reading the correct code, and the second attempt is rejected.

RFC 6238 asks verifiers to accept a given code only once per time step, and most implementations honour it by recording the last step used for an account. From the account’s point of view there is only one user, so the second login looks like a replay of a code that has already been spent.

The fix is to wait for the next code. It is worth knowing in advance, because the natural reaction, assuming the code was mistyped and typing it again, makes the next problem worse.

Retries pile up against the provider’s rate limit

Six digits is a million possibilities, so providers throttle attempts. That throttle counts per account, not per person.

Three people who each try twice have produced six failed attempts on one account, which can be enough to trigger a temporary lockout, a step-up challenge, or a security email to whoever owns the address on file. The individual behaviour is reasonable; the aggregate looks like an attack.

One clock drifts and only one person notices

Clock drift is usually described as an account-wide failure, but with several devices it presents as something stranger: codes work for everyone except one person, consistently, from their device only.

That person’s phone is computing codes for a time step the server has already passed or not yet reached. Nothing is wrong with the secret, and no amount of re-entering it helps. The check is the device’s automatic time setting, on the device that is failing.

Simultaneous sign-ins from several places look like an intrusion

Abuse detection on the provider’s side reacts to patterns, and one account authenticating from two cities inside a few minutes is a pattern it is built to notice. Depending on the service, that produces an extra verification step, a new-device email, a forced password reset, or a session that ends mid-task.

None of this is a TOTP problem, and none of it can be configured away from your side. It is simply what a shared login looks like from the outside, and it gets more frequent as more people use it.

Nothing records which device produced the accepted code

The verifier compares six digits. It does not learn where they came from, because there is nothing in the code to learn from, and enrolling a device sent nothing anywhere in the first place.

So when the account’s own log shows a login at 14:12, that is the end of the trail. If four people can generate codes, four people could have signed in, and the account cannot narrow it further. This is the part that matters after an incident, and it is the reason how to give employees access to 2FA without giving them the secret treats attribution as a requirement rather than a nice extra.

So “yes, technically”, at what cost

Everything above is friction: annoying, diagnosable, survivable. The cost of multiple people holding the secret is a different category, and it does not produce symptoms at all.

You cannot count the copies. Nothing in the account’s security settings will ever say how many devices were enrolled, so the number is whatever your memory of past enrolments happens to be.

You cannot remove one. There is no rotation in the protocol and no per-device registration, which means the only revocation available is disabling 2FA on the account and setting it up again, for everyone at once.

And the second factor stops being independent wherever the secret ends up next to the password: a shared note, a vault entry, a document. One place reached, both factors gone. How TOTP secrets work (and why you shouldn’t share them) goes through where copies accumulate. The short version: they accumulate quietly, and they stay.

The shape the question is really asking for

What people want when they ask this is for several colleagues to be able to sign in to one account. That does not require several people to hold the secret. It requires three things.

One holder of the secret. Entered once, by whoever administers the account, kept in a single known place that at least two administrators can reach. Every other participant consumes codes rather than storing anything.

Codes distributed per person. Each authorised person gets the current code and its countdown when they need it, granted account by account, and removable in one action. Nobody’s device holds anything that outlives their access.

A record of consultations. Since the provider’s log can only ever show the shared account, the log of who asked for a code is the only thing that puts a name against a timestamp.

If the platform in question can give each colleague their own login instead, do that, which is better than sharing anything, and shared account 2FA: how should teams handle it? covers which accounts genuinely have no per-person option. The three requirements above are for the ones that are truly single-login.

Where Share Auth fits

Share Auth is built for that case. The secret is entered once and encrypted at rest; invited members see the code and its countdown, never the secret behind it. Permissions are set per member and per account, every code view is written to an access log, and removing a member removes their access everywhere in one action. Scripts that need to sign in can request codes through the API instead of involving a person.

The free plan covers three secrets and three members, with no card required, which is enough to see whether the shape described above fits how your team actually works.