Risk-Based and Adaptive Authentication Guide

Static authentication rules treat every sign-in the same, so they either annoy users with prompts that add nothing or wave through the one sign-in that matters. Risk-based, or adaptive, authentication evaluates signals about each attempt and session, such as network, device, behaviour and threat intelligence, and adjusts the response: allow, require a stronger method, limit the session or block. Done well, it reduces friction and catches compromised sessions; done badly, it becomes a substitute for strong authentication that attackers learn to stay under. This guide covers which signals are worth using, how scoring and thresholds work, how to design step-up and session responses, what NIST SP 800-63-4 allows, and how to test, tune and measure. It is written for identity engineers and architects designing policy for workforce or customer sign-in. For the policy engine itself, see the Conditional Access Guide.

Key takeaways

Risk signals adjust the response, they are not a factor: NIST SP 800-63B-4 says fraud indicators may lower the risk of misauthentication but do not change the assurance level or substitute for an authentication factor.
Start from a strong baseline: adaptive policy works on top of phishing-resistant MFA for high-value access, not instead of it; low risk should mean fewer prompts, never no authentication.
Separate sign-in risk from user risk: one describes a single attempt, the other the likelihood the account is already compromised, and they need different responses.
Evaluate continuously, not only at sign-in: session signals and shared signals such as OpenID CAEP events let applications revoke or step up a live session when risk changes.
Tune with report-only data: run every new rule in report-only or audit mode, measure what it would have done, and only then enforce.

What risk-based authentication is, and is not

Risk-based authentication computes a risk assessment for an authentication event or session and uses it to choose a response. It differs from simple conditional access rules ("block legacy protocols", "require MFA outside the office") in that the decision draws on many signals, often weighted by a model, and can change during the session. NIST SP 800-53 Rev. 5 control IA-10 Adaptive Authentication describes requiring additional authentication when defined circumstances arise, and IA-11 Re-authentication covers re-prompting in defined situations.

Three limits matter. First, risk signals are probabilistic and can be spoofed: an attacker with a stolen session cookie on a residential proxy in the victim's city looks low risk. Second, risk scoring is only as good as its baseline; a new user or a new device has no history. Third, risk engines are mostly vendor-proprietary, so the score's meaning differs between products. Design policy around signal categories and outcomes, not around a single number.

Risk signals: what to use and how reliable it is

Signal category	Examples	Reliability and caveats
Network	IP reputation, anonymiser or Tor exit, hosting provider ASN, new country, known-bad ranges	Useful for blocking obvious abuse; residential proxies defeat it; VPN use causes false positives
Geovelocity	Impossible or atypical travel between sign-ins	Noisy with mobile networks and cloud egress; better as a contributor than a trigger
Device	Managed or compliant device, device certificate, new device, browser fingerprint change	Device compliance from management tooling is a strong signal; fingerprints are weak and privacy-sensitive
Authentication behaviour	Repeated push prompts, rapid MFA approval after denials, failed attempts, password spray patterns	Strong indicator of MFA fatigue and spraying; requires telemetry from the identity provider
Credential intelligence	Credentials found in breach or infostealer data	High-value; drives user risk and forced reset
Session and token	Token replay from a new IP or device, anomalous token properties, session use from two locations	Key for detecting session theft after MFA; device-bound tokens make it stronger
Behaviour after sign-in	Inbox rule creation, mass file access, new credential added to an account	Detected after the fact; feeds user risk and response
Context of the request	Sensitivity of the application, action (payment, admin change), data classification	The most important input for choosing the required assurance, and fully under your control

Microsoft Entra ID Protection is a useful worked example of how a vendor classifies signals. It separates sign-in risk detections such as anonymous IP address, atypical travel, unfamiliar sign-in properties, password spray, malicious IP address, anomalous token and suspicious MFA authentication approval, from user risk detections such as leaked credentials, anomalous user activity, suspicious credential addition and attacker in the middle. Some are real-time and some are calculated offline after the sign-in, which matters for design: offline detections cannot block the sign-in that produced them, only the next one or the live session. Microsoft notes that the unfamiliar sign-in properties detection uses a learning period of at least five days for new users.

Scoring, thresholds and responses

Most engines produce a level (low, medium, high) rather than exposing the underlying score. Map each level, combined with the sensitivity of the resource, to a response.

Risk level	Standard application	Sensitive application or privileged action
None or low	Allow with existing session; normal reauthentication interval	Require phishing-resistant MFA at session start; short session
Medium	Step up to MFA, force fresh authentication (sign-in frequency every time)	Step up to phishing-resistant MFA; restrict session (no downloads, read-only)
High sign-in risk	Step up to phishing-resistant MFA or block	Block and alert
High user risk	Require remediation: strong authentication then secure password change, or session revocation for passwordless users	Block until investigated

