The Friction Map

Most account takeovers do not cost anything at the moment of sign-in. The loss happens a few minutes later, when the attacker changes the email, adds a payee, or redeems the stored balance. Sign-in is where most teams put their friction. The sensitive action is where it belongs.

The friction map is the one policy table that ties the previous chapters together. It lists what users do, how risky each action is, what the default experience should be, and when to add friction. Use it as a starting point and tune it to your own fraud data. The shape holds across retail, media, SaaS, and fintech.

The map

User action	Risk	Default experience	Add friction when
Browse, read, search	Low	No login needed	Never
Add to cart, save, like	Low	Guest or silent session	Never
Return visit, same device	Low	Stay signed in	Session expired or device signals changed
Sign in on a new device	Medium	Passkey, or fallback plus one factor	Always on first use; then remember the device
Checkout with saved payment	Medium	Passkey or device biometric	New shipping address plus new device
View sensitive data (health, statements, tax)	Medium to high	Fresh passkey check if the session is old	Session older than your set window
Change email, phone, or password	High	Step-up with a phishing-resistant factor	Always, plus notify the old contact point
Add a payout account or move money	High	Step-up with a phishing-resistant factor	Always; hold first-time payees
Add a new passkey or MFA method	High	Step-up with an existing factor	Always, plus notify all devices
Account recovery	Highest	Verified recovery factor and cool-down	Always; never bypassable by support alone

Read it top to bottom. The first half is where users spend most of their time, and it should feel like no security exists at all. The second half is where account takeovers turn into losses. Every bit of friction you remove from the top should be reinvested at the bottom.

The rows map directly onto the earlier chapters. The top rows depend on risk scoring (Chapter 2). The middle rows depend on passkeys being the default factor (Chapters 4 and 5). The bottom rows are the step-up policy from Chapter 6 and the recovery design from Chapter 7.

Adapting the map to your industry

The structure of the map does not change by industry. What changes is which rows carry the money. The table below is my working guidance, drawn from the patterns I saw repeatedly across consumer and B2B login. It is opinion, not a published standard.

Industry	Where takeovers turn into losses	Rows to tighten	Rows to loosen
Retail and e-commerce	Stored balances, gift cards, loyalty points, saved cards shipped to new addresses	Treat "redeem points or gift card" and "change shipping address" as high risk	Guest checkout, browsing, wishlists, order tracking by link
Media and subscriptions	Resold or shared accounts, plan upgrades on stored cards, profile takeovers	New-device sign-in from a new country; payment method changes	Long sessions on TVs and home devices; reading and watching need no prompts
B2B SaaS	Admin role changes, SSO and SCIM settings, API key creation, bulk data export	Treat every admin and integration change as high risk; require a passkey for admins	Day-to-day work inside a trusted session; routing business domains to SSO
Fintech and banking	New payees, transfers, limit changes, contact detail changes before a transfer	Hold first-time payees; pair any contact change with a cool-down before money can move	Viewing balances on a trusted device; repeat payments to known payees

Two notes on the table. First, a regulated business has a floor set by its regulator, and the map can only add friction above that floor. Check your obligations before you loosen any row. Second, B2B SaaS has two maps. One covers end users. The other covers administrators, and for them the "high" rows start much earlier.

Tuning the thresholds with your own fraud data

The map has deliberate blanks: "your set window", "hold first-time payees", "device signals changed". Your fraud data fills them in. Here is the process I recommend.

1. Collect 90 days of confirmed takeovers. Use chargebacks, support escalations, and user reports. For each one, record which row the attacker reached first and which row caused the loss.
2. Find the gap between sign-in and loss. Measure the time from the attacker's first sign-in to the first high-risk action. That gap sets your cool-down and hold periods. If most losses happen within an hour of a contact change, a 24-hour cool-down on that row removes most of them.
3. Measure the friction you already impose. For each row, record the challenge rate and the first-try pass rate. A row with a high challenge rate and almost no confirmed takeovers is friction you can remove.
4. Price both sides. Estimate the cost of a takeover on each row against the cost of friction: abandoned checkouts, support tickets, and lost sessions. Chapter 1 covers how to put numbers on the friction side.
5. Move one row at a time. Change one threshold, hold it for two to four weeks, then compare takeovers and abandonment against the baseline. Changing several at once makes the result impossible to read.
6. Review quarterly. Attackers move to whatever row you leave soft. A new pattern in the takeover log is a signal to revisit the map.

Track these four numbers on one dashboard: prompt rate for returning users, step-up first-try pass rate, confirmed takeovers per 10,000 active accounts, and passkey share of sign-ins. If the first falls while the third holds steady, your map is working. Chapter 12 turns these into a monthly scorecard.

One user's week on the map

Here is how the map feels from the user's side. The scenario is illustrative: a returning customer of an online retailer with a synced passkey on their phone.

Day	What happened	Map row	What the user saw
Monday	Browsed new arrivals on the phone during a commute	Browse, read, search	Nothing
Tuesday	Added two items to the cart on the home laptop	Add to cart, save, like; return visit, same device	Nothing; the session was still valid
Wednesday	Signed in on a new work laptop	Sign in on a new device	One passkey check through a cross-device QR code, then an offer to save a passkey on that laptop
Thursday	Checked out with the saved card to the usual address	Checkout with saved payment	One face unlock
Friday	Changed the account email to a new address	Change email, phone, or password	A passkey step-up, plus a notice to the old email with a "This wasn't me" link
Saturday	An attacker tried a password from an old breach, from another country	Sign in on a new device (high risk)	A new-device notification; the attacker met a passkey requirement and stopped
Sunday	Added a passkey on a new tablet	Add a new passkey or MFA method	A passkey check on the phone, plus a notice to all devices

Count the friction. Across seven days the user saw four short biometric checks and three notifications. They never typed a code. The one hostile attempt failed at the row where it should, and the real owner heard about it the same day.

That is the goal of the whole map. The same week under a uniform policy would have meant a code at every sign-in and a second code at checkout. The attacker's attempt would have met the same code prompt the real user had learned to clear without thinking.

Key takeaways

• Takeovers turn into losses at sensitive actions, not at sign-in. Put friction where the money moves.
• The top of the map should feel like no security exists. The bottom should never be bypassable, even by support.
• The map's structure is universal, but each industry tightens the rows where its losses happen.
• Fill in windows, holds, and cool-downs from your own takeover data, and change one row at a time.