Mapping Who Can Reset Your Accounts Before Someone Gets Locked Out

Why recovery paths deserve their own audit

Access rules are usually written around the happy path, where the account holder signs in normally. Recovery is the unhappy path, and it tends to be configured once and forgotten. The person who set up a tool may have used a personal email address for its recovery contact. A shared mailbox may have been reassigned. A phone number tied to a second factor may belong to someone who no longer works with you.

The practical risk is not only that an outsider takes over an account. It is also that legitimate staff cannot get back in, which can halt billing, customer communication, or deployments. Both failure modes come from the same blind spot: nobody has written down who can reset what, or how.

Building an inventory of recovery contacts

Start with a simple list of every tool that holds business data or controls money, customers, or code. For each one, record the account owner, the admin users, and the email address or phone number that receives password reset and verification messages. Note whether that contact is a named individual, a role mailbox, or a personal address.

Then check the recovery options the tool exposes in its settings. Look for backup administrators, alternate verification methods, and recovery codes. Where the vendor provides recovery codes, record where they are stored and who can retrieve them. Do not paste these codes into shared chat or a general document. Use a password manager or another access-controlled store that matches the sensitivity of the account.

Questions to ask before you trust a tool's recovery design

Before adopting or renewing a tool, put a short set of questions to the vendor or to your own testing. Can more than one administrator be designated? Can an administrator change the recovery email without the current email being confirmed? What happens to the account if the sole owner leaves the company? Is there a documented process for an authorized person to regain access, and what evidence does it require?

Ask also what a legitimate recovery looks like from the vendor's side. You want to know whether support staff can bypass verification, how they confirm identity, and whether recovery attempts are logged in a way an administrator can review. If the answers are unclear, treat that as information about the tool, not as a detail to resolve later.

A checklist for quarterly review

Run this review on a fixed schedule, such as each quarter or whenever someone leaves the team. First, confirm that every critical tool has at least two active administrators who are current employees. Second, verify that each recovery email or phone number still reaches a monitored inbox or a device someone actually holds. Third, check that any recovery codes or backup methods are stored in an approved location and that the people who need them know where to look.

Fourth, remove access for anyone who has changed roles. Fifth, test one recovery path deliberately, using a non-critical account where possible, so you learn whether the process works before an emergency. Record the results in the same inventory so the next review starts from accurate facts rather than memory.

Finally, document the procedure itself. A recovery plan that lives only in one person's head fails in exactly the situation it was meant to handle. Keep a short written runbook that names the responsible roles, the locations of stored credentials, and the escalation steps when the primary owner cannot be reached. Good recovery planning is unglamorous, but it is the difference between a bad afternoon and a business that cannot operate until someone finds the right email password.