Category: Multi-Factor Methods

Adaptive Authentication

Also known as: Risk-Based Authentication, Contextual Authentication

Simply put

Adaptive authentication is an approach to verifying a user's identity that adjusts the strength of the checks based on the risk of a given sign-in attempt. Instead of applying the same login requirements to everyone, it looks at signals such as location, device, and behavior to decide whether to allow access, require an additional factor, or block the attempt. This lets low-risk logins proceed smoothly while higher-risk ones face stronger verification.

Formal definition

Adaptive authentication is an authentication method that evaluates contextual and risk signals, such as location, device status, and end-user behavior, to determine the authentication requirements applied to a given access attempt. Depending on the assessed risk, a policy framework may permit the session, invoke step-up authentication (for example requiring a second factor), or block the attempt outright; in some vendor implementations these responses are configurable per user or condition. It is primarily concerned with verifying identity (authentication) rather than determining what a principal may do (authorization), though some vendor descriptions frame it as informing authorization levels as well. Note that specific signals, risk-scoring logic, and enforcement responses vary by vendor and deployment configuration; the underlying risk-scoring algorithms and thresholds are typically implementation-specific and out of scope for a general definition.

Why it matters

Static authentication applies the same requirements to every sign-in regardless of context, which forces a trade-off between security and usability: strict controls frustrate legitimate users on low-risk logins, while relaxed controls leave higher-risk attempts under-verified. Adaptive authentication addresses this by scaling verification strength to the assessed risk of each attempt, allowing routine access to proceed with minimal friction while reserving stronger checks for sign-ins that appear anomalous based on signals such as location, device status, and end-user behavior.

Because it can invoke step-up authentication or block an attempt outright in response to elevated risk, adaptive authentication is a common control for mitigating credential-based attacks such as those relying on stolen or replayed credentials. In many deployments, for example, an otherwise valid login from an unfamiliar location or device can be challenged with an additional factor or denied, rather than being accepted solely on a correct password.

It is important to keep the scope of adaptive authentication precise. It is primarily concerned with verifying identity (authentication), not with determining what an authenticated principal is permitted to do (authorization), even though some vendor descriptions frame it as informing authorization levels as well. The specific signals collected, the risk-scoring logic, and the enforcement responses all vary by vendor and configuration, so the security value in any given environment depends heavily on how policies and thresholds are set.

Who it's relevant to

Security Architects

Architects designing authentication flows use adaptive authentication to balance security and usability, defining which risk signals feed the policy framework and how the system responds, permit, step-up, or block, across different user populations and conditions. They must account for the fact that scoring logic and enforcement responses are implementation-specific and vary by vendor.

IAM Engineers

Engineers configure and operate the adaptive authentication policies within a given platform, mapping contextual signals such as location and device status to enforcement responses. Because some implementations allow responses to be configured per user or condition, engineers are responsible for tuning these settings and validating that step-up and block behaviors work as intended.

Compliance Officers

Compliance leads care that authentication strength can be scaled to risk and evidenced per access attempt. Adaptive authentication supports demonstrating that higher-risk sign-ins face stronger verification, though officers should note that this control addresses identity verification (authentication) rather than authorization decisions.

System Administrators

Administrators handle the day-to-day operation of adaptive authentication, including reviewing challenged or blocked sign-ins and managing configuration for suspicious-login handling and second-factor prompts. They need to understand that specific signals and thresholds are set by configuration and may differ across the products in their environment.

Inside Adaptive Authentication

Risk Signals

Contextual inputs evaluated during an authentication attempt, such as device posture, IP reputation, geolocation, time of access, and behavioral patterns. These signals are typically aggregated into a risk score that drives the authentication decision.

Risk Engine / Policy Evaluation

The component that evaluates collected signals against configured policies to determine the required assurance level. Depending on the deployment, this may function similarly to a policy decision point (PDP) that returns an allow, deny, or challenge outcome.

Step-Up Authentication

A mechanism to require additional or stronger factors when risk is elevated, rather than always enforcing the highest assurance. It applies to authentication specifically and should not be confused with authorization decisions about what a principal may do once authenticated.

Authentication Factors

The knowledge, possession, and inherence factors that adaptive flows may selectively require. Adaptive authentication typically orchestrates which factors (and how many) are demanded based on assessed risk, drawing on MFA, 2FA, or passwordless methods depending on configuration.

Continuous / Session-Based Evaluation

In some deployments, risk is reassessed during an active session and not only at initial sign-in, allowing re-challenge if context changes. The extent of continuous evaluation varies by vendor and profile.

Common questions

Answers to the questions practitioners most commonly ask about Adaptive Authentication.

