Threat Modeling Account Recovery

The Instagram takeover story reads like a joke until you map it onto a threat model. The alleged attack path used an account recovery and support path, the part of the product built for legitimate users who lose access.

That detail should make identity teams uncomfortable. Most consumer products treat login as the security surface and recovery as the compassionate exception. Attackers do not respect that split. If a recovery flow can restore access, change contact methods, bypass MFA, or route a case to an internal operator, the flow is part of authentication. It may be the weakest authentication path in the system.

Recovery systems accumulate risk because they inherit the hardest product constraints. Real users forget passwords, lose phones, change emails, get locked out by travel, lose access to old corporate domains, and report account theft under stress. Support teams need to help them without turning every case into a week-long investigation. Product teams add shortcuts to reduce support load. Trust and safety teams add special paths for creators, advertisers, public figures, and hacked accounts. Over time, the recovery surface becomes a second login system with more branches, weaker observability, and more human discretion.

The Recovery Surface

An account recovery surface usually includes more than "forgot password." A mature consumer product may have:

Recovery Component	Security Question
Email or SMS reset	Can an attacker control or spoof the channel?
Device recognition	Can the attacker fake location, user agent, or device history?
Social proof	Can public profile details stand in for ownership evidence?
Photo or ID verification	Who reviews it, how long is it retained, and what can it unlock?
Support escalation	What authority does the human operator have?
VIP or creator support	Does a high-value account get stronger checks or faster unsafe exceptions?
Ad account linkage	Can business access become a path into personal identity?
Appeal forms	Can repeated submissions train the attacker against the review process?

Each row can bypass or mutate the primary login state. That means each row needs rate limits, evidence requirements, audit logs, and post-recovery containment.

Evidence Quality

The weak point in many recovery systems is evidence quality. Teams accept evidence that proves familiarity with the account rather than control of the account.

Public profile details prove familiarity. Old email addresses prove history. Screenshots prove access to screenshots. A phone number may prove control of a recycled identifier. Location similarity proves that the attacker can route traffic through a plausible place. None of those signals should restore sensitive capabilities on its own.

Better recovery systems separate evidence into tiers:

Evidence Tier	Example	Allowed Result
Weak familiarity	Public profile facts, screenshots, old handles	Case triage only
Channel control	Current email link, current phone OTP	Low-risk reset, still delayed
Device continuity	Previously trusted device with intact session	Limited recovery, notify other channels
Strong identity proof	Verified document, enterprise admin, hardware key	Broader recovery after review
Multi-signal proof	Trusted device plus current email plus delayed confirmation	Restore normal account state

The design choice sits in the jump between tiers. The system should refuse to move from weak evidence to full account control. If a user proves partial ownership, restore partial capability.

Recovery Should Be Progressive

Teams often make recovery binary: locked out or restored. That creates pressure to approve unsafe cases because the support outcome has only two states. Progressive recovery gives the product more room.

A recovered account can start in a limited mode. The user can read old messages, export data, or respond to support, but cannot change the primary email, disable MFA, modify payout settings, delete history, transfer ownership, or access ad spend. The system can hold sensitive operations for 24 to 72 hours and notify existing trusted channels. The user can cancel the recovery if the request is fraudulent.

Progressive recovery gives defenders time. Many account takeover attacks rely on speed: change email, disable recovery options, drain value, impersonate the owner, and disappear. A delay on high-impact actions turns recovery from a single decision into a monitored window.

Human Operators Need Guardrails

Human support often becomes the highest-risk tool in the system. Operators may see internal account details, override risk checks, change recovery channels, or mark a case as verified. Attackers know how to exploit urgency and ambiguity.

Support tooling should enforce several constraints:

• Operators should see only the fields needed for the case type.
• High-risk changes should require dual approval or policy-backed reason codes.
• The tool should display the account's risk profile before allowing recovery.
• Every override should log operator ID, evidence reviewed, policy reason, before/after account state, and user-visible notifications.
• The system should sample approved recoveries for review, with higher sampling for high-value accounts.

Good support tooling also protects operators. It gives them a policy-backed way to say no. A support agent under time pressure should not have to invent a security decision from scratch.

High-Value Accounts Need Different Paths

Products often discover too late that accounts carry different risk profiles. A teenager's personal account, a celebrity account, a government account, a developer account, and a business ad account need different recovery paths.

High-value accounts need stronger recovery defaults:

• Multiple recovery contacts or admin approvers.
• Mandatory hardware key or passkey registration.
• Delayed recovery for changes to identity, payout, or ownership.
• Alerts to out-of-band contacts.
• Separate support queues for public-figure and enterprise cases.
• Evidence packages reviewers can inspect after the fact.

