Friction Should Follow Risk, Not Routine

A returning customer opens your app on the same phone, in the same city, on a normal Tuesday evening. Your login asks for a code. Eight hours later, someone on a brand-new device, routed through a hosting provider in another country, types that customer's leaked password at 3 a.m. Your login asks for the same code.

That is uniform friction, and it is the root cause of most bad login. The loyal customer pays the full security tax every visit. The attacker faces the same single hurdle, and has often already planned for it.

Risk-based authentication, also called adaptive authentication, fixes that. You score every sign-in and every sensitive action, then add friction only when the score earns it.

What the research says

The best public evidence on challenges comes from Google, which protects one of the largest consumer account bases in the world.

Google studied more than 350,000 real hijacking attempts. Device-based challenges blocked 100% of automated attempts and over 94% of phishing-driven ones. But when challenges fired, 52% of legitimate users failed to sign in, though 97% got into their account within a short period. (Google Research)

In a separate experiment, 38% of users did not have their phone when challenged, and 34% could not recall their secondary email address. (Google Security Blog)

The same Google post shows that not all challenges are equal:

Challenge type	Automated bots blocked	Bulk phishing blocked	Targeted attacks blocked
SMS code to a recovery phone	100%	96%	76%
On-device prompt	100%	99%	90%
Knowledge-based question (for example, last sign-in location)	Effective	As low as 10%	Similarly weak

Source: Google Security Blog. Passkeys were not part of that 2019 study. They go further than an on-device prompt, because they are bound to your domain and cannot be phished at all.

The lesson is simple. Challenges work, and they are expensive. Spend them only where risk is real, and when you spend one, make it a strong one.

Signals worth scoring

A risk engine is only as good as the signals it reads. These six cover most consumer and SaaS use cases.

Signal	Low-risk example	High-risk example
Device	Known device bound to the account	First-time device, emulator, or tampered browser
Network and location	Home city, residential ISP	New country, hosting provider, anonymizer
Velocity	One login, normal hours	Impossible travel, many accounts from one IP
Credential health	Password not in any breach set	Password found in a known breach corpus
Behavior	Human typing and navigation	Scripted timing, copy-paste credential stuffing patterns
Action	Browsing, reading, saving	Changing email, adding a payee, moving money

A few practical notes on each:

• Device. A device is "known" once the user has completed a strong check on it. A passkey created on that device is the cleanest binding you can get. Cookies alone are weaker, because they get cleared and can be stolen.
• Network and location. Treat location as a nudge, not a verdict. Travelers, VPN users, and mobile carriers routing traffic through other cities are common. A hosting-provider IP is a stronger signal than a new city.
• Velocity. Look across accounts, not just within one. Credential stuffing shows up as one network trying many usernames, each only once or twice.
• Credential health. If the password just submitted appears in a breach corpus, the sign-in deserves more scrutiny even when it is correct. Chapter 3 covers screening at password creation too.
• Behavior. Timing and input patterns separate humans from scripts. This signal usually comes from a bot-detection or fraud vendor rather than in-house code.
• Action. What the user is trying to do matters as much as who they appear to be. Reading an order history is not the same as changing the email address on the account.

Turn the score into a decision

Keep the output simple. Three bands are enough for most brands.

1. Low risk: let them in silently.
2. Medium risk: one quick, phishing-resistant check, ideally a passkey or confirmation on a known device.
3. High risk: block, or require strong step-up and notify the account owner on every known channel.

Step-up means asking for fresh, stronger proof in the middle of a session, at the moment it is needed. It is the opposite of asking for everything up front.

A worked example: three sign-ins, one model

The weights below are an illustrative starting model, not a published standard. Use them to reason about the shape, then tune with your own fraud data.

Signal	Points
Known device (strong check completed before)	0
New device	+30
Usual city and ISP	0
New country	+15
Hosting provider or anonymizer network	+25
Submitted password found in a breach corpus	+30
Network seen trying many accounts in the last hour	+40
Scripted input timing	+30
Sensitive action requested (email change, payee, payout)	+40

Bands: 0 to 29 is low, 30 to 59 is medium, 60 and above is high.

Sign-in A: the Tuesday regular

A customer opens the app on their usual phone, from their home city, on a residential connection. Typing looks human. They browse and reorder a usual item.

• Known device: 0
• Usual city and ISP: 0
• No breach match, no velocity, human input: 0
• Action: reorder to a saved address, not sensitive: 0

