A practical threat model for sharing recovery codes

Why recovery codes deserve their own threat model

Most people treat recovery codes as an afterthought. You screenshot them, paste them into a note, or forward them to a colleague in a Slack DM with the message "keep this safe." Then they sit there — in chat history, in a synced notes app, in an email thread — indefinitely.

That's a problem worth thinking carefully about, because a recovery code is categorically different from a password. A password can be rotated. A recovery code is often a static bypass of every other control on an account: MFA, login alerts, device trust, all of it. Whoever holds the code can get in regardless.

The actual threats you're protecting against

Before picking a tool, be specific about what can go wrong. For recovery codes, there are four failure modes worth naming:

• Persistence: The code exists in a channel — email, chat, a shared doc — long after it was needed. A breach of that channel months later exposes it.
• Over-sharing: You send a recovery code to one person but it lands in a shared inbox, a team Slack channel, or a CC'd thread.
• Screenshot leakage: The recipient screenshots the code, and that image ends up in cloud photo backup, a device backup, or a shared folder.
• No audit trail: You have no idea whether the recipient actually read it, or whether someone else did first.

This is a different shape of risk than a leaked API key. As covered in what goes wrong when secrets sit in chat history forever, the danger with persistent secrets isn't just that they're stolen in the moment — it's that the window of exposure never closes.

Who actually needs recovery codes, and when

Let's get concrete. Here are the real scenarios where you end up sharing a recovery code:

• IT onboarding a new hire who needs access to a shared service account
• A business owner handing MFA backup codes to their accountant at tax time
• A sysadmin setting up a service and leaving recovery codes with a backup admin
• A journalist giving a source access to a secure communications account
• A developer handing off access to a critical third-party service during a handover

In each case, the code has a defined recipient and a defined purpose. It needs to get from you to them once — and then it should stop existing in transit.

Why one-time links fit this use case well

A one-time encrypted link solves the persistence problem cleanly. You encrypt the recovery code client-side, generate a link that works exactly once, send it, and when the recipient opens it the note is gone. There's no copy left on the server, and if anyone intercepts the link after it's been read, they get nothing.

The key detail — and one that's worth understanding rather than taking on faith — is where the decryption key lives. On SecureNotes, it lives in the URL fragment (the part after the #). Fragments are never sent to the server in HTTP requests, which means the server processes the note without ever seeing the key. This is the same zero-knowledge principle described in how zero-knowledge architecture works in SecureNotes.

What this means practically: even a full server-side breach doesn't expose the content of unread notes. The attacker gets encrypted ciphertext and no key.

Where the one-time link approach has limits

One-time links aren't a complete solution on their own, and it's worth being honest about the gaps.

First, the link itself is sensitive until it's opened. If you send it via an unencrypted channel and the recipient's email is compromised before they open it, the attacker can read the note first — and you won't necessarily know (though the recipient's failed attempt to open it would give you a signal).

Second, there's a delivery problem. If the link gets lost in transit and the recipient never opens it, the note is gone and you need to create a new one. That's annoying but it's the right tradeoff — the alternative is a note that stays up indefinitely.

Third, one-time links don't protect against the recipient being the threat. If you're sharing a recovery code with someone you don't fully trust, that's a people problem, not a technical one. The right answer there is usually to question whether they need the code at all.

Pairing the link with an out-of-band confirmation

A simple workflow that works well in practice:

1. Create the encrypted note with the recovery code.
2. Send the one-time link via whatever channel you'd normally use — email, Slack, a ticket.
3. Tell the recipient to confirm receipt via a different channel: a quick text, a phone call, or a verbal confirmation.
4. Once they confirm, you know the note was read by the right person. If they come back to you saying the link was already consumed and they didn't open it, you have an incident to investigate.

This is the same out-of-band verification principle recommended for passcode-protected notes — you separate the secret from the confirmation channel so that compromising one doesn't automatically compromise the other.

For teams with more structured needs, the SecureNotes API lets you automate note creation and build this delivery step into existing workflows — useful if you're onboarding new hires regularly or rotating credentials after a contractor offboards.

What to do after the recovery code is shared

Sharing the code securely is only half the job. Once it's delivered:

• Confirm the recipient has stored it in their own password manager or a secure vault, not a sticky note or a screenshot.
• If the code was shared for a one-time use (account recovery, an emergency login), regenerate the codes afterward. Used codes should be treated as burned.
• Log that you shared it and with whom. You don't need an elaborate system — a one-line entry in a private ops log is enough. If there's ever an incident, you'll want to know the blast radius.

Recovery codes sit in a category with other static credentials — SSH private keys, signing certificates, root passwords — where rotation is hard but persistence is dangerous. The same thinking applies to any secret that doesn't expire on its own. The complete guide to secure password sharing covers the broader picture if you're building team policies around this.

Share one secret, then forget it ever existed

Recovery codes are too important to treat casually and too sensitive to leave sitting in a chat thread. A one-time encrypted note takes thirty seconds to create and eliminates the persistence problem entirely. Compose a note on SecureNotes the next time you need to pass a recovery code — and send a link that disappears the moment it's read.