Who can keep things running if you cannot access your accounts?

A person's digital responsibilities rarely fit inside one account. Email, domains, billing, cloud files and device access can depend on one another. If the only administrator becomes unavailable, a simple renewal or customer handover may become difficult even when nobody is trying to break in.

Plan for three different situations: you lose access temporarily; someone needs authorised access to continue work; or selected information must be handled after your death. These situations require different permissions and platform features.

Recovery does not equal delegation

An account-recovery contact helps the account holder regain access under a provider's process. It is not automatically permission for that contact to read the account or run the business. Apple, for example, states that a recovery contact can supply a recovery code without receiving access to the account. Apple: recovery contacts.

Business delegation should use supported roles, a second authorised administrator or another documented organisational mechanism. Give people the access needed for the responsibility, with their own identities and an audit trail. Sharing the owner's everyday login weakens accountability and may still leave recovery dependent on the owner's phone.

Legacy and inactivity tools have specific limits

Apple's Legacy Contact feature concerns access to certain account data after death and requires an access key and the required death documentation. It excludes items such as iCloud Keychain passwords and passkeys and some purchased content. It is not a general emergency business-access feature. Apple: Legacy Contact.

Google's Inactive Account Manager can notify selected people and share selected data after the configured inactivity conditions. That is different from immediately transferring account ownership or granting unrestricted access. Review the chosen data and contact details in the account's current settings. Google: Inactive Account Manager.

Platform features do not, by themselves, determine inheritance rights, company authority or every applicable legal obligation. Where those rights need to be established, align the technical plan with the appropriate legal and organisational arrangements.

A worked example: the domain-renewal trap

A fictional consultant controls a business domain, email and project storage. The domain renews on the 25th. Its recovery messages go only to an email address on that same domain. The payment card is personal and the only administrator's second factor is on their phone.

If renewal fails while the consultant is unavailable, email may also become unavailable, disrupting the recovery route. The problem is a circular dependency, not simply a missing password.

A better plan identifies an authorised backup administrator, verifies the registrar's supported recovery arrangements, keeps billing responsibility current and records the next renewal date. Where permitted, the recovery route should not depend entirely on the service being recovered. Test the arrangement before an outage, without deliberately disabling the live domain.

Build an inventory without collecting a pile of secrets

Record service name, account purpose, legal or organisational owner, primary and backup responsible people, renewal dates, recovery method, data-export route and location of protected recovery material. The inventory should explain how to act; it need not contain the actual password or recovery codes.

Separate personal photographs from company customer records and shared project documents. A family member who should receive personal memories may have no authority to access confidential business files. A colleague responsible for operations does not need unrestricted access to private messages.

Classify the urgency: what must be handled within a day, a week or a month? Domain renewals, payroll administration and customer obligations can have different response needs. This helps a trusted person start with the right task under the authority they actually hold.

Keep passwords, recovery codes and identity documents out of a general inventory.

Store instructions and recovery material appropriately

Use a suitable protected location for secrets and tell the authorised person how to find the instructions. Avoid an unencrypted shared spreadsheet containing every login. Keep any physical recovery material secure and separate from the device whose loss it is meant to address.

Write clear triggers and boundaries: who may act, for which purpose, how their authority is checked and who else must be informed. A person named in a private note may still need the provider's formal process; do not assume the note overrides platform rules.

Test the plan while changes are easy

Ask the backup person to locate the service inventory and explain the first steps for a sample scenario. Verify their own authorised access where it is already meant to exist. Test export and recovery with a safe sample where possible, without exposing private content unnecessarily or activating a death-related process.

Review after a phone replacement, staff departure, family change, new service or ownership change. Remove obsolete contacts and permissions. Keep a dated record of what was checked and what remains dependent on the provider.

A workable plan gives the right person a legitimate route to the right task. For device-loss preparation, see Passkeys and recovery.