Score: 0. Low. Let them in silently. No code, no prompt, nothing to approve. This is where most of your traffic should land.

Sign-in B: the new phone

The same customer just replaced their phone. They sign in from home, on the same ISP. Typing is normal. The password they enter is correct and not in any breach set.

• New device: +30
• Usual city and ISP: 0
• Everything else clean: 0

Score: 30. Medium. Ask for one quick check. If they have a synced passkey, it is already on the new phone, and a face scan settles it in seconds. If not, send a confirmation to a known device or email. Then remember this device, and offer a passkey before they leave.

Sign-in C: the 3 a.m. attempt

A browser with no history connects through a hosting provider abroad. The password is correct, but it appears in a breach corpus. The same network tried 400 other usernames in the past hour. Within a minute of signing in, the session tries to change the account email.

• New device: +30
• New country: +15
• Hosting provider: +25
• Breached password: +30
• Velocity across accounts: +40
• Sensitive action: +40

Score: 180. High. Block the sign-in, or at minimum require a phishing-resistant step-up the attacker cannot complete. Notify the real owner on every known channel. Force a password reset on next legitimate sign-in, because NIST requires a change when there is evidence of compromise (Chapter 3).

Score actions, not just sessions

Most risk engines score the sign-in and then trust the session until it expires. That leaves the most dangerous moments unguarded.

Attackers who get in rarely do anything dramatic at first. The damage comes from a short list of actions: changing the email or phone on the account, adding a payout destination, registering a new MFA method, or starting recovery. Each one should trigger its own risk check, regardless of how the session began.

This is the core idea behind the friction map. Chapter 8 turns it into a policy table that lists every common action, its risk, the default experience, and when to add friction.

Choosing what the medium-risk check should be

The medium band is where most of your design effort belongs. The check fires often enough that its friction matters, and on enough real attacks that its strength matters.

Decision criteria, in order:

1. Phishing resistance. A passkey or a confirmation on a device that already holds a strong credential. Avoid anything a fake page can relay in real time.
2. Availability. Google's data says 38% of users did not have their phone when challenged. Offer at least two ways to pass, and pick the default based on what that user has already enrolled.
3. Speed. A two-second biometric check beats a code the user has to wait for and type.
4. Clarity. Tell the user why you are asking: "We don't recognize this device." People cooperate with friction they understand.

Chapter 6 ranks every factor by phishing resistance and explains how to ask once, remember the device, and step up only at sensitive moments.

A benchmark for your risk engine

My working benchmark (opinion, not a published standard): if more than a small single-digit share of returning users see an MFA prompt on a typical day, your risk engine is not doing its job.

Track three numbers weekly:

• Challenge rate: share of sign-ins that get any extra check. This should be low and stable.
• Challenge pass rate: share of challenged legitimate users who complete it. If this drops, your challenge is too hard or the wrong type.
• Account takeover rate: confirmed takeovers per 10,000 active accounts. This tells you whether lowering the challenge rate cost you safety.

If the challenge rate falls and takeovers stay flat, you removed friction for free. That is the goal.

Common mistakes

• CAPTCHA on every sign-in. It punishes every human to slow down a few bots. Show it only when velocity or behavior signals justify it.
• Treating VPN use as guilt. Many privacy-minded customers use one. Weight hosting providers and known anonymizer exits, not every unfamiliar IP.
• Scoring once at sign-in. The session is not the risk. The action is.
• No feedback loop. Confirmed fraud cases and false positives must flow back into the weights. A model that never learns drifts out of date.
• Silent blocks with no recovery path. A legitimate user who is blocked with no explanation becomes a support ticket or a lost customer. Always offer a next step.
• Building everything in-house too early. Device intelligence and bot detection are specialized. Start with what your identity platform provides, then add a specialist if the data says you need one.

For a deeper technical treatment of behavioral signals, see Adaptive Authentication and Behavioral Biometrics in my enterprise passkeys ebook.

Key takeaways

• Uniform friction taxes loyal customers and barely slows attackers. Score each sign-in and each sensitive action instead.
• Google's data shows challenges block nearly all automated attacks, but 52% of challenged legitimate users failed to sign in. Spend challenges where risk is real.
• Knowledge-based questions can drop to 10% protection against phishing. Use phishing-resistant checks for the medium band.
• Three risk bands are enough: silent, one quick strong check, and block or step-up with notification.
• Measure challenge rate, challenge pass rate, and account takeover rate together, so you can prove friction came down without safety going with it.