I deleted my authenticator app: what comes back

The phone is fine. The app is gone — swiped off the home screen in a tidy-up, cleared out in a storage purge, or removed by somebody who did not know what it was. And under the panic there is one specific question: if I install it again, do the codes come back?

Reinstalling restores nothing by itself. What it restores is whatever something else was already holding on your behalf — and which "something else" that is differs enormously between apps. Two authenticators deleted from the same phone in the same minute can land in completely different places, and nothing on the App Store page tells you which one you were using.

So this page does three things. It gives you the per-app answer with each vendor's own documentation attached, it names the moves that quietly destroy a recovery you still have, and it gives you an order to work through tonight.

The short answer

• Deleting the app turned off two-factor authentication on exactly zero accounts. Every service still wants a code.
• A reinstall returns only what a sync account or a backup was already holding. No sync, no backup, and the app comes back empty — the secrets were on the device and they went with it.
• Whether that applies to you depends on which app it was, not on which phone. The table below is the whole answer.
• Do not re-enrol anything, and do not factory-reset the phone, until you have checked whether the phone's own backup still holds the app's data. On both iOS and Android that route is one-shot, and both of those moves spend it.
• The fastest way back in is a device where you are still signed in. An active session is a credential.
• Fix your primary email first, then anything financial. It is a dependency order, not a priority order.
• KeyNesta is zero-knowledge. With no sync and no backup file, we cannot restore your vault either, and the rest of this page is written as if you are not a customer.

Deleting the app did not switch off 2FA anywhere

A time-based code is not issued to you by the service at sign-in. The service and your app each hold a copy of the same secret and each compute the same six digits independently — which is why the app works on a plane. RFC 6238 states the arrangement as a requirement: "The prover and verifier MUST either share the same secret or the knowledge of a secret transformation to generate a shared secret" (RFC 6238 §3).

Nothing in that sentence is a device. Deleting the app destroyed your copy of a shared secret. The service's copy is untouched, so three things follow:

• Every account still demands a code. The enrolment lives on the service's side of the arrangement, and it has no idea anything happened.
• There is nothing to "undo". An enrolment is removed by you, on the service's security page, while signed in. Google's own instruction for a device whose codes were not synced is to "visit every site that you have Google Authenticator set up on to remove the codes, and then relink your new device" (Google Account Help). Visiting every site is the work, and it is the same work whether the phone was lost or the app was deleted.
• Nobody else gained anything. This is a lost copy, not a breach. Unlike a stolen phone, there is no second party here and no reason to rotate anything in a hurry.

Removing one entry is not the same as removing the app

These get written about as if they were one topic, and they behave very differently.

You deleted a single entry inside an app that is still installed. The app is intact; one secret is gone from it. The trap is that if that app syncs, the deletion syncs too — 2FAS says changes like adding or deleting codes "will immediately appear on other synchronized devices" (2FAS), and the same logic holds anywhere a vault is kept consistent across devices. Deleting the app afterwards and reinstalling it will not bring that entry back; it will faithfully restore the vault without it. What can bring it back is an older backup file, if you have one, or the service's own re-enrolment.

You deleted the whole app. Then the entire local store went at once, and on iPhone that is explicit rather than incidental: "Deleting an app removes it and its data from your iPhone" (Apple). Note what that is not: offloading. An offloaded app "frees up storage used by the app, but keeps its documents and data", and leaves the icon on the Home Screen with a cloud symbol. If the icon is still there with a cloud on it, tap it — you have not lost anything.

What a reinstall actually restores, app by app

Every row below is what that vendor documents, and any app whose behaviour could not be sourced to its own documentation is simply not here.

Four details that sit underneath that table and decide a lot of outcomes:

• A backup you cannot decrypt is not a backup. Authy, 2FAS, Aegis and KeyNesta all put the encryption key in your head rather than on a server, which is the correct design and also the reason people lose vaults they technically still have. Twilio is explicit that "the encryption/decryption key is never transmitted". If the password is gone, the ciphertext is noise.
• Microsoft's backup does not cross platforms, in either direction: "accounts backed up using an iOS device cannot be restored on an Android device." If you deleted the app on an iPhone and are rebuilding on an Android, that row does not apply to you. Microsoft also notes that from January 2027 Android backup stops using a personal Microsoft account and moves to Google One backup, so check its current page before following older steps.
• Sync is not the same as end-to-end encrypted sync, which matters if you are here because you care who can read your vault. Google says Authenticator codes are "encrypted in transit and at rest across our products" — encrypted in Google's systems, which is a weaker claim than end-to-end. Proton and KeyNesta both state end-to-end encryption, meaning the server cannot decrypt what it stores. The restore experience looks identical from the outside; the trust model does not. What zero-knowledge costs you is that trade in full.
• A restore is a point in time. Anything you enrolled after the last backup is not in it, and falls back to re-enrolment at the service. That is the same gap that makes an untested backup a belief rather than a backup.

If what you actually want is the planned version of this — old phone still in hand, moving deliberately — the per-app walkthroughs live at move to a new phone.

The phone's own backup is the last copy, and it is one-shot

If no row above applied to you, there is still one place the app's data might exist: your phone's own backup. This is the part the pages ranking for this question skip entirely, and it is time-sensitive in a way nothing else here is.

