Authentication receives the investment. Recovery inherits the power.
A critical account may require a hardware key every day and still be recoverable through a phone number established years ago. A bank may enforce careful login controls while a support process accepts contextual knowledge from an assistant. A principal may use a secure device while a family member’s tablet remains trusted for recovery. Recovery exists because authenticators are lost, people travel and devices fail. That necessity makes it powerful. It is the process by which a provider decides that the person who cannot prove control should be allowed to establish control again. The recovery path is therefore not an administrative convenience. It is an authority system.
The perimeter is larger than the account
For a family office, recovery often crosses several services.
- Email can reset a financial or communications account.
- Telecoms can reissue the number used to recover email.
- A device account can restore passwords, messages and trusted sessions.
- An assistant can persuade a provider that urgency is legitimate.
- A family member can act as a recovery contact.
- A vendor administrator can bypass the user journey entirely.
The services may be contractually separate. Operationally, they form one recovery graph. An attacker needs only a credible route through the graph, not simultaneous compromise of every node.
Map the recovery graph
Start with the accounts carrying the greatest authority: primary email, telecoms, password management, financial platforms, cloud identity, document systems and the devices able to approve or restore them. For each account, record:
- Every bound authenticator and trusted device.
- Recovery email addresses and phone numbers.
- Saved and issued recovery codes.
- Recovery contacts and provider support routes.
- Identity evidence a provider may request.
- People able to contact the provider or approve an exception.
- Notifications generated when recovery occurs.
- Services that can be reached after recovery succeeds.
Then draw the edges. If control of one node can reset, approve or suppress notice in another, connect them. Cycles deserve immediate attention: email recovers telecoms while telecoms recovers email; the password manager recovers email while email recovers the password manager.
Recovery should be deliberately inconvenient
NIST’s current digital identity guidance treats recovery as distinct from ordinary authentication and recognizes recovery codes, contacts, repeated identity proofing and provider-specific methods. The useful implication is not that every family office should copy a public standard mechanically. It is that exceptional recovery deserves a higher-friction design and explicit risk analysis. A high-authority account should not be recoverable through a channel selected for convenience alone.
- Require two independent forms of evidence where consequence is high.
- Do not let one compromised inbox receive both the recovery action and its only notification.
- Use recovery codes that are stored offline, controlled and periodically accounted for.
- Define which staff may assist without allowing them to impersonate the principal.
- Require delay or escalation for changes to recovery factors when the request is unusual.
- Notify more than one trusted party when high-authority recovery occurs.
Design the break-glass path
A break-glass route is not the secret password everybody knows. It is a controlled process for restoring minimum authority when normal mechanisms are unavailable.
- Activation condition — what must be true before the process begins.
- Decision owner — who may authorize it and who acts if that person is unreachable.
- Independent verification — which evidence does not depend on the failed environment.
- Minimum access — what can be restored first without granting full control.
- Observation — who is notified and what is logged.
- Expiry — when temporary access ends and credentials are re-bound.
- Review — who confirms that the original failure was understood and no residual route remains.
The process should be usable from outside the normal office, without access to the normal directory and while one trusted person is unavailable. Otherwise it is a diagram of ideal conditions, not a recovery capability.
Test without creating the incident
Recovery tests should not begin by locking a principal out of a live account. Start with provider walkthroughs, evidence review and controlled lower-consequence accounts. Confirm that the documented process matches what the provider will actually do. The most valuable finding is often a disagreement: the office believes two approvals are required; the provider’s support team believes one authorized caller is enough. Resolve the disagreement before an attacker or genuine emergency tests it.
The decision
Strong authentication protects the front door. Recovery determines who receives the keys when the door cannot be opened. For high-consequence accounts, that transfer of authority must be mapped, independent, observable and rehearsed. Anything less leaves the real perimeter in the hands of whoever can tell the most convincing story to the weakest provider.