Adaptive Authentication: Risk-Based Access and Continuous Verification

Traditional authentication is a gate. You prove who you are once, receive a session, and that session is trusted until it expires — whatever happens in between. Adaptive authentication treats access as a continuing judgment rather than a single verdict, and it is the mechanism that makes zero trust operational rather than aspirational.

The Problem With One-Time Authentication

Consider what a valid session survives. The laptop is stolen ten minutes after login. The session cookie is exfiltrated by malware. The user's role changes and their entitlements do not. The account starts behaving nothing like the person who owns it.

In each case authentication worked correctly and the outcome is still bad, because the decision was made once against conditions that no longer hold. This is the same class of problem as a stale check in any other system — the fact was true when it was verified.

Risk Signals

Adaptive authentication scores each request against signals grouped roughly as follows:

• Identity — the account's normal hours, normal resources, normal access patterns.
• Device — is it enrolled and managed, is it patched, is endpoint protection running and healthy, has this device been seen with this account before.
• Network and location — corporate network, known home address, unfamiliar country, anonymizing proxy or hosting-provider address range.
• Behavior — volume and sequence of actions compared to the account's own baseline and its peer group.
• Resource sensitivity — reading a shared calendar is not exporting a customer database.

Geographic impossibility is the cleanest single signal and the easiest to explain: two authentications too far apart to be the same traveller. The detection logic is covered in impossible travel.

Note that no individual signal is decisive. An unfamiliar country is a holiday as often as an attack. The value is in combination — unfamiliar country and unmanaged device and an immediate bulk export is a different proposition entirely.

What Happens With the Score

Four outcomes, and exams expect you to match the outcome to the scenario:

1. Allow silently. Low risk, familiar everything. The user notices nothing, which is the point — friction spent here is friction unavailable later.
2. Step up. Elevated risk triggers an additional factor before proceeding. This is the characteristic behavior of adaptive authentication and the answer to most questions about it.
3. Restrict. Grant partial access — read-only, no download, no administrative function — rather than all or nothing.
4. Block and alert. High risk, with the event raised to the SIEM for investigation.

Step-up should use a phishing-resistant factor where available. Stepping up to a one-time code against an adversary already proxying the session accomplishes little, whereas the origin binding described in FIDO2 and passkeys holds.

Continuous Evaluation

The stronger form re-evaluates during the session rather than only at its start. Posture changes — endpoint protection disabled, device falls out of compliance, network moves — trigger re-assessment, and a session can be terminated mid-flight.

This requires the identity provider and the resource to keep talking, which older applications cannot do. It also requires short-lived tokens with frequent refresh, since a long-lived token cannot be revoked in any meaningful sense. That constraint is why session hijacking remains viable against systems that issue eight-hour tokens and never look again.

Architecturally this is the trust algorithm doing its job. The component model behind it — which part decides, which part enforces — is covered in zero trust components.

Getting It Wrong

Adaptive authentication fails in two directions and both are avoidable.

Too sensitive, and users face constant challenges. They habituate, approve prompts without reading them, and the control becomes a liability — prompt-bombing works precisely because approval has become reflexive. Too permissive, and it is theatre.

Two practical requirements: run it in monitoring mode first and look at what would have been challenged before enforcing anything, and have a documented, tested path for a legitimate user who is genuinely locked out. The second one determines whether the help desk becomes a social engineering target.

Exam Focus

Recognize step-up authentication as the answer when a scenario describes risk detected mid-flow. Know that adaptive decisions combine identity, device, location and behavior, and that resource sensitivity weights the threshold. Know that continuous evaluation requires short-lived tokens. And know that factor type still matters at step-up — adding a weak second factor does not make a high-risk request safe.