Map the accounts and recovery methods your team depends on, find circular dependencies, protect recovery credentials and rehearse access without a lockout.
Direct answer: List the accounts that keep the business operating, identify what each recovery route depends on, and remove circular dependencies using supported, protected alternatives. Keep recovery credentials accessible only to authorised people but not dependent on the account they are meant to recover. Rehearse the plan without deliberately locking anyone out. If recovery requires changing organisation-wide identity controls or you cannot verify a supported route, involve your administrator or provider before making changes.
An account list is not a recovery plan. It may tell you the supplier and owner while leaving unanswered how you would regain access if the owner's phone, email or usual device were unavailable.
The fragile part is often the connection between services. The password manager might require a work-email confirmation, while the work-email recovery information is stored only inside the password manager. Use a small-team technology retrospective to identify the important accounts, then investigate those dependencies specifically.
Applies to: authorised planning for your team's business accounts. Product-specific examples are documentation-based; no account recovery or emergency-access configuration was tested for this article.
Draw the account recovery dependency map
The account recovery dependency map is an editorial method for showing what must remain available before another account can be recovered. Each account points to its required email, device, credential, authorised person or supplier process.
Start with the services whose loss would interrupt essential work: identity and email, domain registration, financial operations, shared files and the systems that serve customers. Include a service because of the work it supports, not because its subscription is expensive.
For each account, record the official sign-in address, business owner, account type, supported recovery method and where the recovery instructions are kept. Do not put passwords, backup codes or complete security answers in the planning document. Use a reference to their approved protected location instead.
Add the conditions that can make the method unavailable. A recovery email is not independent if it is an alias of the same failed mailbox. A second person's access may still depend on the same missing phone or identity provider.
My recommendation is to fix a circular recovery dependency before buying another general security tool. The dependency is a specific operational weakness. A managed identity or security service may still be justified where the team needs expertise or controls it cannot maintain, but the purchase should solve a defined problem.
Separate ordinary access from emergency recovery
Several mechanisms can help with access, but they are not interchangeable:
| Mechanism | What it may help with | Limitation to verify |
|---|---|---|
| Another authorised user | Continuing the work through their own account | They may not have recovery or ownership authority |
| Backup verification method | A missing normal sign-in factor | It may not replace the password or every account check |
| Provider recovery process | Establishing control after normal routes fail | Evidence, eligibility and delays vary by provider |
| Organisation emergency access | An administrator lockout scenario | Requires specialist configuration, monitoring and controlled use |
Google's account documentation, for example, describes backup codes as a way to complete the second verification step, with each code usable once. Generating a new set invalidates the old set, and availability has account-specific limitations. Google says not to share these codes: an individual's backup codes must not become shared team credentials. Use provider-supported separate administrator or delegated-access arrangements where available. Check the exact arrangement rather than treating a printed code as a universal recovery key. Google's backup-code documentation.
For Microsoft Entra organisations, Microsoft's emergency-access guidance addresses independent authentication dependencies, secure storage and regular validation. These are highly privileged accounts, not a suggestion to share an everyday administrator login. Follow the complete current guidance with a qualified administrator. Do not weaken security controls as an improvised recovery shortcut. Microsoft Entra emergency-access guidance.
Record which mechanism applies to each of your services. If the only entry is “contact support”, find the official process and required evidence while you still have access. Mark anything the provider does not guarantee as uncertain.
Protect the route without making it unreachable
Decide who is authorised to initiate recovery and who should know it has happened. Use named responsibilities and appropriate access controls, not a password copied into a group chat.
Keep the instructions available during the failure you are planning for. An offline or independently accessible copy of non-secret instructions may be useful. Recovery secrets need a protected arrangement appropriate to their power, with access restricted to authorised people and a way to keep them current.
Check physical dependencies too. A backup security key locked in the same bag as the only laptop is not independent of losing the bag. A secure office location may be unavailable during a building-access problem. Do not solve this by scattering unprotected duplicates; choose a deliberate storage and access arrangement.
Where a provider permits multiple authorised administrators, use supported separate identities and roles. Confirm licensing and role capabilities rather than assuming an ordinary paid seat can perform recovery. Avoid making changes to ownership or authentication until you know how to preserve current access and reverse a mistake.
Rehearse without manufacturing an outage
Start with a tabletop exercise: assume the usual phone is unavailable and walk through the written route. Can the authorised person find the instructions and protected recovery material? Does the route depend on a message arriving in the locked account?
Next, perform only supported, low-risk checks while retaining a working session and an authorised fallback. For example, verify the recorded recovery destination and confirm another authorised person can sign in to their own account. Do not intentionally reset the only administrator or remove the only verification method to prove the plan works.
If you use a one-time code during a permitted rehearsal, update the protected record so nobody relies on a consumed code later. If you regenerate a set, replace obsolete copies securely according to your organisation's process. Record the check date and outcome, not the secret itself.
A successful ordinary sign-in is not proof that a provider's lost-account recovery procedure will succeed. Keep that distinction in the record. A plan can contain verified components and unresolved dependencies at the same time.
Calculate the sequence, not just the number of accounts
Consider an illustrative seven-account business: two email identities plus domain registration, payroll, shared files, invoicing and website management. Five operational services depend on one of the two email identities. Email A also needs Email B for recovery, and Email B needs Email A.
The circular pair is the first problem. Suppose a supported independent verification route for Email A is established and protected, allowing a planned sequence from Email A to Email B and then the dependent services. This is a fictional arrangement, not a claim that every provider supports it.
Assume a rehearsal budget of 21 minutes to establish access through Email A's supported route, nine minutes to verify Email B, and six minutes for each of five downstream checks:
21 + 9 + (5 × 6) = 60 minutes.
If the business's illustrative tolerance is 90 minutes, the plan leaves 30 minutes of margin. But a provider-imposed waiting period or unavailable support could exceed it completely. Do not present the arithmetic as a promised recovery time.
Add 20 minutes to prepare the exercise and 15 minutes to update the records: total planned person-time is 95 minutes. That effort buys information about the recovery arrangement, not an automatic cash saving. If the remaining uncertainty is unacceptable, change the operating fallback, seek a supported stronger recovery arrangement or reconsider dependence on that service.
Complete the first plan in two sessions
- In a 45-minute session, identify the essential accounts and map their recovery dependencies. Keep secrets out of the shared document and mark unknowns clearly.
- Before changing anything, ask the account owners or administrator to verify supported methods and permissions. Stop where the proposed change could remove your only working access.
- Schedule a separate rehearsal with an authorised fallback available. Record what was actually checked and which provider processes remain untested.
- Fix the most consequential dependency and set a review trigger for device replacement, account-owner changes or supplier changes. Keep a manual operating fallback for any recovery time you cannot control.
The useful result is a route someone can follow under pressure, plus an honest account of where that route still depends on outside help.
Related guides
Frequently asked questions
Should everyone on the team have the recovery codes?
No. Recovery credentials can provide significant account access and should be limited to people authorised to use them. The team may need to know who can initiate recovery and where non-secret instructions live without seeing the credentials themselves. Choose a protected storage arrangement and a notification process proportionate to the account's importance. Do not create uncontrolled copies in email or shared chat for convenience. If only one person can reach the protected material, address that dependency through an approved alternative rather than giving every colleague the same powerful secret.
Is a recovery email enough if I lose my phone?
Not necessarily. The available route depends on the service, account configuration and checks the provider requires. A recovery email might help establish ownership but not replace every sign-in factor. Check the official documentation and the methods already configured on your account while access is working. Also verify that the recovery mailbox does not depend on the lost phone itself. Do not assume a successful password-reset message proves the whole recovery journey. Record the remaining uncertainty and consider supported alternative verification methods appropriate to the service and your organisation's rules.
Can we keep using a personal account for a critical business service?
Assess ownership, permitted use and recovery before deciding. A personal account may tie essential business access to one person's private email, phone and provider relationship, making continuity difficult. An organisation-supported arrangement with separate authorised users may be more suitable, but migration capabilities and costs vary. Do not rename or transfer a personal account without understanding the provider's rules and the individual's rights. Preserve business records and agree an authorised migration where needed. The recovery plan should expose the dependency so you can make that decision, not silently treat private access as company property.
How often should we rehearse the plan?
Use the relevant provider guidance and your operational risk to set the interval, then add reviews after material changes. A new phone, changed recovery address, departed owner or altered identity configuration can invalidate a plan before the next calendar review. Keep the rehearsal proportionate: verifying protected materials and dependencies does not always require a live reset. Record the date and result so another person can distinguish a current check from an old assumption. For specialist emergency-access accounts, follow their specific validation requirements rather than borrowing a generic schedule from an unrelated service.
What if recovery requires documents we do not have?
Identify the missing evidence now and ask the provider what supported alternatives exist. Do not fabricate ownership documents, bypass verification or rely on an unofficial recovery service promising guaranteed access. Business registration, billing history or domain-control evidence may be relevant in some processes, but requirements differ, so collect only what the official procedure actually needs. Protect any sensitive evidence and record its authorised location. If no dependable recovery route exists, plan how the business would operate without the service and consider an authorised migration while normal access is still available.
Does a successful rehearsal mean we can promise a recovery time?
No. A rehearsal shows what happened under its specific conditions, not every future failure. A provider outage, additional verification, unavailable staff or a lost storage location can change the sequence. Separate your measured internal steps from waiting times controlled by suppliers. Use the result to compare against the business's tolerance and identify a fallback, rather than turning one exercise into a guarantee. If a customer contract requires a particular recovery commitment, ensure the service arrangement and operational evidence support it and obtain appropriate professional advice before making the promise.
Sources and verification
- Google Account Help: sign in with backup codes, checked 11 September 2026 for second-step use, single-use behaviour and replacement-set implications.
- Microsoft: emergency access in Entra ID, checked 11 September 2026 for independent dependencies, protected credentials and validation. No administrator configuration is prescribed without its full context.
- The parent was read in the supplied website source; its public route could not be retrieved. The seven-account example and timings are illustrative, not an observed recovery test.
This article is practical guidance. Apply it in proportion to your tools, evidence, risks, and responsibilities.
