The recovery process is itself an attack surface
Aliases: lost-device recovery · device takeover · device migration attack
What it is
The device-loss recovery attack surface combines number replacement, cloud-account recovery, backup restoration, new-device binding, and old-device revocation triggered by loss. An attacker holding the old device or controlling a communication channel can reverse a process intended to restore the owner into account and data takeover.
Why it happens
A device often stores authenticators, email, messages, a password vault, and recovery evidence, so loss removes several supposedly independent proofs together. Under urgency, carriers, support, and cloud platforms each relax rules without sharing risk state. An attacker can transfer a number, reset email, restore a cloud backup, and bind a new device in a cross-provider cascade while the old device retains sessions.
Studying it
With synthetic identities and test devices, run legitimate-owner and old-device-attacker recovery in parallel across number change, old email, cloud backup, support, migration, and payment wallet. Build a timeline of evidence, notification destination, delay, privilege gain, and revocation propagation. A compliant flow on one platform does not prove the cross-platform composition secure.
Where it stops holding
This concept is narrower than general account recovery: it centers on the device as a common failure of several authentication and data channels and on migration cascades. Not every loss is theft, and fraud controls must not permanently deny legitimate communication or emergency service. Carriers and cloud providers are not fully controlled, but products can document dependencies, detect changes, and reduce one-channel authority.
Applying it
- Make loss reporting discoverable, but authorize any account-level high-risk state and restriction from proportionate identity or device evidence. An unverified report may trigger low-impact review, not direct power to lock, erase, or alter the account, and a falsely reported owner needs a recovery route.
- Use independent evidence and delay for number changes, cloud restore, and new-device binding; do not make a code visible on the old device the sole proof.
- Send alerts to existing channels still assessed as safe, not only the newly replaced or potentially attacker-controlled number.
- After recovery, have the user inspect devices, sessions, recovery contacts, and wallets; revoke old state and retain an appealable audit trail.