Draw a recovery dependency map before a failure

01 · decision point

Begin with accounts that can reset other accounts

List primary email, password manager, mobile carrier, Apple or Google platform account, workplace identity provider, domain registrar, financial administrator, and any service that receives recovery notices. These are control-plane accounts: losing one can block many others, while compromising one can enable multiple resets. Add ordinary accounts later. The first map should remain small enough to review after a phone loss or suspected takeover.

For each account, write the provider, account owner, and business or household purpose. Do not write the username when that would create unnecessary exposure, and never include a secret. Use neutral identifiers such as ‘primary family email’ or ‘company identity owner.’ The map is an operational diagram, not a credential inventory. Store it where the authorized recovery operators can reach it without opening the same password manager the diagram is meant to recover.

02 · decision point

Draw authenticators and recovery channels as separate edges

An authenticator proves access during normal sign-in; a recovery channel helps replace lost authenticators. NIST SP 800-63B-4 treats account recovery as a distinct event and recognizes saved codes, issued codes, recovery contacts, and repeated identity proofing. Draw a solid edge for normal authentication and a dashed edge for recovery. That simple difference exposes plans that count the same mailbox as both the second factor and the only recovery route.

Add trusted sessions, enrolled devices, hardware keys, passkey providers, phone numbers, recovery addresses, offline codes, and authorized administrators as nodes. Mark whether each is independently recoverable. A synced passkey on three devices may still have one provider-account dependency. Two email addresses may both forward to the same compromised mailbox. Redundancy is real only when the failure that removes one route does not remove the other.

03 · decision point

Find circles, orphan nodes, and sole operators

A circle appears when account A recovers account B and account B recovers account A with no external route. A sole operator appears when only one family organizer or identity owner can recover everyone else. An orphan has no tested recovery edge. Highlight these patterns, then decide which one has the highest consequence. Fix email and password-manager cycles before low-impact entertainment accounts.

NIST recommends binding multiple authenticators to reduce recovery need and requires notification around important binding and recovery events in covered systems. Apply the principle broadly: register two independent strong authenticators where the provider allows it, keep one away from the daily device, and route alerts to a channel that an attacker cannot silently suppress through the same compromised account.

04 · decision point

Convert the diagram into a no-secrets rehearsal

Choose one scenario, such as ‘phone unavailable,’ ‘primary organizer locked out,’ or ‘employee identity disabled.’ Ask the backup operator to follow the map to the provider's official recovery screen without completing a destructive reset. Verify they can locate the hardware key, identify the recovery-code container, contact the correct administrator, and distinguish the real service domain. Record the date and every edge that proved inaccurate.

Update the map after new devices, changed phone numbers, email migrations, administrator turnover, password-manager switches, family membership changes, or revised provider recovery features. Destroy superseded printed copies or mark them clearly. A stale dependency map can direct a responder to a former employee, expired phone, or removed feature at the worst time. The map's value comes from dated verification, not visual completeness.

Practical sequence

Create the map without creating a secret leak

1. 01

   List only high-impact control-plane accounts, owners, and purposes.

2. 02

   Add authenticators, recovery channels, devices, artifacts, and administrators as separate nodes.

3. 03

   Use different edge styles for normal sign-in and recovery.

4. 04

   Mark circles, single operators, shared-device dependencies, and nodes with no tested recovery.

5. 05

   Rehearse one failure scenario without entering or rotating any real secret.

6. 06

   Date the map and revise it after every device, role, provider, or membership change.

Original research element

Score each dependency by failure concentration

This original worksheet turns a diagram into a prioritized remediation queue.

Continue on login.com

Related independent guidance

• Assign household recovery roles and rehearse them
• Map business ownership before revoking an employee
• Separate mobile backup from service-side re-enrollment
• Use the map during an unexpected-prompt incident