The hard part is user experience. Stronger recovery creates friction for the people most likely to complain about friction. Product teams should present this as account insurance, not as punishment. The user gets faster legitimate recovery because the account already has a known escalation path.

The Telemetry Layer

Recovery attacks leave traces if the product records the right events. Useful signals include:

• Number of recovery attempts per account and per actor cluster.
• Form resubmissions with small changes in evidence.
• Support cases that mention urgency, legal threats, brand damage, or public status.
• Recovery attempts followed by email change, MFA removal, payout change, or mass messaging.
• Operators whose approval rates deviate from peers.
• Accounts with recent password reset plus new device plus region shift.

Teams should promote confirmed account takeover cases into regression tests for the recovery system. That sounds odd for a support workflow, but the pattern matches software testing: every serious incident becomes a scenario the system should catch next time.

A Practical Review Checklist

I would review an account recovery system with this checklist:

1. List every path that can restore access or change trusted channels.
2. Assign each path an evidence tier and maximum allowed account capability.
3. Mark high-impact actions that need delay or extra approval after recovery.
4. Inventory every internal tool that can override recovery state.
5. Confirm that each override logs actor, reason, evidence, and account diff.
6. Build special flows for high-value accounts before an incident forces them.
7. Create post-recovery monitoring for the first 72 hours.
8. Run abuse exercises where attackers have public profile data, old emails, screenshots, and partial device signals.

Design the Recovery State Machine

Recovery systems get dangerous when teams represent account state as a handful of booleans: email verified, phone verified, MFA enabled, locked, restored. Those flags do not capture the risk of a recent recovery. A better model treats recovery as a state machine.

The states can stay simple:

State	Meaning	Allowed Actions
Normal	User authenticated through expected path	Full account capability
Recovery requested	User submitted recovery evidence	No capability change yet
Evidence pending	System or reviewer needs stronger proof	Support messaging only
Limited restored	User regained partial access	Read, export, respond to support
Sensitive hold	Account waits before high-impact actions	No email change, MFA removal, payout change
Fully restored	Hold passed and no dispute arrived	Normal capability returns
Disputed	Existing trusted channel rejects recovery	Freeze sensitive changes and escalate

This model helps product and security teams discuss recovery without hand-waving. A support agent should not "restore the account." They should move the account into a specific state with a specific authority level. Engineering can then enforce that state in code.

The state machine also gives you better logs. Instead of one event that says account_recovered, you can inspect transitions: who requested recovery, which evidence tier moved the account forward, which operator approved the transition, which trusted channel received notice, and whether the user tried to perform a sensitive action during the hold.

Build a Recovery Evidence Package

High-risk recovery should produce a small evidence package. The package should be readable by a reviewer who was not involved in the first decision.

It should include:

• Account ID and risk tier.
• Recovery request time and source.
• Evidence submitted by the requester.
• Evidence tier assigned by the system.
• Existing trusted channels notified.
• Operator actions and reason codes.
• Capability state before and after recovery.
• Sensitive actions attempted after recovery.
• Signals that contradicted the request.

This package does not need to expose private user content to every reviewer. It should expose the facts used for the decision. Without that package, the team cannot learn from recovery incidents. A postmortem becomes a support anecdote instead of an engineering input.

The package also helps customer support. When a real user comes back angry after a denied recovery, the support team can explain the missing evidence and offer a safer path. When an attacker submits repeated cases with small variations, reviewers can see the pattern.

A Rollout Path

Teams with an existing recovery system do not need to rebuild everything at once.

Start with observability. Log every path that changes trusted channels or restores access. Add a recovery_source field to account events. Measure how often recovery is followed by email change, MFA removal, password reset, payout change, high-volume messaging, or support recontact.

Next, add sensitive-action holds. You can often implement holds with a small policy layer: if recent_recovery_at is within a configured window, block or delay high-impact actions. Notify the old trusted channels. Give the user a dispute link.

Then separate account tiers. High-value accounts should receive stronger default holds and stronger evidence requirements. You do not need a perfect account-value model to start. Public figures, verified business accounts, ad spenders, developer accounts, and enterprise admins make an obvious first group.

Finally, redesign support tools around state transitions instead of free-form overrides. This is the slowest step because it touches operations, training, and internal UX. It is also the step that turns recovery from institutional memory into enforceable product behavior.

Account recovery is where product empathy and adversarial thinking collide. A team can protect legitimate users while denying attackers a softer login page. Treat recovery as a security boundary during the first design review. Security audits should not meet it for the first time after launch.

Sources

• 0xsid: Meta account takeover fiasco