Nobody picks your lock anymore. They click “I lost access.”

Twenty years of security advice has been about the login screen. Longer passwords. Then two-factor. Then authenticator apps. Then passkeys, which finally solved the thing passwords never could: you cannot phish a credential the user doesn’t know and can’t retype into a fake page.

It worked. On World Passkey Day this May, the FIDO Alliance put the count at roughly five billion passkeys in use worldwide, with 75% of people having enabled at least one and 68% of organizations deploying them for employees. And then both Google and Microsoft spent the same week making an awkward point in public: passkeys aren’t the finish line, because the recovery path behind them usually isn’t phishing-resistant at all.

That’s the whole story. Attackers stopped attacking the login screen because the login screen got hard. They go to the same page you’d go to after dropping your phone in a lake — I lost access — and satisfy whichever challenge is weakest. The FBI’s IC3 logged 1,008,597 complaints and $20.877 billion in reported losses for 2025, and called out account takeover as a named threat for the first time: roughly 4,700 complaints and $359.7 million, with cases complex enough to involve more than 50 simultaneous transfers across multiple banks.

Part 1 — The root-account inventory (45 minutes)

You don’t have hundreds of accounts to protect. You have four, and everything else is downstream of them. Open a blank doc and write these headings:

• The root email. Whatever address can reset the password on everything else. This is the master key, and almost nobody treats it that way.
• The phone number. Not a device — the number itself. It receives codes, approves resets, and can be moved to someone else’s SIM by a person at a counter.
• The password manager or platform vault. The thing holding the other 200 logins.
• The OS / cloud account. Apple, Google, or Microsoft. It syncs your passkeys, holds your backups, and can often unlock the other three.

Now, for each one, do the part that feels tedious and isn’t: go into its security settings and write down every way back in. Not the ways you use — every way that exists and is currently switched on. Recovery email. Recovery phone. Backup codes. Trusted contacts. Security questions. Whether a support agent can do it for you over the phone.

Two rules while you inventory. First, list the paths as an attacker would read them, not as a customer: the question is never “how do I get back in,” it’s “what is the cheapest challenge on this account that a stranger could satisfy.” Second, look for circular recovery — the email recovers the phone, the phone recovers the email, and the loop closes with nothing outside it. That loop is one compromise deep, and it is the single most common finding in this exercise.

Part 2 — The assurance ladder

Every recovery method sits somewhere on a ladder, and your real posture is your lowest enabled rung. Top to bottom:

1. A second passkey or hardware security key on a different device, registered in advance. Strongest fallback there is — it’s the front door twice, not a side door.
2. One-time recovery codes generated by the service, printed, stored offline.
3. A TOTP authenticator app with its own backup, on a device that isn’t your phone.
4. Trusted device or trusted-contact recovery — Apple’s recovery contacts and similar features. Slow by design, which is a feature.
5. Email magic link. Only as strong as the root email, which is why the root email can’t use this.
6. SMS to your phone number. Better than nothing; defeated by anyone who moves the number.
7. A human at a support desk answering knowledge questions. Your mother’s maiden name has been in a breach dump since 2013.

The move is not to add security. It’s to subtract rungs. On each root account, register two methods from the top three, then go turn off everything below rung four that the platform will let you turn off. Adding a hardware key while leaving SMS enabled changes your posture by zero — you’ve built a taller wall next to the same open gate. This is the same discipline as deciding what an AI agent is allowed to touch: the security of a system is set by its most permissive path, not its most impressive one.

Part 3 — Close the three back doors (about an hour)

The phone number (15 minutes, do this one first). Every major US carrier now ships a free account-level lock that makes them refuse port-out and SIM-change requests outright: T-Mobile calls it Account Takeover Protection, Verizon has Number Lock plus SIM Protection, and AT&T’s Wireless Account Lock blocks a dozen categories of account change — SIM swaps, device changes, number transfers, port-outs — from inside the myAT&T app. These are off by default for most people. Turn yours on tonight. It is the highest-leverage fifteen minutes in this entire playbook, because the phone number sits underneath almost every other recovery path you own.

