Recover an Account After Phone Compromise
Design an account recovery journey for someone whose phone, number, and active session may all be controlled by another person.
The brief
Understand the problem
Background
Standard recovery sends codes to the phone being reported as stolen or compromised. A safer flow must find trustworthy alternatives, limit information revealed to an attacker, and secure the account after identity is re-established.
User context
Aya's unlocked phone was stolen on a train. Her email and authenticator were signed in on it, but she still has a previously trusted laptop and a printed recovery code at home.
Product problem
A legitimate account owner needs a route around the compromised factor while the service must resist an attacker who can receive messages and approve prompts on the missing phone.
Objective
Create recovery-method selection, identity confirmation, account containment, and post-recovery review for a compromised phone scenario.
What to design
Define the experience
Required experience
- Declare that the usual phone and session are not trusted
- Choose a recovery route based on available independent factors
- Complete a risk-appropriate verification without exposing account data
- Revoke compromised access and establish new recovery methods
Screens and states
- Compromise declaration
- Recovery route chooser
- Verification state
- Secure-account review
Core user flow
Follow the critical path
- 01
Aya begins recovery from her trusted laptop and marks the stolen phone as compromised
- 02
The service suppresses approval prompts and text codes to that device
- 03
She uses a recovery code plus the trusted laptop to confirm access
- 04
She revokes the stolen session and removes its passkey and authenticator
- 05
She adds a new recovery method and reviews recent sensitive actions
Product rules
Requirements and constraints
Requirements
- Let people exclude compromised devices, numbers, and sessions before verification begins
- Rank recovery routes by independence from the reported compromise
- Reveal only minimal account hints until identity is confirmed
- Provide one coordinated containment step for sessions, credentials, passkeys, and recovery factors
- Record delayed security changes and notify previously trusted channels where safe
Constraints
- A carrier-issued replacement SIM is not automatically proof of account ownership
- High-risk recovery may require a cooling-off period
- Support agents must not see secret recovery codes or full identity documents
Reality check
States worth considering
Finish line
What to deliver
- Five responsive screens showing safe factor exclusion, recovery, containment, and one delayed-review state
If you want more
Optional extensions
Optional direction
Visual resources
Use these as a starting constraint if you want one. They are not part of the required solution.
Roboto Condensed & Cabin
Clear interface writing gives people the confidence to understand what changed and decide what to do next.
Roboto Condensed & Cabin
Clear interface writing gives people the confidence to understand what changed and decide what to do next.