Account takeover and account recovery

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.

Inside the mechanism. The takeover chain can include credential compromise, session capture, recovery abuse, a contact change, a new destination, and value extraction. Record the sequence with event times and authority changes. A successful login is only one point in that chain. Detection can act before the payment if the system can connect earlier account changes to the intended operation. Preserve the distinction between suspicious access and a confirmed unauthorized financial effect.

A concrete example. An attacker’s useful path may include login, session creation, privilege change, payee addition, and payment. Each event alone can appear ordinary. The rule flags 513 of 26,000 sensitive account sessions. Of those flags, 125 meet the synthetic target, giving 24.37% precision. It misses 31 target events. Under the stated cost assumptions, residual loss and operating friction total $32,918. The important result is the connection between the population, action, capacity, and outcome—not one isolated score.

When the assumption fails. The rule ignores the sequence and scores every action independently. Connect related events within an explicit observation window and action scope. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

An attacker’s useful path may include login, session creation, privilege change, payee addition, and payment. Each event alone can appear ordinary.

Takeover sequence detection: reference condition figure preview

01Reference conditionTakeover sequence detection

Takeover sequence detection: failure and stress figure preview

02Failure and stressTakeover sequence detection

Takeover sequence detection: controlled response figure preview

03Controlled responseTakeover sequence detection

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.

Inside the mechanism. Authentication strength depends on method, transaction binding, session context, and recovery design. A strong sign-in method does not protect an operation that can be approved through a weaker alternate path. Record what was authenticated and how recently, then require appropriate authority for high-consequence changes. A generic step-up flag is insufficient if the system cannot tell whether the customer approved this payee, this amount, or only access to the account.

A concrete example. A valid authentication ceremony supports a particular session and assurance claim. It does not automatically authorize every later action or establish informed customer intent. The case identifies 2,832 eligible records from a source population of 5,900. The required workflow completes for 2,747, but 41 completed records miss the illustrative internal target. Another 85 remain incomplete. Communication evidence covers 2,720 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. An old session is reused to change the payout destination without fresh evidence. Bind any required step-up evidence to the sensitive action and retain the scope of approval. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A valid authentication ceremony supports a particular session and assurance claim. It does not automatically authorize every later action or establish informed customer intent.

Authentication scope: reference condition figure preview

01Reference conditionAuthentication scope

Authentication scope: failure and stress figure preview

02Failure and stressAuthentication scope

Authentication scope: controlled response figure preview

03Controlled responseAuthentication scope

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.

Inside the mechanism. Recovery changes who can exercise authority over the account. Treat it as a privileged transition with evidence, independent notifications where appropriate, and protection against immediate extraction. Customer support needs a bounded override process and an audit trail. If recovery resets all prior controls and immediately permits a new payout destination, the recovery path becomes the effective security boundary regardless of how strong the ordinary login appears.

A concrete example. Recovery can restore an account without the original authenticator, which makes it a privileged control path. The customer story alone is not the authorization record. The case identifies 718 eligible records from a source population of 780. The required workflow completes for 696, but 10 completed records miss the illustrative internal target. Another 22 remain incomplete. Communication evidence covers 689 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. An urgent support request changes both contact details and recovery authority. Separate evidence collection, approval, customer notice, and restoration of specific privileges. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

Recovery can restore an account without the original authenticator, which makes it a privileged control path. The customer story alone is not the authorization record.

Support-led account recovery: reference condition figure preview

01Reference conditionSupport-led account recovery

Support-led account recovery: failure and stress figure preview

02Failure and stressSupport-led account recovery

Support-led account recovery: controlled response figure preview

03Controlled responseSupport-led account recovery

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.

Inside the mechanism. A session needs an identifier, creation context, authority scope, expiry, and revocation state. Changes to credentials or account ownership may require revoking existing authority rather than merely updating the next login. Propagate revocation to the services that execute financial actions. A cached authorization that outlives a revoked session can preserve an attacker’s capability. Record the authority checked at the final action boundary, not only at page load.

A concrete example. A risk decision revokes authority, but several services cache sessions or tokens. A revocation event is useful only if the affected enforcement points receive it in time. 330 intended requests generate 346 processing attempts under this retry assumption. Capacity is 390 attempts per interval, and the critical path consumes 150 ms of a 160 ms budget. The request-based SLO view observes 100 bad requests against an illustrative allowance of 100. These measurements must be connected to the financial effect and control evidence before declaring recovery.

When the assumption fails. A delayed consumer continues to accept a session that another service has revoked. Define token lifetimes, revocation propagation, and failure behavior for sensitive actions. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A risk decision revokes authority, but several services cache sessions or tokens. A revocation event is useful only if the affected enforcement points receive it in time.

Session revocation propagation: reference condition figure preview

01Reference conditionSession revocation propagation

Session revocation propagation: failure and stress figure preview

02Failure and stressSession revocation propagation

Session revocation propagation: controlled response figure preview

03Controlled responseSession revocation propagation

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.

Inside the mechanism. Measure both harm reduction and the cost imposed on legitimate customers. Useful outcomes include confirmed unauthorized loss, recovery completion, challenge abandonment, support demand, and time to regain access. Compare equally mature cohorts and record changes in attack mix. A lower loss rate achieved by locking out a large legitimate population is a different product result from a targeted improvement. The confusion matrix is a starting point, not the whole customer experience.

A concrete example. A takeover control can reduce harmful activity while making legitimate recovery difficult. The operating point needs both loss and customer-impact evidence. The rule flags 761 of 42,000 account access attempts. Of those flags, 134 meet the synthetic target, giving 17.61% precision. It misses 34 target events. Under the stated cost assumptions, residual loss and operating friction total $67,120. The important result is the connection between the population, action, capacity, and outcome—not one isolated score.

When the assumption fails. Aggressive flags are reported as prevented loss without checking legitimate customer outcomes. Measure mature labels, false alarms, recovery delay, and the effect of the actual intervention. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A takeover control can reduce harmful activity while making legitimate recovery difficult. The operating point needs both loss and customer-impact evidence.