On iPhone. The data went with the app, so the only remaining copy is inside a device backup — and getting it out means restoring the whole device, not the app: "If you already set up your device, you need to erase all of its content before you can use these steps to restore from your backup" (Apple). Meanwhile the clock is running against you, because "iCloud automatically backs up your iPhone daily when iPhone is connected to power, locked, and connected to Wi-Fi" (Apple). Every one of those overwrites the newest backup with a phone that no longer has the app on it. Two things follow: decide before tonight's backup runs, and do not go into the backup settings to turn the authenticator off to "save space" — Apple warns that "the apps' existing backup data will also be deleted from iCloud".

On Android. The restore is attempted exactly once, at install: "Data is restored whenever the app is installed, whether from the Play Store, during device setup... or by running adb install. The restore operation occurs after the APK is installed but before the app is available to be launched by the user" (Android Developers). So the reinstall is your one attempt — make it on the same device, signed in to the same account. And if the app opens empty, stop there rather than starting to use it, because "Only the most recent backup is stored. When a backup is made, any previous backup is deleted."

Factory-resetting is not a neutral act here. Android stores backups per device-setup-lifetime: "If the user factory-resets a device and then sets up the device with the same account, the backup is stored in a new dataset." A reset to "start clean" starts a new dataset, and the old one ages out. On iPhone, erasing to restore is the documented route — but only once you know which backup you want, and only before a fresh one has replaced it.

Whether a given authenticator participates in any of this is the app's decision, not yours — Aegis, for instance, has an explicit Android cloud backups setting that is off until you turn it on, and it works only for encrypted vaults (Aegis). Which is the honest summary of this whole section: it is worth ten minutes of checking, it is not a plan, and it is gone the moment you treat it casually.

The fastest route back in is a session you are still signed in to

Before any re-enrolment, inventory the places you are already logged in: the laptop browser, the work machine, the tablet, the desktop app that has not asked you for anything in months. Each one is an authenticated session, and most services will let an authenticated session change its own security settings.

That is a documented recovery path, not a trick. GitHub lists "previously verified device" alongside an SSH key and a personal access token among the factors it will accept when your 2FA credentials are gone (GitHub Docs) — and its ladder starts, as everyone's does, with the recovery codes you were given at setup and probably never filed. Where to store your 2FA backup codes covers finding them, spending one, and regenerating a set.

Three rules for tonight:

• Do not sign out of anything, anywhere, and do not clear cookies or site data while you work through this.
• Expect a re-prompt. Plenty of services ask for a second factor again before letting you edit security settings, so an open session is a strong start and not a guarantee. That is the moment a recovery code earns its keep.
• Use the session to get ahead, not just to get in: while you are there, generate fresh recovery codes and save them somewhere that is not this phone.

Work through the accounts in this order

1. Your primary email. First, always. Nearly every other account's recovery route ends with a message sent to it, so an inbox you cannot open turns every subsequent recovery into a two-step problem. If that inbox is itself protected by a code from the app you just deleted, read locked out of email and 2FA first: the way out of a ring is not the account you want most.
2. The account your phone signs in with — Apple Account or Google Account — and your password manager. These hold or gate most of the rest, including, awkwardly, the device backup discussed above.
3. Domain registrar, DNS and cloud provider, if you run anything that other people depend on.
4. Anything financial: banks, brokers, exchanges, payment accounts. Deliberately after email, not because it matters less but because its recovery is the slowest and most identity-heavy, and it will almost certainly want to email you. Expect days rather than minutes, and have the account details they will ask for to hand.
5. Everything else, at whatever pace suits you.

As each account comes back, do two things before moving on: add it to the authenticator you are actually going to keep, and save that service's new recovery codes properly. Re-enrolment is the last resort on this page, but once you are doing it, do it once — a half-rebuilt set of accounts is how people end up back here in six months.

Where KeyNesta fits, and what we cannot do

Plainly, because this page is about what is recoverable and we are not an exception to it.

• If sync was on, open the web app on any device, sign in to your sync account and unlock with your vault passphrase. Your spaces, groups and entries come back, because what the server held was ciphertext your passphrase unwraps.
• If you made an encrypted backup file, restore it in the web app with the password you set when you made it. The vault is rebuilt exactly as it stood at that moment.
• If you had neither, we cannot help you, and that is a property of the design rather than a support policy. The server holds ciphertext, object ids and version numbers, and no key that opens any of it. Nobody here can reset your passphrase. That is the cost of the thing that makes a breach of our servers uninteresting, and it is paid on exactly this page.
• There are no automatic cloud backups. The encrypted backup file is a deliberate act, which is the point and also the catch: it is only as current as the last time you made one.
• KeyNesta holds TOTP and HOTP only — no passkeys and no security keys. The features page names passkeys among what is not built, and an authenticator app of any kind is not a FIDO authenticator. If you want the factor that cannot be phished or deleted off a home screen, that is a security key, and passkeys are the other half of that answer. We are not a substitute for either.

The honest version of the pitch is small: an authenticator you can open from a second device without copying a secret around is a category of evening you never have again. 2FA backup and sync is the whole mechanism, and the web app needs no sign-up if you want to look first.

Takeaway

Reinstalling the app is not a recovery. It is an empty container that may or may not get filled, and what fills it was decided weeks ago, by whether you signed in to something, switched a backup on, or exported a file.

So tonight, in this order. Work out which app it was and read its row above. If nothing applied, check the phone's own backup before you reinstall-and-use, re-enrol or reset anything, because each of those is a door closing. Then open the sessions you are still signed in to and start with your email, not your bank. And when it is over, pick a vault with a backup you have actually tested — because the difference between a bad hour and a bad fortnight was never the deletion. It was whether a second copy existed before it.