RecoveryCodes

RecoveryCodes helps teams prevent account lockouts by mapping every MFA dependency that lives outside their identity provider.

Most companies believe their multi-factor authentication is under control because Okta, Entra ID, Google Workspace, or JumpCloud sits in front of the apps that matter. That belief holds right up until someone drops their phone in a canal, leaves the company on short notice, or loses the one YubiKey that happened to be the only registered factor on the root billing account. At that point the team discovers an uncomfortable truth: the identity provider only governs the accounts that were actually federated. Everything else, and there is always an everything else, is protected by factors that nobody has documented.

RecoveryCodes is the system of record for that gap. It gives you a live map of which accounts depend on which phone, which security key, which authenticator app, and which employee, so that when a device disappears you already know the blast radius instead of discovering it one locked account at a time.

The problem it solves

Every growing company accumulates accounts that never make it into SSO. Domain registrars, DNS providers, payment processors, app store consoles, cloud root accounts, ad platforms, bank portals, code signing certificates, and dozens of SaaS tools on plans where SSO is priced as an enterprise upsell. Each of these gets protected with TOTP or a hardware key by whoever set it up, usually in a hurry, usually on their personal device, usually without telling anyone.

The result is a quiet single point of failure. One engineer's phone holds the second factor for the production DNS account. One founder's security key is the sole registered credential on the payment processor. One departed contractor still appears as the recovery contact on an ad account that spends five figures a month. None of this is visible in the identity provider dashboard, because none of these accounts were ever connected to it.

When the device goes missing, the cost is not the device. The cost is the days spent grinding through vendor account recovery flows, notarised identity documents, support tickets that take a week per round trip, and in the worst cases, an account that is simply unrecoverable. Meanwhile DNS cannot be updated, payouts cannot be released, and the app cannot ship.

RecoveryCodes exists to make that failure mode visible before it happens rather than after.

How it works

You register the things that actually hold your factors. A phone, a laptop, a hardware security key, an authenticator app profile, a backup key stored in a safe. Each of these becomes a device in RecoveryCodes, owned by a person.

You then register the accounts that depend on them. For each account you record which devices carry a working factor, which method each device uses, who owns the account, and what recovery paths exist if every registered factor is lost. This mapping is the core of the product. Everything else is built on top of it.

Once the map exists, RecoveryCodes continuously answers the questions that used to require a company-wide Slack thread:

• Which accounts would we lose access to today if this specific phone stopped existing?

• Which accounts have exactly one registered device and therefore no redundancy at all?

• Which accounts depend on a person who is leaving in two weeks?

• Which accounts have no stored recovery codes, and no documented fallback?

• When was each account's recovery material last verified as still valid?

Single-device risk detection

The highest value signal RecoveryCodes produces is the single-device risk list. An account with two independent factors on two independently owned devices is resilient. An account with one factor on one phone is a countdown timer.

RecoveryCodes surfaces every account in that fragile state and ranks them so you fix the ones that matter first. A single-device dependency on an internal analytics tool is an annoyance. A single-device dependency on your domain registrar, your cloud root account, or your payment processor is an existential risk to the business, and it should not be sitting undiscovered in someone's Google Authenticator.

The same view exposes concentration risk. If eleven critical accounts all trace back to the same founder's phone, that is not eleven independent risks, it is one incident that takes out eleven accounts simultaneously.

Recovery code management without shared secrets

RecoveryCodes stores recovery codes and backup codes, the one-time strings vendors issue as a last resort when every factor is unavailable. It deliberately does not store shared TOTP seeds.

This distinction matters and it is the design decision the product is built around. A shared TOTP seed turns a second factor into a shared password. Anyone who can read the vault can mint valid codes forever, for every account using that seed, without leaving a trace at the vendor. It quietly collapses two-factor authentication back into one factor and creates a single high-value target that grows more dangerous the more accounts it covers.

Recovery codes behave differently. They are single-use, they are revocable and regenerable at the vendor at any time, using one is a visible event you can audit, and burning a code does not hand over standing access to the account. RecoveryCodes keeps them under controlled access with a clear record of who viewed which code and when, so recovery stays possible without turning your MFA program into a shared secret store.

Access is scoped per account and per person. Viewing a code is an event, not a silent read, and every view lands in the audit log with actor, timestamp, and the account touched.

Device replacement and offboarding

Two workflows turn the map into day-to-day operations.

Device replacement. When someone gets a new phone, RecoveryCodes generates the exact list of accounts that need re-enrolment on the new device, ordered by criticality, and tracks each one to completion. Instead of remembering which apps were on the old device, which nobody ever does accurately, the list is derived from the map. Nothing is missed, and you can see at a glance which accounts are still stranded on a device that no longer exists.

Offboarding. When an employee leaves, RecoveryCodes produces every account where that person holds a factor, is the account owner, or is listed as the recovery contact. That becomes an offboarding checklist you can actually close out. The goal is that access is transferred while the person is still reachable and cooperative, rather than discovered six months later when their factor is the only thing standing between you and a locked account.

Evidence for security reviews

Security questionnaires, SOC 2 evidence requests, cyber insurance applications, and enterprise vendor reviews all ask variations of the same question: show us how you manage authentication and access recovery.

RecoveryCodes exports that evidence directly. Account inventory with ownership, factor coverage per account, single-point-of-failure remediation history, access logs showing who retrieved recovery material and when, and offboarding completion records. Instead of assembling a spreadsheet from memory the week before an audit, you export the state that has been maintained continuously.

Who it is for

RecoveryCodes fits teams past the point where one person can hold the whole picture in their head, and short of the point where every single vendor is federated behind SSO. Startups, agencies, IT and security teams, finance and operations leads, and technical founders who are the current single point of failure and know it.

It does not replace your identity provider or your password manager. It covers the accounts they were never able to reach, and makes sure that losing a device is an inconvenience rather than an incident.