Microsoft's recommended Conditional Access baseline illustrates this: a sign-in risk policy for medium and high risk that requires an MFA authentication strength with sign-in frequency set to every time, and a separate user risk policy for high risk that requires risk remediation. Microsoft advises not combining sign-in risk and user risk in one policy, and notes that its legacy ID Protection risk policies retire on 1 October 2026 in favour of Conditional Access. Whatever the product, the principles transfer: separate the two risk types, make remediation self-service only through strong authentication, and never let a risk response depend on a factor the attacker may already hold, such as SMS to a number they control.

Threshold trade-offs

High only: few prompts, but misses medium-risk compromises. Microsoft's guidance notes this may not stop an attacker using a compromised identity.
Medium and high: better coverage, more interruptions. The usual default for workforce.
Low and above: suits privileged roles and high-value customer actions, where friction is acceptable.

Step-up design

Step-up authentication raises the assurance of a session when risk or the requested action demands it. Design it at three layers.

Identity provider: conditional policies and authentication strengths that require a stronger method when risk rises. Use phishing-resistant methods (FIDO2 security keys, platform passkeys, certificate-based authentication) as the step-up target for sensitive actions. See the Phishing-Resistant MFA Guide.
Application and API: RFC 9470, the OAuth 2.0 Step Up Authentication Challenge Protocol (Proposed Standard, September 2023), lets a resource server reject a token with the error insufficient_user_authentication and state the required acr_values or max_age, so the client can obtain a token with stronger or fresher authentication. See the OAuth Step-Up Authentication Challenge Guide.
Transaction: for payments, admin changes and data exports, bind the step-up to the specific action (transaction signing or a fresh authentication within seconds), not just to the session.

Keep the step-up method stronger than the method already used. Stepping up from a password to SMS adds little against a phishing kit that relays both.

What NIST SP 800-63-4 allows

NIST SP 800-63-4 (the Digital Identity Guidelines, published August 2025, superseding 800-63-3) is the clearest standard on how risk signals fit with assurance levels.

Signals are supplementary: SP 800-63B-4 says indicators of potential fraud may be used at all authentication assurance levels to lower the risk of misauthentication, but do not change the AAL or substitute for an authentication factor. An unexpected geolocation or IP range is given as an example that might trigger additional risk-based controls.
Assess and disclose: verifiers must assess such indicators for efficacy and include them in their privacy risk assessment, which matters for device fingerprinting and behavioural data.
Reauthentication limits: at AAL2 the overall reauthentication timeout should be no more than 24 hours and the inactivity timeout no more than one hour; at AAL3 the overall timeout shall be no more than 12 hours and inactivity should be no more than 15 minutes. Adaptive policy can shorten these when risk rises; it should not stretch them.
Phishing resistance: at AAL2 verifiers shall offer at least one phishing-resistant option, and AAL3 requires it.
Rate limiting: consecutive failed attempts on an authenticator are limited to no more than 100, an upper bound that can be set lower.
Risk management process: SP 800-63-4 sets a digital identity risk management process (define the service, assess impact, select assurance levels, tailor and document in a Digital Identity Acceptance Statement, continuously evaluate). Adaptive controls are part of tailoring and should be documented there.

Continuous evaluation and shared signals

Risk changes after sign-in: a token is replayed from elsewhere, a device falls out of compliance, an administrator confirms a compromise. Long-lived sessions in SaaS applications ignore those changes unless something tells them. The OpenID Continuous Access Evaluation Profile (CAEP) 1.0, published 29 August 2025 by the OpenID Shared Signals working group, defines events that one provider can send another, including Session Revoked, Credential Change, Assurance Level Change, Device Compliance Change and Risk Level Change, on top of the Shared Signals Framework. Where your identity provider and key applications support it, use these events so that a high-risk change ends or downgrades sessions everywhere, not just at the identity provider. Session theft is the gap adaptive sign-in policy cannot close alone; see the Infostealer Logs and Session Token Abuse Guide and the Device-Bound Session Credentials (DBSC) Guide.

Where identity fits: non-human identities

Adaptive policies are usually written for people. Service accounts and workload identities sign in too, often from predictable locations, which makes them good candidates for strict network and behaviour baselines. Microsoft notes that user-scoped Conditional Access policies do not apply to service principals and points to separate Conditional Access for workload identities. Treat a service account sign-in from a new ASN, or a sudden change in API call pattern, as high risk, and replace interactive service accounts with managed or federated workload identities where possible. The Snowflake intrusions showed how password-only accounts with no network restrictions could be used from anywhere once credentials leaked. See the Snowflake breach analysis.

Implementation: a phased rollout

