Unit 02 · Chapter 2 · 10 min read

Account takeover and account recovery

Protect high-impact actions across the entire account lifecycle.

The attacker does not break the front door. They persuade the help desk to reset the lock. Account security is only as strong as the recovery path, the active sessions, and the actions allowed after a reset.

Map the takeover chain

Account takeover is unauthorized control of an existing account. The chain can include stolen credentials, compromised recovery channels, active sessions, changed contact details, and a new payout destination. Detecting only login anomalies leaves the rest of the chain unobserved.

Create events for enrollment, credential changes, recovery, session creation, payee changes, and money movement. Link them by account and time. A new device followed by a password reset and immediate withdrawal is more informative than any single event alone. Avoid turning this into a universal ban on new devices; legitimate customers replace phones too.

Map the takeover chain Map the takeover chain — the flow Follow the sequence. A high-impact action follows. Access An actor gains a session Change Security or payout details change Extract A high-impact action follows — Follow the sequence. A high-impact action follows. Chapter sources · Open image

Map the takeover chain Map the takeover chain — the distinction These concepts answer different questions. Read each definition in the context of the section. New device A common legitimate event Risky sequence Several changes precede value extraction — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Map the takeover chain Takeover timeline Fictional teaching record. Exposure follows immediately. Takeover timeline Illustrative data; not a real customer record or a prescribed policy. 10:01 recovery completed Account access changes 10:04 payee replaced Value destination changes 10:05 withdrawal requested Exposure follows immediately Connected events give stronger context — Fictional teaching record. Exposure follows immediately. Chapter sources · Open image

Map the takeover chain Map the takeover chain — control and failure modes Connected events give stronger context. The branches show why alternative designs fail. Control design Assess the sequence before withdrawal. Connected events give stronger context. Failure mode 1 Score only the initial login. Later changes can alter the risk. avoid Failure mode 2 Ban all replacement phones. That harms ordinary account use. avoid Failure mode 3 Wait for a monthly login report. The intervention arrives too late. avoid — Connected events give stronger context. The branches show why alternative designs fail. Chapter sources · Open image

Use strong authentication with scope

Authenticators differ in resistance to phishing and replay. Select controls according to the action and the threat model. A stronger method for a payout change can be justified even when a lower-risk read action uses a normal session.

Bind confirmation to the actual action where possible. A generic approval prompt may not tell the customer which destination or amount is being approved. Store the action reference and authentication context together. Do not describe any single method as eliminating fraud: session theft, device compromise, and manipulation can remain relevant. Good security includes understandable prompts and a usable recovery path.

Authentication proves a particular relationship between a claimant and an authenticator under a defined protocol. It does not establish that every later instruction reflects the account owner’s informed intent. A person can authenticate successfully while being deceived into approving a payment. A stolen session can also let an attacker act after the original authentication ceremony has ended.

Bind additional controls to the sensitive action. Changing a payout destination, creating a new administrator, and viewing a receipt have different consequences. A useful design can require fresh evidence for the first two while allowing routine low-risk work to continue. The evidence should be tied to the operation and its relevant details, so an approval for one action cannot be casually reused for another.

Use strong authentication with scope Use strong authentication with scope — the flow Follow the sequence. Record proof against the action. Identify action Amount destination and authority Authenticate Use the required method Bind Record proof against the action — Follow the sequence. Record proof against the action. Chapter sources · Open image

Use strong authentication with scope Use strong authentication with scope — the distinction These concepts answer different questions. Read each definition in the context of the section. Generic approval Confirms an unclear prompt Action confirmation Shows the intended high-impact change — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Use strong authentication with scope Payout confirmation Fictional teaching record. Prevents unrelated reuse. Payout confirmation Illustrative data; not a real customer record or a prescribed policy. Action change bank destination Specific operation Destination ending 4217 Recognizable reference Proof bound to change-81 Prevents unrelated reuse The evidence should authorize this operation — Fictional teaching record. Prevents unrelated reuse. Chapter sources · Open image

Use strong authentication with scope Use strong authentication with scope — control and failure modes The evidence should authorize this operation. The branches show why alternative designs fail. Control design Bind confirmation to the sensitive action. The evidence should authorize this operation. Failure mode 1 Reuse any old authentication forever. Assurance and scope can expire. avoid Failure mode 2 Hide destination details. The customer cannot verify the intended change. avoid Failure mode 3 Assume strong login removes all scams. A real user can still be manipulated. avoid — The evidence should authorize this operation. The branches show why alternative designs fail. Chapter sources · Open image

Treat recovery as a privileged flow

Recovery can replace the credentials that protect every other action. It therefore deserves its own threat model, evidence requirements, and audit trail. A support agent should not improvise proofing questions from public information.

Define which changes invalidate sessions, which trigger notifications through established channels, and which require a temporary restriction on high-impact actions. Recovery restrictions need clear expiry and escalation routes. Otherwise, a customer who lost a phone can become trapped. Measure account restoration success and subsequent loss together so security and access are evaluated as one system.

Recovery deserves the same engineering attention as login. A support agent may see an urgent customer story, while an attacker sees a route around the strongest authenticator. Define which evidence can restore which privileges, when another person must approve a change, and how the genuine customer is informed through a reliable channel. Record the old and new authority, not merely that a ticket was closed. Recovery success means restoring appropriate access without transferring control to the wrong person.

