Recovery Paths and Break-Glass Access: Planning for the Day an Admin Is Unreachable
Most security conversations focus on who can get in. Fewer address the quieter question of who can get back in when the usual route fails. An administrator leaves the company, a phone is lost, a password manager is locked behind a forgotten master credential, or a single employee holds the only recovery email for a billing account. None of these events are dramatic, but each can stop a business from working for hours or days. This article walks through a practical method for mapping recovery paths and designing break-glass access that is safe, documented, and tested, without assuming any particular vendor feature exists.
Start With an Inventory of Recovery Routes, Not Just Logins
Most teams keep a list of accounts and users. Far fewer keep a list of how each account recovers. For every important tool, write down the recovery channels: a password reset email, a backup phone number, a set of one-time recovery codes, a secondary administrator, or a support request to the vendor. Record which identity each channel depends on. A recovery email tied to a personal inbox of a former employee is a recovery route that no longer works, even though the account itself looks healthy.
Work through your core tools in order of how much a lockout would hurt: email and identity, file storage, financial and billing systems, code repositories, customer-facing consoles, and domain registration. For each one, answer three questions. Who can reset access? Through what channel? And does that person or channel still exist today? The answers often reveal dead ends, such as a recovery phone number belonging to a device nobody has, or an administrator whose only contact is a mailbox that was deleted during offboarding.
Keep this inventory in a document your leadership can find, and update it whenever someone joins, leaves, or changes roles. An inventory that lives only in one person's head is itself a recovery risk.
Separate Everyday Admin Power From Emergency Access
A common pattern in small teams is that one or two people hold full administrative rights for everything, all day, every day. That convenience creates two problems. First, a compromised daily account becomes a compromised everything. Second, when that person is unavailable, nobody else can act. Good recovery design separates routine administration from exceptional access, so that the person who handles daily tasks does not automatically hold the keys to every system, and a deliberate, documented path exists for the rare moments when normal access fails.
The idea behind break-glass access is simple. An emergency credential or elevated account exists but is not used in normal operations. It is stored in a controlled location, its use is recorded, and using it triggers a review afterward. The exact mechanism depends on your tools and your risk tolerance, so the important step is deciding in advance who may invoke it, under what conditions, and who must be notified.
When you design this, avoid creating a shared generic admin login that everyone knows. Shared credentials make it impossible to tell who did what. Where the tool supports it, prefer named emergency accounts, each tied to a specific person or role, with documented custody.
Questions to Ask Every Vendor Before You Depend on Them
When evaluating a new tool or reviewing an existing one, the account recovery design deserves the same attention as its feature list. Ask how an administrator recovers access if they lose their credentials. Ask whether account ownership can be transferred to another person within your organization, and what verification the vendor requires before that happens. Ask whether the vendor can reset access on your behalf, and what proof of authority they demand. If the answer is that only one named individual can ever recover the account, treat that as a concentration risk.
Ask about session and device handling as well. If an administrator's device is replaced, what happens to trusted devices and recovery factors? Ask whether recovery codes can be generated, stored, and rotated by your team, and whether using one invalidates the others. Ask how the vendor authenticates support requests, because a support channel that accepts weak proof can become an attack path rather than a safety net.
Be cautious about assuming any specific capability. Confirm each control directly with the vendor's current documentation instead of relying on memory or on the assumption that a competitor offers the same thing.
A Practical Checklist for Your Next Review
Use the following steps to turn this into action. First, list your ten most important accounts and record the recovery channel for each. Second, mark any channel that depends on a departed employee, a retired device, or an inbox nobody monitors, and assign an owner to fix it. Third, identify which accounts have only one person capable of administering them, and add at least one additional trusted holder where the tool allows.
Fourth, decide what your break-glass process is. Write down who may use emergency access, the specific conditions that justify it, where the credential is stored, and who gets notified when it is used. Fifth, test the process. A recovery path that has never been exercised is a guess. Walk through one realistic scenario, such as an administrator being unavailable on a Friday evening, and note every point where someone would be stuck.
Finally, schedule a recurring review, perhaps quarterly, and tie it to your offboarding and onboarding checklists. Recovery paths decay quietly. The contact details change, the people move on, and the vendor updates its verification flow. A short, regular review catches those drifts before a real lockout does. The goal is not perfect security but a known, tested route back into every system your business depends on.