The root email. Three changes. Put it on rung 1 or 2 and nothing lower. Make sure its own recovery address is a different mailbox that isn’t used for anything else and isn’t recoverable via the first one — that’s how you break the circle. And check the account’s forwarding rules and connected apps while you’re in there; a quiet forwarding rule is what a competent intruder leaves behind instead of a locked door, precisely so you don’t notice.

The human. Where a service offers an account passcode or PIN required before support staff can make changes, set one — that’s the control that converts a persuasive phone call into a dead end. Where a service offers “advanced protection” style enrollment that removes phone-based recovery entirely, take it on the root accounts and nowhere else. It is deliberately unforgiving, which is the point, and which is also why you need the next two sections.

Part 4 — The 60-minute lockout drill

Hardening without testing produces a very secure account you can’t get into either. Once a quarter, run the clock:

1. 0:00–0:05. Declare the scenario out loud: your phone is gone as of now — stolen at an airport, powered off, unrecoverable. You have a laptop and whatever is in your house. Put the phone in a drawer. No peeking.
2. 0:05–0:20. Get into the root email. From a browser you’ve never used for it, ideally.
3. 0:20–0:40. Get into the password manager, then the OS/cloud account.
4. 0:40–0:55. Get into your primary bank and one system your work depends on.
5. 0:55–1:00. Score it, and write down every snag by name.

Pass: you’re into all of them inside the hour without using the phone. Fail: anything else, including “I would have been fine if I’d just checked one thing on my phone.” A failed drill on a quiet Sunday is the cheapest security incident you will ever have. Same logic as the failover drill for an AI stack — an untested backup isn’t a backup, it’s a hypothesis.

Worked example of what a real fail looks like: you get into the email fine, because the laptop is a trusted device. The password manager wants a code from the authenticator app that lived only on the phone. Your recovery codes for it are stored in the password manager. That’s the loop, discovered at minute 24 of a drill instead of minute 24 of a very bad Tuesday, and the fix is twenty minutes of printing and a walk to a drawer.

Part 5 — The break-glass kit

One physical envelope or small fireproof pouch, somewhere that is not your desk. In it:

• Printed one-time recovery codes for all four root accounts, dated.
• A second hardware security key, already registered to those accounts.
• A single printed page: the sequence to follow, in order, to rebuild access from zero. Which account first, which method, which fallback if that fails.
• The customer-service numbers for your carrier, bank, and card issuer, written down — because you will not have your contacts.
• Nothing that is a password. Codes and sequence only.

Refresh it when you rotate anything, and at minimum every time you run the drill. One trusted person should know the envelope exists and where it lives. If the thought of that makes you uneasy, note that the alternative is a plan that fails completely the day you’re in a hospital instead of an airport — the same argument as documenting your job so someone else can run it.

Six failure modes

• Circular recovery. Email recovers phone, phone recovers email, nothing outside the loop. One breach takes both.
• Codes inside the vault they open. The most common self-inflicted lockout in existence. Recovery material for the password manager lives outside the password manager. Always.
• The stale contact. A recovery address at a job you left in 2022, or a number you gave up. Dead recovery paths are worse than none: they look like coverage and can sometimes be re-registered by someone else.
• Front-door theater. A hardware key on an account that still accepts SMS. Impressive, and worth exactly as much as the weakest rung still enabled.
• Single-device passkeys. One passkey on one phone is a beautiful lock with one key. Register a second on a different device, or you have converted a security upgrade into a single point of failure.
• Doing this for yourself only. If you run anything with other people, the shared accounts have recovery paths too — usually pointed at one person’s phone, often someone who left. Inventory those the same way.

The 30-day install

• Week 1: Turn on the carrier account lock. Run the root-account inventory and write down every enabled recovery path on all four.
• Week 2: Register a second passkey or hardware key on each root account. Generate and print recovery codes. Then subtract: disable SMS and security questions everywhere the platform allows.
• Week 3: Break the circle — separate recovery mailbox, fresh contacts, support PINs set. Build the break-glass envelope and put it somewhere that isn’t your desk.
• Week 4: Run the lockout drill. Fix what snagged. Book the next drill for a quarter out, and a ten-minute calendar check every six months to catch stale contacts.

Two hours of audit, an hour of settings, an hour of drill. The people who lost a share of that $359.7 million last year did not have weaker passwords than you. They had a back door nobody had ever walked through, and someone else walked through it first.