Treat recovery as a privileged flow Treat recovery as a privileged flow — the flow Follow the sequence. Control sessions and sensitive actions. Request Identify the recovery claim Verify Apply approved recovery evidence Restore Control sessions and sensitive actions — Follow the sequence. Control sessions and sensitive actions. Chapter sources · Open image

Treat recovery as a privileged flow Treat recovery as a privileged flow — the distinction These concepts answer different questions. Read each definition in the context of the section. Public knowledge Often available to another person Approved recovery evidence Meets the defined assurance requirement — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Treat recovery as a privileged flow Recovery action record Fictional teaching record. Illustrative post-recovery control. Recovery action record Illustrative data; not a real customer record or a prescribed policy. Evidence approved assisted method Documented verification Sessions revoked per policy Limits old access Payout change additional review Illustrative post-recovery control Recovery must be secure and usable — Fictional teaching record. Illustrative post-recovery control. Chapter sources · Open image

Treat recovery as a privileged flow Treat recovery as a privileged flow — control and failure modes Recovery must be secure and usable. The branches show why alternative designs fail. Control design Apply a defined recovery policy with an exit path. Recovery must be secure and usable. Failure mode 1 Let agents invent personal questions. Public facts may be easy to obtain. avoid Failure mode 2 Restore every old session. An attacker session may survive. avoid Failure mode 3 Freeze the account without review. The customer needs a resolution route. avoid — Recovery must be secure and usable. The branches show why alternative designs fail. Chapter sources · Open image

Manage sessions and authority

A valid session can outlive a changed password or a changed role unless the system explicitly handles revocation. Maintain session identifiers, creation time, assurance context, and authority scope. Sensitive actions should re-evaluate relevant permissions rather than trust a stale role snapshot indefinitely.

For business accounts, separate viewer, preparer, approver, and administrator permissions. Test role changes during active sessions. A former employee should not retain payout authority because a browser tab stayed open. Use server-side enforcement; hiding a button is a user-interface change, not an authorization control.

Manage sessions and authority Manage sessions and authority — the flow Follow the sequence. End access when conditions change. Session Establish a bounded context Permission Check current action authority Revocation End access when conditions change — Follow the sequence. End access when conditions change. Chapter sources · Open image

Manage sessions and authority — the distinction

Hidden button: Changes the visible interface
Server authorization: Enforces whether the action is permitted

These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Manage sessions and authority Role-change specimen Fictional teaching record. Must not preserve old permission. Role-change specimen Illustrative data; not a real customer record or a prescribed policy. Old role payout approver Previous authority New role viewer Current authority Open session still present Must not preserve old permission An old session must not preserve removed rights — Fictional teaching record. Must not preserve old permission. Chapter sources · Open image

Manage sessions and authority — control and failure modes

Control design

Check current authority on sensitive requests. An old session must not preserve removed rights.

Failure mode 1avoid: Trust the hidden button. Requests can reach the server independently.
Failure mode 2avoid: Assume password changes revoke all sessions. That requires explicit implementation.
Failure mode 3avoid: Cache administrator rights indefinitely. Authority can change before cache expiry.

An old session must not preserve removed rights. The branches show why alternative designs fail. Chapter sources · Open image

Measure protection and customer cost

A takeover control can reduce loss while also locking out honest users. Measure both. Useful metrics include confirmed compromise rate, prevented high-impact actions, recovery time, false restrictions, and complaint patterns. Define how confirmation is obtained; a challenge failure alone is not proof of an attacker.

Review a sample of both allowed and restricted sessions. Otherwise, analysts see only the population the system already suspects. Separate friction caused by security policy from friction caused by broken integrations. A vendor outage that blocks every login should not appear as a successful fraud-prevention campaign.

Measure protection and customer cost Measure protection and customer cost — the flow Follow the sequence. Adjust the specific control. Observe Collect allowed and restricted outcomes Attribute Separate fraud from technical failure Improve Adjust the specific control — Follow the sequence. Adjust the specific control. Chapter sources · Open image

Measure protection and customer cost Measure protection and customer cost — the distinction These concepts answer different questions. Read each definition in the context of the section. Challenge failure Could reflect usability or outage Confirmed compromise Requires supporting evidence — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Measure protection and customer cost Control outcome report Fictional teaching record. Operational failures need separate tracking. Control outcome report Illustrative data; not a real customer record or a prescribed policy. Restricted sessions 200 Not all are attackers Confirmed compromise 18 Evidence-backed cases Vendor errors 70 Operational failures need separate tracking The system has more than one outcome — Fictional teaching record. Operational failures need separate tracking. Chapter sources · Open image

Measure protection and customer cost Measure protection and customer cost — control and failure modes The system has more than one outcome. The branches show why alternative designs fail. Control design Report false restrictions and compromise separately. The system has more than one outcome. Failure mode 1 Count every denial as stopped fraud. That inflates effectiveness. avoid Failure mode 2 Ignore allowed-session samples. Missed compromise remains invisible. avoid Failure mode 3 Treat an outage as a security win. Unavailability is not successful risk detection. avoid — The system has more than one outcome. The branches show why alternative designs fail. Chapter sources · Open image

Chapter connections

This chapter builds on Identity, credentials, and synthetic profiles. Continue with Transaction risk and decision economics to follow the next part of the system. Use the glossary for terminology and risk mathematics for formulas and worked calculations.

Sources

Reviewed 2026-09-17