How should a team store 2FA recovery codes?

Team 2FA recovery codes belong in encrypted, access-controlled storage that's separate from the account the codes unlock, with a record of who has accessed and used them — not a shared spreadsheet, a screenshot saved to a drive, or a pinned message in chat, all of which are unencrypted, over-shared by default, and leave no trail of who used which code. The goal is to treat recovery codes with the same discipline you'd apply to any other high-value shared credential, because that's exactly what they are: a bypass for the very authentication step they're backing up.

Why the obvious places go wrong

Recovery codes tend to end up in whatever tool is fastest to reach for during setup — a note in a shared drive, a message to a team channel, a line in an onboarding spreadsheet. Each of those has the same underlying problem: they're protected by whatever access control that tool already has, which is usually broader than intended (anyone with a shared link, anyone who was on the team six months ago and never had access revoked) and rarely encrypted specifically for this purpose. A drive folder or chat channel is also one of the first places an attacker looks once they've compromised any single account on your team, which makes it a poor hiding place for a credential meant to survive account compromise.

A more subtle version of the same mistake is storing recovery codes inside a tool that itself needs 2FA to open. If the codes for your identity provider live in a document whose access also depends on that identity provider being reachable, you've built a circular dependency that fails exactly when you need it not to.

A practical approach

1. Use dedicated, encrypted storage — not a general-purpose document. The specific tool matters less than the property: the codes should be encrypted at rest, and opening them should require an explicit access-control decision, not "anyone with this link."

2. Track which codes are spent. Most services issue single-use codes in a batch; storing them without a way to mark which ones are already used risks a failed attempt with a code that looked available but wasn't.

3. Limit who can retrieve the full set. Not everyone on the team needs standing access to recovery codes for every shared service. Scope access to the people who'd realistically need to use them during an incident.

4. For your highest-value accounts, consider splitting the codes rather than storing them whole. This mirrors quorum-based secret sharing: instead of one vault holding the complete set, a threshold of people must act together to retrieve one, so no single compromised account or departing employee walks away with everything.

5. Regenerate periodically, and always after a suspected exposure. Recovery codes don't expire the way an OTP does, which is exactly why they need active management rather than being written down once and forgotten.

How Glassbreak fits this

Encrypted secrets are Glassbreak's core storage primitive, and team secrets use exactly the threshold approach described above: a secret is split with Shamir's Secret Sharing so recovering it requires a quorum of independently authorized members, not one person's access to a shared vault. Glassbreak itself never holds a key that could decrypt a stored secret — the cryptographic details are on the security page. For a team already thinking about shared credential storage more broadly, not just recovery codes, the shared credential vault page covers per-team vaults, roles, and one-click offboarding, which closes the "departed employee still has access" gap that plain document storage doesn't. Every plan, including Free, includes encrypted secrets — see pricing for what scales with team size.

The habit that matters more than the tool

Whatever storage you choose, the practice that actually prevents an incident is treating recovery codes as a managed credential with an owner, not a one-time setup step. Review who has access when someone joins or leaves the team, regenerate after any suspected exposure, and confirm — before you need to, not during an outage — that the person who'd actually reach for the codes at 2 a.m. knows where they are and can get to them.