Is adaptive authentication the same as multi-factor authentication (MFA)?

No. MFA refers to requiring authentication factors from two or more distinct categories (knowledge, possession, inherence), while adaptive authentication is a decisioning approach that adjusts authentication requirements based on contextual risk signals. Adaptive authentication may invoke MFA as one possible response, typically via step-up authentication when risk is elevated, but it can also allow a low-friction or passwordless flow when signals indicate low risk. In short, MFA is a control; adaptive authentication is the risk-based logic that decides when and how strongly to apply such controls.

Does adaptive authentication determine what resources a user is allowed to access?

No. Adaptive authentication operates at the authentication stage, verifying the principal's identity with a level of assurance proportional to assessed risk. Deciding what an authenticated principal may do is authorization, which is handled by separate mechanisms (for example RBAC, ABAC, or PBAC policies evaluated at a PDP/PEP). Some architectures feed the risk signals or authentication assurance level produced during adaptive authentication into subsequent authorization decisions, but the two steps remain distinct and should not be conflated.

What signals are typically used to assess risk during adaptive authentication?

Signals vary by vendor and deployment, but commonly include contextual attributes such as source IP or geolocation, device posture and recognition, network reputation, time of access, impossible-travel indicators, and behavioral patterns. Some implementations incorporate threat intelligence feeds or session anomaly detection. The specific signals available, how they are weighted, and whether scoring is rule-based or model-driven depend heavily on the product and configuration, so the available signal set should be validated against your provider's documentation rather than assumed.

How does step-up authentication fit into an adaptive authentication deployment?

Step-up authentication is a common response action within an adaptive flow: when the risk evaluation exceeds a configured threshold, the system prompts the principal for an additional or stronger factor before granting or continuing access. In most deployments you configure which risk levels trigger step-up and which factors are acceptable (for example a FIDO2/WebAuthn authenticator, an OTP, or a push approval). Step-up is one of several possible outcomes, others may include allowing access outright, denying it, or requiring re-authentication, depending on your policy configuration.

How do adaptive authentication decisions relate to federation protocols like SAML 2.0 and OpenID Connect?

Adaptive authentication is typically performed by the identity provider during the authentication event that precedes issuing a federation assertion or token. In OpenID Connect, the resulting assurance can often be conveyed through claims such as the authentication context or authentication methods, and relying parties may request a particular context. SAML 2.0 similarly supports authentication context classes in its assertions. The precise claims, context values, and whether a relying party can request or verify them depend on the protocol profile and how both the IdP and relying party are configured.

What should be considered when tuning risk thresholds and handling false positives?

Threshold tuning is a balance between security and user friction: overly aggressive thresholds increase step-up challenges and legitimate-user lockouts, while lax thresholds weaken the control's value. In most deployments you should establish fallback and recovery paths for cases where a legitimate user cannot satisfy a step-up challenge, log decision rationale for auditability, and monitor false-positive and false-negative rates over time. Because signal quality and scoring logic differ across products, thresholds generally require iterative tuning against real traffic rather than a one-time static configuration.

Common misconceptions

Adaptive authentication is a form of authorization that decides what resources a user can access.

Adaptive authentication governs how confidently a principal is verified (an authentication concern). Deciding what an authenticated principal may do is authorization, handled by access control models such as RBAC, ABAC, or PBAC. The two steps remain distinct even when risk signals inform both.

Adaptive authentication always adds friction by requiring more factors.

In most deployments it is bidirectional: low-risk contexts may reduce prompts while high-risk contexts trigger step-up challenges. The goal is to match assurance to assessed risk, not to universally increase the number of factors.

Adaptive authentication and MFA are the same thing.

MFA refers to combining factors from different categories. Adaptive authentication is a policy-driven approach that decides when and which factors (including MFA, passwordless, or step-up) are required based on risk. MFA can be a component invoked by an adaptive flow, but they are not interchangeable.

Best practices

Define explicit risk policies that map assessed risk levels to required assurance, and document what each level triggers rather than relying on opaque default behavior.

Keep authentication decisions separate from authorization decisions, ensuring that risk-based step-up governs identity verification while access to resources is enforced through your chosen access control model.

Select and weight risk signals appropriate to your environment, and validate that signals such as device posture and geolocation are reliable before making them decisive.

Test both the low-friction and high-friction paths so legitimate users are not blocked while elevated-risk attempts are appropriately challenged with step-up authentication.

Where supported, enable session-level or continuous re-evaluation so that context changes during a session can trigger re-authentication, and confirm the extent of this capability with your vendor or profile.

Log risk scores, signals, and resulting authentication outcomes to support auditing, tuning, and incident investigation, noting that behavior may vary across vendors and configurations.