The handover looked finished. The password moved into the shared vault, the laptop came back. Then someone tries to sign in to the brand account, the login screen asks for a six digit code, and the only device in the world that produces it is a personal phone belonging to a person who no longer works here. That is a different problem from the password, and it is usually discovered at the worst possible moment.
The second factor is a different problem than the password
A shared password vault solves one question: who can retrieve the credential. The vault holds the string, the vault rotates the string, and no phone is involved at any point. That is the model most teams already have, and the subject of the companion piece on sharing brand account access without sharing a password.
A time based one time password works nothing like that. At enrollment the platform shows a QR code encoding a shared secret, the seed. Whatever app scans it stores that seed locally and derives the six digit number from it plus the current time. The platform never sends the code anywhere, it derives the same number independently and checks the two match. The code is not a credential waiting in a vault, it is the output of a computation running on a specific device holding a specific secret.
That is why shared access has to be solved twice. Solving it once, at the password layer, leaves the second factor pinned to whatever hardware was in the room on setup day. If that was one employee’s personal phone, then that phone is a load bearing part of your access control and nobody wrote it down. One scoping note: this piece covers authenticator app TOTP codes only. SMS 2FA and hardware security keys have their own recovery mechanics.
What actually happens when the enrolled phone is gone
Teams find out in one of two ways, and the second is considerably more expensive.
The good version is mid offboarding. Someone walks the handover checklist, reaches the brand account, and notices the 2FA prompt has no owner other than the person leaving. That phone still exists, is still unlocked, and is still reachable on their last day. Whatever the authenticator app supports, you can still use, because the enrolled device is present.
The bad version is weeks later. A session expired and the prompt appears with no way to satisfy it. The phone is gone, the person is gone, and the relationship may not be warm enough to ask. The only route left is the platform’s own account recovery process, built on the assumption that the requester might be an attacker and therefore identity verification heavy by design. That is the price of never having tested the authenticator app’s own multi device or transfer option while the device was in hand. What any given platform requires, and how long it takes, is specific to that platform. [EVIDENCE NEEDED: the current published recovery documentation for the specific platform holding the account]
What Authy, Google Authenticator, and 1Password each let you do about it
Three apps a team likely already has, three answers. All of it from each vendor’s own documentation, checked 6 September 2026.
| App | What its own documentation says about more than one device | If the enrolled phone is already gone |
|---|---|---|
| Authy | The features page lists “Multiple Devices”, described as “Sync 2FA across mobile and tablet”, and “Backup”, described as “Prevent account lockout when you lose your phone”. It also says you can control which devices tokens are accessed from, and “Add new devices with SMS, voice or existing device approval”. | Not exclusively gated on the old phone, since that page names SMS and voice alongside existing device approval. The exact step sequence could not be read this session. [EVIDENCE NEEDED: the current Authy add a device help article, which serves no text to a plain HTTP request] |
| Google Authenticator | Two modes. Signed in to a Google Account, the support article states that when you sign in to that account within Google Authenticator on a new device, your codes are automatically synced to it, with version floors of 6.0 or above on Android and 4.0 or above on iOS. Without a Google Account, the only documented route is manual: on the old device, Menu, then Transfer accounts, then Export accounts, unlock, select accounts, then scan the QR code from the new device running Import accounts. | Depends on the mode chosen at setup. The manual transfer flow lists the old device with the codes on it as a requirement, so it is unavailable once that phone is gone. The article also warns that using Authenticator without an account removes codes from your Google Accounts and stores them on the device, where they will not be available elsewhere. |
| 1Password | The one time password is a field on the Login item, not a device local secret. The support article documents adding it through Edit, then Add More, then One Time Password, from the browser extension, the Mac, Windows, iOS, Android and Linux apps, and 1Password.com. It also states you can share logins with one time passwords by moving them to vaults you have shared with your family or team. | The code travels with the item, so a second person signed in with access to that vault can produce it. [EVIDENCE NEEDED: whether one time password storage is gated to specific 1Password plans, which that page does not address] |
The practical shape of that table: Authy and 1Password both answer “can somebody other than the original phone produce this code” with yes, by design. Google Authenticator answers “yes, if you signed in to a Google Account, and no if you did not and the old phone is gone.” That decision was made silently, at enrollment, by whoever did the setup.
The setup choice that decides which of those two situations you are in
- Confirm enrollment on a second device today, not that it is possible. “Authy supports multiple devices” is a fact about the app. “Our brand account’s token is visible on the agency tablet as well as one person’s phone” is a fact about your access control. Only the second survives a departure. Open the second device and look at the code.
- For Google Authenticator, check which mode each shared account is in. Codes saved to a Google Account or held locally with no account is a per install setting, and it is the whole difference between recoverable and not.
- Find your backup codes, or admit you never saved them. Most platforms issue a set of recovery codes when 2FA is enabled, meant to live outside the authenticator app so a lost device does not take them down too. They are usually shown once. Search your shared vault for them now. If they are not there, they were probably downloaded to a personal machine and lost.
- Test it, and record who holds the second factor next to who holds the password. Sign in with a code produced somewhere other than the original phone. An untested recovery path is a belief, not a control.
A short example of the handoff done in advance
Here is one illustrative sequence, hypothetical rather than a real account. Picture a four person team running a restaurant group’s social presence, about to enable 2FA on the main brand account.
They do not scan the QR code with the social lead’s personal phone. They scan it into the vault item that already holds the account’s password, so the second factor inherits the same access list as the first. Anyone who can retrieve the password can produce the code, and anyone removed from the vault loses both at once.
Where a standalone authenticator app is preferred, they enroll it on a team owned device and add the second device the same day, while both are in hand. The recovery codes go into the same shared vault item, labelled for that account. Six months later, offboarding this account means removing one person from a vault.
FAQ
Is this the same problem as sharing a password for a brand account?
No. Sharing a brand account password solves who can hold and retrieve the credential, which is what the piece on sharing brand account access without sharing a password covers. This one is about who holds the device that generates the second factor. A team can have the first fully solved and still be locked out by the second.
What if the team never saved backup codes and the original device is gone?
The remaining route is the affected platform’s own account recovery process, which you start from that platform’s published help documentation rather than from the authenticator app. What it asks for and how long it takes varies by platform and changes over time, so check the current page for that specific service. Assume it is slower than any of the options above, which is why they are worth setting up first.
Sources
- Authy, Features, fetched 6 September 2026.
- Google Account Help, Get verification codes with Google Authenticator, fetched 6 September 2026.
- 1Password Support, Use 1Password as an authenticator for sites with two-factor authentication, fetched 6 September 2026.
- 1Password, Two factor authentication, fetched 6 September 2026.
Product documentation for Authy, Google Authenticator and 1Password verified 6 September 2026 from each vendor’s own pages. This is a blog piece, not Watchdog data, and it is not on the re-verification schedule. followedapp is published by the team behind RecurPost, and RecurPost is covered vendor #34 under the same rules as every other vendor.