A phone can be purchased in an hour. The device it replaces may take weeks to reconstruct. The lost object contained passkeys, authenticator seeds, private messages, trusted banking relationships, encrypted notes, travel applications, digital wallets, personal photographs and the recovery paths for other accounts. It was also recognised by providers, assistants and family members as evidence that the principal was speaking. When that combination cannot be reproduced without the original hardware, the institution does not have a device problem. It has concentrated identity and authority.
Replacement and recovery are different
Replacement restores hardware. Recovery restores the ability to act with legitimate continuity. A new phone may receive calls while critical services remain locked. The principal may remember passwords but lack the trusted factor. A cloud restore may recover application data while silently excluding credentials or encryption keys. A provider may require the old device to approve the new one. The recovery design must therefore be tested at the level of outcomes, not inventory.
Map what the device proves
- Possession: services treat the device or number as an authentication factor.
- Identity: contacts assume messages and calls from it represent the principal.
- Recovery: codes, reset links and support calls terminate there.
- Authority: banking, signing, approval and administration applications are installed and trusted.
- Memory: information exists locally or inside applications with no institutional record.
- Coordination: the device connects people who may not share any other secure channel.
A single phone can hold all six. Losing it—or having it controlled by someone else—affects far more than communications.
Value object — The Device Recovery Dossier
For every high-consequence device, maintain a dossier outside that device:
- Owner, device class and business or personal roles it supports.
- Critical applications and the outcome each enables.
- Recovery factor and provider procedure for each critical service.
- Required identity documents, trusted contacts and independent contact routes.
- Data that is local-only, encrypted, backed up or deliberately excluded from backup.
- Revocation sequence if loss or compromise is suspected.
- Replacement test date, result and unresolved exceptions.
The dossier should not contain the secrets themselves in an exposed list. It should contain the map needed to use the protected recovery material.
Test the hostile replacement
A friendly migration proves little. Test a scenario in which the old device is unavailable and possibly compromised. Can the team suspend the number, revoke sessions and prevent the old device from approving a new one? Can the principal authenticate without relying on the lost channel? Can providers recognise the legitimate replacement while refusing an attacker using accurate personal information? Recovery that works only when the old device cooperates is migration, not resilience.
Separate recovery channels
Do not let the same phone receive the alert, approve the reset and act as the trusted contact. Use independent factors and institutional contact records for the most consequential services. Where a provider offers only weak recovery, add compensating process: restricted transaction limits, independent call-back, a pre-registered adviser or a documented freeze instruction.
Plan for the human event
Loss is not the only scenario. The principal may be ill, travelling, under coercion or unable to navigate a complex recovery. The plan should identify who may assist, what they may see and what authority they hold. Do not solve accessibility by sharing the principal’s credentials. Create delegated, revocable roles wherever possible.
The standard
A critical device is recoverable when the institution can remove its authority, restore the legitimate user and preserve necessary evidence without depending on the missing object or the memory of one technician. Until then, the device is not personal hardware. It is an undocumented control plane.