Account recovery without handing over more

Signing into an account usually asks for one thing: proof you know a password, or proof you hold a device. Losing access to that account asks for something different. Recovery flows exist to answer a harder question. If you don’t have the thing you normally prove yourself with, who are you? That question tends to pull in whatever the service can get. A phone number. A backup email. A photo of your ID, an address, sometimes a copy of a utility bill.

None of that is malicious by default. Recovery is a real problem, and services that skip it end up with a support queue full of people permanently locked out. But the data collected to solve “prove you’re you when your usual proof is gone” often outlives the recovery event itself. A phone number added for account recovery becomes a marketing contact field. An ID uploaded to unlock a suspended account sits in a verification vendor’s database indefinitely. The threat model worth thinking through isn’t “will I get locked out,” it’s “what does the fallback plan cost me if I never actually need it.”

The phone number problem

SMS-based recovery is the most common fallback. It’s cheap for the service and familiar to users. You lose your password, you get a text with a code, you’re back in. The privacy cost is that the phone number becomes a durable identifier tied to the account, and increasingly to every other account that reuses the same recovery pattern. Phone numbers are also weaker than they look as a security mechanism: SIM swapping works because carrier account changes and phone number porting were designed around customer convenience, not attacker resistance. A number that a support agent can move to a new SIM with the right sounding answers isn’t a strong secret, it’s a lookup key that happens to also work for identity theft.

None of this means SMS recovery is unsafe to have as an option. For a low value account, the convenience is a reasonable trade. The point is to be deliberate. Don’t hand a number over reflexively. Every recovery prompt asks. Once a service has it, it’s part of the profile they hold on you, searchable and correlatable with every other service using the same number.

Security questions answer trivia, not secrets

“What street did you grow up on” and “what was your first pet’s name” were designed at a time when this information wasn’t easily discoverable. It usually is now, sitting in old social media posts, obituaries, public records, or answered honestly by family members on their own accounts. Security questions fail as a recovery mechanism for the same reason they fail as an authentication mechanism. They check whether you know a fact. Not whether you’re authorized. And facts about a person’s early life are rarely private for long.

If a service still requires them, the practical move is to treat the answer field as a second password rather than a factual answer. Type something unrelated to the real question and store it the same way you’d store a password. That way the “secret” being checked is actually secret, instead of something discoverable from a decade-old class reunion post.

Backup codes and recovery keys: unglamorous and it works

The most privacy-respecting recovery mechanism is usually the least exciting one: a set of one-time backup codes or a recovery key generated at setup time, stored somewhere offline. It works because it doesn’t require the service to learn anything new about you. No phone number, no ID, no third party involved. The tradeoff is entirely on you: if you lose the codes and don’t have another recovery path, you lose the account, permanently in many cases.

That tradeoff is worth accepting for accounts where you control the fallback, and worth avoiding for accounts where losing access has real consequences and no support path exists. A password manager entry with backup codes stored alongside it, or a printed copy kept somewhere physically secure, solves the “what if I lose my phone” problem without creating a new data trail. The failure mode is boring and self-inflicted (you didn’t save the codes) rather than someone else’s database getting breached later.

What passkeys actually change

Passkeys shift the recovery problem instead of eliminating it. A passkey is a cryptographic key pair, generated on your device, where the private half never leaves the device or its secure enclave. There’s no shared secret to phish, guess, or leak from a server breach, because the server only ever holds a public key. That’s a real improvement over passwords, which live on both sides of the connection and can leak from either.

The catch is device loss. If passkeys are synced through a platform account (a phone’s cloud backup, a browser’s sync feature), losing the device doesn’t lose the passkey, but it does mean recovery now depends on the security of that platform account. If passkeys aren’t synced, losing the device can mean losing the credential outright unless the service has some other route back in. Passkeys reduce phishing and credential-stuffing risk substantially, but they don’t remove the need to think about what happens when the device holding them is gone. They’re one strong layer, not a replacement for a recovery plan.

When a service asks for a government ID

Some recovery flows, particularly for financial and government-adjacent accounts, escalate to identity verification: a photo of a driver’s license or passport, sometimes a selfie matched against it. This is a categorically different disclosure than a phone number or backup email. Once submitted, that document image typically goes through a third party verification vendor, not just the original service, and it’s rarely deleted promptly even after the recovery case closes.

There’s no way to avoid this entirely for accounts that legally require identity verification, and this isn’t the place for advice on what you’re obligated to provide, since that depends on the service, the jurisdiction, and the account type. What’s worth doing is treating ID-gated recovery as a sign to look at the account’s value and exposure before you’re in a crisis. If a service will only let you back in with a document scan, that’s useful information to have before you lose access, not after, because it changes how much you want that account holding sensitive data in the first place.

A newer pattern, used by some password managers and a handful of platforms, lets you designate trusted contacts who can vouch for your identity or help unlock an account if you’re ever unable to prove it yourself. Done well, this distributes trust to people you actually chose rather than a support queue following a script. Done poorly, it just creates a new dependency: if the trusted contact’s own account is compromised, that path becomes an attack surface too.

If a service offers this, it’s worth using for at least one high value account, but it works best treated the same way you’d treat someone holding a spare house key. Pick someone whose own security practices you trust, and check in on that setup occasionally rather than assuming it’ll still be valid years later.

Building a recovery plan before you need one

The common thread across all of this is that recovery decisions made under pressure, in the moment you’re actually locked out, tend to be the ones that give away the most. That’s when a phone number gets added without a second thought, or an ID gets uploaded because it’s the fastest way back in. Doing the boring version ahead of time, generating backup codes, picking a password manager that stores them, deciding which accounts are worth a synced passkey versus a device-bound one, costs an afternoon and avoids that pressure entirely.

None of this makes an account, or you, untraceable or immune to determined access attempts. It just means the fallback plan doesn’t quietly become the biggest data collection point in the whole relationship.

If you want more explainers like this on how the everyday mechanics of accounts, browsers, and networks actually work, check out the rest of The Privacy Wire.

The moment recovery asks for more than login ever did