Recovery-code custody must be explained to the person who holds them

What it is

Recovery codes (backup codes) are one-time high-entropy secrets that prove it is still you when the second factor is unavailable. Explaining custody means saying, at generation: who keeps them, what kind of place counts as safe, what happens after loss or leak, and whether the product will ever show them again. This entry hands a paper or file factor to someone who can understand the duty. It does not argue whether a backup factor must be pre-enrolled—that happens earlier; this is the copy at the moment of generation.

Why it happens

The security model is an equivalent key kept offline. If it is screenshotted into a cloud album, pasted into chat, or stored in the same unencrypted note as the password, the second factor is theatre. If the product does not say “shown this once,” people close the page assuming settings will always have it, and discover there is no copy only when they are lost. Two symmetric failures: too light (“you might want to save these”), so they are not treated as keys; too frightening without a save act (download, print, copy), so they close the dialog and keep a screenshot. The responsibility line must also be drawn: the product will not put the codes in a vault for you; it will notify you when a code is used, so a leak can be seen.

Studying it

In the generation flow, manipulate explanation and save acts; later ask where the codes are and whether they can be retrieved.

Independent variables: whether one save act is forced (download or print confirm), whether “will not show again” is stated, whether “do not store with the password” is stated. Dependent variables: share who can still produce a code after a delay, storing them in a plaintext cloud note, believing settings will show them after loss.

Asking “did you save them?” the same day measures compliance. Return a week later. A download click is not successful custody—spot-check that the file still exists and is not next to the password. Interviews can ask whether they would send codes to “support.”

Where it stops holding

If a password manager has a dedicated recovery-code field, copy may recommend it, still saying it is separate from the login password. When an enterprise has an admin hold the codes, copy must split duties; employees should not think they still have a copy. After one-time codes are exhausted, regenerate and run the explanation again; old copy does not cover new codes. Products that “email you a recovery message” instead of codes are channel possession, not an offline credential, and must not be worded as recovery-code custody.

Applying it

• At generation, list the codes full-screen, state “shown this once; each code dies after one use,” offer download and print, and require a check: “I have put these in a password manager or an offline safe place, not in chat.”
• Do not write the codes back in plaintext on an ordinary settings page; settings show “N generated, M used”; revealing the full list requires fresh authentication and counts as regenerate or redisclose.
• Notify a verified channel when any code is used; if the person did not act, warn of a possible leak and offer void-and-reissue.
• Verify: a week after generation, people should produce a code; inability is failed custody. Check that the download is not sitting in the same unencrypted note as the password. Settings must not show the full list without re-authentication. Using one code should send a notice.

Related

• Within the group: H6.12.1 MFA should offer strength options between convenience and security · H6.12.2 A failed second factor needs a pre-enrolled backup method · H6.12.3 Assess device availability before mandating MFA
• Adjacent: H6.11 Password recovery and reset · H6.04 Password rules
• Search terms: recovery codes · backup codes · credential custody