Playbook

Authenticator Apps: The Second Factor That Locks Out Your Executor

Platform claims verified July 25, 2026

What this mechanism is

Six-digit authenticator codes are not sent to you. They are computed on your device from a seed: a secret string the service gave you once, inside that QR code you scanned at setup. Device and server run the same clock and the same maths, so the numbers agree. Whoever holds the seed can produce valid codes forever, from any device, with no network connection.

That has one consequence that matters for your estate: there is no legacy program for a second factor, and there never will be. No provider can mail your executor a code. The seed is either recorded somewhere they can reach, or every account it protects is closed to them.

This is the most common way a good digital estate plan fails in practice. The executor finds the password manager, opens it, reaches the bank, and stops at a prompt for six digits from a phone that is locked, wiped, or buried. Passwords without second factors are an address without a key.

The artifact that actually solves this is the recovery codes, not the seeds. Almost every service that offers an authenticator app also issues eight or ten single-use backup codes when you turn it on. They are bearer secrets: anyone holding one gets in once. They are also the only part of a 2FA setup designed to be written down and stored, which makes them the natural thing to escrow.

Set it up now

1. For each account that matters (email first, then password manager, bank, phone carrier, domain registrar), find the security settings and locate the backup / recovery codes. Most services let you regenerate them if you never saved them.
2. Put those codes in AmberKey Layer 2 as a secret item, one per account, linked to that account’s card. They are bearer secrets and belong nowhere else.
3. On the account card (Layer 1), record which second factor that account uses: authenticator app, SMS, hardware key, or passkey. Your executor needs to know what they are about to meet, not the secret itself.
4. If you use Google Authenticator, decide about cloud sync deliberately. Signing into a Google Account inside the app backs your seeds up and restores them on a new device, which removes the lost-phone problem. It is not end-to-end encrypted, so Google can technically read the seeds. Either choice is defensible. Recording which one you made is not optional.
5. If you use Authy, set a backup password and escrow that password in Layer 2. Without it the encrypted backups are unrecoverable, including by you.
6. Consider consolidating: 1Password and Bitwarden can hold TOTP seeds directly, so recovering the password manager recovers the second factors with it. Read the tradeoff in Gotchas before you do this.
7. Re-check when your AmberKey liveness nudge arrives. Recovery codes are consumed as they are used, and a set you have burned through is not a plan.

What AmberKey stores

• Layer 1 (metadata): which second factor each account uses, which authenticator app you use, and whether cloud sync is on. Safe for the executor packet, and enough for a survivor to know what they are facing.
• Layer 2 (bearer secrets): recovery codes for each account, the Authy backup password, and TOTP seeds if you chose to escrow them.
• Do not store recovery codes in Layer 1, in the notes field of an account card, or in the same document as the password. A recovery code is a complete bypass of the second factor.

What your survivors do

1. Work from the account card, not from the phone. The card names the second factor, and Layer 2 holds the codes.
2. Use a recovery code to sign in once, then immediately turn off 2FA on that account or re-enrol it on a device the executor controls. Do not burn codes one at a time across weeks.
3. If the deceased’s phone is available and unlocked, the authenticator app on it will keep producing valid codes indefinitely. The seeds do not expire when the person does. Keep that device charged and out of a drawer until the estate work is finished.
4. If codes came from Google Authenticator with sync on, recovering the Google Account recovers every seed with it. See the Google playbook.
5. If there are no codes and no device, the account is reached only through that provider’s deceased-user process, if it has one. Most do not.

Required documents

None on the AmberKey side: a recovery code is bearer, and that is the point. Where you fall back to a provider’s process, expect the usual death certificate plus letters testamentary, and expect that most consumer services have no documented 2FA-reset path for an estate at all.

Expected timeline

With recovery codes in Layer 2: minutes per account. With the unlocked device: minutes. Without either: assume the account is unreachable, and plan on the provider’s deceased-user process only for closure, not for access.

Gotchas

• Storing TOTP seeds beside passwords collapses two factors into one. If the vault opens, both fall together. That is a real security cost, taken deliberately by many people because the alternative is a plan their family cannot execute. If you take it, take it knowingly. Recovery codes in Layer 2 usually get the estate what it needs without merging the factors.
• SMS second factors depend on the phone number surviving you. A carrier that reclaims the number takes every account secured by it. See the phone-carrier playbook; this is why keeping the number alive matters.
• Hardware keys are physical objects. A YubiKey in a desk drawer is worthless if nobody knows it is a key rather than a memory stick. Record where it is on the account card, and register a second key or keep recovery codes.
• Passkeys are usually device-bound or platform-synced. They inherit the legacy story of whatever holds them, which for Apple means they are excluded from Legacy Contact. See the Apple playbook.
• Authy discontinued its desktop apps. If your setup depended on the desktop client, confirm your seeds still exist on a mobile device you control.
• Regenerating recovery codes invalidates the old set. Any time you generate new ones, replace the copy in Layer 2 the same day. A stale code set reads as a plan and behaves as nothing.