What Is Risk-Based Authentication?

Risk-based authentication adjusts what is required based on how unusual an attempt appears. A familiar user on a known device from a normal location proceeds; the same account from an unfamiliar country on an unrecognised device is challenged or blocked.

It differs from conditional access in that the decision comes from a computed risk score rather than from explicit rules — though in practice the two are combined, with risk feeding a rule.

The signals that drive scoring

Device familiarity, location and travel plausibility, network reputation, behavioural patterns such as typical hours and access sequences, and threat intelligence including whether the credential has appeared in a known breach.

Impossible travel is the most cited signal and among the least reliable, because virtual private networks and corporate proxies produce it constantly for legitimate users. Signals are individually weak and useful in combination.

The trade-off is friction against detection

Set sensitivity high and legitimate users are challenged repeatedly, which trains them to approve prompts reflexively — defeating the purpose and enabling fatigue attacks. Set it low and genuine anomalies pass.

The resolution is to make the response proportionate rather than binary. Low risk proceeds, medium risk prompts for an additional factor, high risk restricts the session or blocks. That way most users rarely see friction while unusual attempts meet resistance.

Risk during the session, not only at sign-in

The more valuable capability is continuous evaluation. Risk assessed only at authentication says nothing about a session hijacked afterwards, which is now the more common attack.

Re-evaluating during the session — and ending it when risk rises, the device falls out of compliance or the account is disabled — addresses session theft in a way that sign-in-time checks cannot.

Prompt design is part of the control

Push notification approval is convenient and vulnerable to fatigue attacks: an attacker holding a valid password sends repeated requests until the user approves one simply to stop the interruption. The defence is in the design of the prompt itself.

Number matching, where the user must enter a code displayed by the application rather than merely tapping approve, defeats this because approval requires sight of the legitimate sign-in screen. Showing context — the application, the location, the device — helps the user recognise a request they did not initiate. And repeated denied or ignored prompts are a strong signal that a password is already compromised.

Telling users what to expect is a cheap and frequently skipped control. Someone who understands that an unexpected prompt means somebody has their password will report it; someone who assumes prompts are random will approve it. A short explanation of what the additional challenges mean, and an obvious way to report one that was not theirs, converts the user population into a detection source.

Where to start

Review what your identity provider currently flags as risky and whether anyone acts on it. Most platforms generate these signals by default and most organisations never look at them.

See conditional access. GuardsArm delivers managed security.