Baseline first: enforce MFA for all users, phishing-resistant MFA for administrators, and block legacy authentication. Adaptive policy cannot compensate for missing basics.
Classify resources: tag applications and actions by sensitivity so policy can combine risk with what is being accessed.
Enable detections and logging: turn on the identity provider's risk detections and stream sign-in, risk and audit logs to the SIEM.
Report-only (2 to 4 weeks): create sign-in risk and user risk policies in report-only mode. Measure how many sign-ins each would challenge or block, and review a sample of each risk level for true and false positives.
Prepare remediation paths: ensure users are registered for strong methods before enforcement; unregistered users hit by a user risk policy are blocked and need help desk support.
Pilot ring: enforce for IT and security staff, then one business unit, watching help desk volume.
Enforce broadly with documented exclusions: emergency access accounts excluded and monitored, and nothing else excluded without an owner and expiry.
Rollback: switch the policy back to report-only; keep the previous version exported so it can be restored exactly.
Tune monthly: adjust named locations, trusted device rules and thresholds from the data.

Decision guidance

Context	Recommended approach	Why
Small organisation on one identity provider	Use the provider's built-in risk policies with vendor defaults (medium and high sign-in risk, high user risk)	Little tuning capacity; defaults are reasonable
Large workforce with many applications	Provider risk engine plus SIEM or ITDR correlation, resource sensitivity tiers, CAEP where supported	Needs cross-signal correlation and session-level response
Privileged users	Phishing-resistant MFA always, low risk threshold, short sessions, managed devices only	Highest impact; friction acceptable
Customer identity	Risk-based step-up at registration, login and high-value actions; bot detection	Friction affects revenue; fraud signals matter most
Regulated payments	Follow the regulation's strong customer authentication rules and exemptions; use risk analysis only where it permits	Regulation sets the floor

Detection and measurement

Monitor risk detections and policy outcomes together. Useful detections, mapped to MITRE ATT&CK: repeated push prompts followed by approval (T1621 Multi-Factor Authentication Request Generation), successful sign-in after a spray pattern (T1110 Brute Force), token use from an unexpected device or network (T1550 Use Alternate Authentication Material), new authentication methods added after a risky sign-in (T1098 Account Manipulation) and sign-ins with valid but stolen credentials (T1078 Valid Accounts).

Challenge rate: share of sign-ins stepped up or blocked by risk policy, by risk level.
True positive rate: share of sampled high-risk events confirmed malicious or suspicious.
Self-remediation rate: share of risky users who remediate through strong authentication without the help desk.
Time to contain: from high user risk detection to session revocation.
Help desk impact: tickets caused by risk policies per 1,000 users.
Unremediated risky users: count and age of users left at medium or high risk.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	IA-10, IA-11, IA-2(1), AC-7, SI-4	Adaptive authentication, re-authentication, MFA for privileged accounts, unsuccessful logon attempts, monitoring
NIST SP 800-63B-4	Fraud indicators, reauthentication, rate limiting	Rules on how signals relate to assurance levels
NIST CSF 2.0	PR.AA-03, PR.AA-05, DE.CM-03	Authentication, access policy, monitoring personnel activity
CIS Controls v8.1	Control 6 (Access Control Management)	MFA for externally exposed applications, remote access and administrative access
ISO/IEC 27001:2022 Annex A	5.15, 8.5, 8.16	Access control, secure authentication, monitoring activities
MITRE ATT&CK	T1078, T1110, T1550, T1621, T1098	Techniques adaptive policy detects or blocks

Common failure patterns

Risk instead of MFA: letting low-risk sign-ins skip strong authentication entirely, so an attacker with a password and a nearby proxy gets in.
Push approval as the step-up: stepping up to a push notification that can be fatigued. The Uber breach began with repeated MFA prompts until a contractor accepted one.
Sign-in only: evaluating risk at sign-in but never revoking the session when user risk rises later.
Trusted location as a bypass: office IP ranges exempted from policy, so anything that reaches the network, including an attacker on a compromised VPN, inherits trust.
Exclusion creep: executives, service accounts and test users excluded over time until the policy covers a minority.
Unregistered users: enforcing user risk remediation before users have strong methods registered, producing lockouts and pressure to disable the policy.

Practitioner checklist

Enforce MFA for everyone and phishing-resistant MFA for privileged users before adding adaptive policy.
Classify applications and actions by sensitivity and use that in every risk rule.
Create separate sign-in risk and user risk policies.
Run each new rule in report-only mode and review a sample of outcomes before enforcing.
Make phishing-resistant MFA the step-up target for sensitive actions.
Revoke sessions on high user risk and use CAEP or equivalent where applications support it.
Apply strict network and behaviour baselines to service accounts and workload identities.
Document exclusions with owners and expiry, and monitor excluded accounts.
Record adaptive controls and their privacy assessment in the digital identity risk documentation.

Risk-Based and Adaptive Authentication Guide: Signals, Scoring and Step-Up Design