What is Risk-Based Authentication?

Risk-Based Authentication (RBA) is an authentication approach that uses contextual, behavioral, device, transaction, and other risk signals to determine how an authentication attempt should be handled. Instead of applying the same authentication requirements to every interaction, RBA evaluates the context of the event and can allow the existing authentication flow to continue, request additional verification, or take another action when risk is elevated.

Risk-Based Authentication is also commonly referred to as adaptive authentication. Current NIST guidance describes risk-based or adaptive authentication techniques as controls that can identify behavior that falls within or outside expected patterns using signals such as IP address, geolocation, request timing, and browser metadata. NIST also allows indicators of potential fraud to trigger additional risk-based controls during authentication. [1]

Importantly, RBA is not an authentication factor or authenticator by itself. It is the decisioning layer that helps determine what level or method of authentication should be applied in a particular context.

For organizations designing authentication journeys, that distinction matters. The aim is not simply to add more authentication when something looks unusual. It is to make a better decision about when additional assurance is required and which authentication method is appropriate for that moment.

Risk-Based Authentication at a glance

How does Risk-Based Authentication work?

A typical Risk-Based Authentication flow has four stages:

1. Collect relevant signals. The authentication system receives information about the interaction, such as the device, network, location, timing, account activity, transaction context, or previous behavior.
2. Evaluate the context. Rules, risk models, or other decisioning logic assess whether the interaction is consistent with expected behavior or contains indicators of increased risk.
3. Make an authentication decision. The assessed risk is mapped to an appropriate response.
4. Apply the authentication policy. The user may continue with the existing authentication flow, be asked for additional verification, use a stronger authenticator, or have the interaction blocked or escalated.

NIST SP 800-63B-4 gives examples of risk-based and adaptive techniques that examine IP address, geolocation, timing of request patterns, browser metadata, and other indicators of potential fraud. It also notes that an unexpected geolocation or IP address block may prompt additional risk-based controls. [1]

The output does not always need to be a numerical "risk score." Some implementations use explicit rules, others combine multiple signals into a score or category, and others use a combination of techniques. In EU payments, for example, the regulatory framework for transaction risk analysis explicitly requires certain risk factors to be combined into a risk score when determining whether qualifying remote payments can use the transaction-risk exemption from strong customer authentication. [3]

The useful architectural principle is to keep the risk decision separate from the authentication method. A signal such as a new device does not authenticate the customer. It helps determine whether the customer should be asked for additional authentication.

What signals can Risk-Based Authentication use?

Risk-Based Authentication can evaluate a wide range of signals, depending on the interaction, available data, and privacy requirements.

Common categories include:

Device signals

Information about the device or endpoint can help determine whether an interaction differs from previous activity.

Examples may include:

• whether the device has been seen before;
• browser or device metadata;
• device integrity or attestation information; and
• changes in the device associated with the account.

NIST SP 800-63B-4 specifically identifies browser metadata as an input that can support risk-based or adaptive authentication and notes that authenticator and endpoint attestation information may be used in risk-based authentication decisions. [1]

Network and location signals

Network context can help identify access that differs from established patterns.

Relevant signals can include:

• IP address;
• geolocation;
• unexpected IP address ranges;
• network reputation; and
• unusual or high-risk locations.

NIST identifies IP address and geolocation as potential inputs into risk-based authentication. [1] In European payment regulation, location is also one of the factors considered in real-time transaction risk analysis. [3]

Behavioral and historical signals

Previous activity can provide context for determining whether a new interaction is unusual.

This can include:

• typical login times;
• normal usage patterns;
• transaction history;
• changes in account behavior; and
• unusual sequences of activity.

NIST's current guidance allows risk-based or adaptive controls to identify behavior that falls inside or outside typical norms. [1] EU transaction risk analysis similarly considers previous spending patterns, payment history, and abnormal payment behavior. [3]

Transaction and journey context

Risk does not only come from the login itself. The action a customer is attempting can change the level of assurance required.

Changing contact information, recovering an account, registering a new device, or completing a high-value transaction can justify different authentication requirements from routine account access.

The European Commission's strong customer authentication framework provides a clear example of this approach in payments: qualifying low-risk remote transactions may be treated differently based on real-time transaction risk analysis, while transactions that do not meet the conditions must revert to strong customer authentication. [3]

Not every available signal should automatically be collected. Signal selection should be proportionate to the authentication decision being made and the privacy requirements that apply.

Is Risk-Based Authentication the same as adaptive authentication?

The terms are commonly used interchangeably.

NIST itself refers to "risk-based or adaptive authentication techniques" when describing techniques that identify user behavior falling within or outside typical norms. [1]

In practice, the terminology can sometimes emphasize slightly different parts of the process:

• Risk-Based Authentication tends to emphasize evaluating the risk associated with an interaction.
• Adaptive authentication tends to emphasize changing the authentication response based on that evaluation.

They describe closely related concepts, and in many implementations the same system performs both functions: assessing risk and adapting the authentication journey.

Is Risk-Based Authentication an authentication factor?

No.

Risk-Based Authentication does not itself prove possession, knowledge, or inherence in the same way as a password, passkey, OTP, or biometric authenticator.

Instead, risk signals act as additional context around an authentication decision.

This distinction is particularly important when regulatory or assurance requirements mandate specific authentication factors. A low-risk assessment does not automatically remove those requirements unless the applicable standard or regulation explicitly permits it.

For example, NIST Authentication Assurance Level 2 (AAL2) requires proof of two distinct authentication factors. Indicators of potential fraud can be used to introduce additional controls, but risk signals do not replace the authenticators required to satisfy the assurance level. [1]

This is why RBA works best as an orchestration layer around authentication rather than as a substitute for authentication itself.

Risk-Based Authentication vs static authentication

Traditional or static authentication policies generally apply predefined authentication requirements whenever a particular event occurs. Risk-Based Authentication introduces additional context into that decision.

This does not mean static authentication is inherently weaker. Some interactions should always require a defined level of assurance regardless of context.

The advantage of RBA is that it gives organizations another dimension for making authentication decisions. A known customer accessing an account from an expected device does not necessarily need the same treatment as an account-recovery attempt following a password reset from a new device and location.

How does Risk-Based Authentication work with MFA?

Risk-Based Authentication and multi-factor authentication solve different parts of the authentication problem.

MFA defines how many independent authentication factors are required.

RBA helps determine when additional authentication should be requested or which authentication method should be used.

For example, an organization might allow a routine interaction to proceed after an existing authentication requirement is satisfied but request step-up MFA before a sensitive action if new risk indicators appear.

Alternatively, regulation, policy, or the required assurance level may mandate MFA regardless of the assessed risk. Risk-Based Authentication should not be used to bypass those requirements.

This makes RBA particularly useful as part of an authentication orchestration strategy. Instead of treating MFA as a single challenge that appears everywhere, organizations can determine where additional assurance is necessary and select an appropriate authentication method for the interaction.

Does Risk-Based Authentication improve security?

Risk-Based Authentication can add useful context to authentication decisions, particularly where valid credentials alone do not tell the full story.

An attacker may have the correct password or access to another authenticator but still behave differently from the legitimate customer. Device, network, behavioral, or transaction signals can provide additional evidence that an interaction warrants greater scrutiny.

NIST SP 800-63B-4 explicitly allows indicators of potential fraud to be used at all Authentication Assurance Levels to reduce the risk of misauthentication and gives unexpected geolocation or IP address ranges as examples of events that may prompt additional controls. [1]

However, RBA should not be treated as a replacement for strong authenticators.

Risk signals can be uncertain, manipulated, unavailable, or incorrectly interpreted. The strength of the resulting authentication still depends on the authenticator ultimately used. If phishing resistance is required, for example, the system needs to invoke a phishing-resistant authentication method rather than assuming that a low or high risk score provides phishing resistance.

The stronger model is signals plus authentication, not signals instead of authentication.

Standards and regulatory considerations for Risk-Based Authentication

There is no single global standard that defines how every Risk-Based Authentication system must operate. Its role depends on the applicable assurance model, regulation, industry, and jurisdiction.

NIST Digital Identity Guidelines

NIST SP 800-63B-4 recognizes risk-based and adaptive authentication controls and allows indicators of potential fraud to trigger additional controls during authentication. [1]

The wider NIST SP 800-63-4 Digital Identity Guidelines take a risk-based approach to digital identity architecture more broadly. The 2025 revision expanded digital identity risk management, allows controls to be tailored based on risk, privacy, customer experience, and the threat environment, and introduces requirements for continuous evaluation of identity systems. [2]

NIST also requires organizations applying its guidance to assess the efficacy and potential negative impacts of fraud indicators used in authentication decisions. [1]

EU strong customer authentication and transaction risk analysis

In European payments, Commission Delegated Regulation (EU) 2018/389 provides a specific regulatory example of risk-based decisioning.

Article 18 permits qualifying remote electronic payment transactions to be exempted from strong customer authentication where a payment service provider's real-time transaction risk analysis identifies the transaction as low risk and the other regulatory conditions are satisfied. [3]

The regulation identifies factors including abnormal spending or behavioral patterns, unusual device or software information, known fraud scenarios, location, previous spending patterns, and transaction history. [3]

This is a narrowly defined regulatory exemption rather than a general rule that "low risk means no MFA." Organizations need to apply the requirements relevant to their market and use case.

Privacy and data use

Risk-Based Authentication can involve processing device, behavioral, location, account, or transaction data, making privacy an important design consideration.

NIST SP 800-63-4 requires organizations applying its guidance to consider privacy risks when designing digital identity systems and includes privacy in its broader risk-management process. It also introduces specific requirements where AI or machine learning is used in identity systems, including documenting its use and performing privacy risk assessments for personal information processed by those systems. [2]

Where the EU General Data Protection Regulation applies, personal data must be collected for specified purposes and be adequate, relevant, and limited to what is necessary for those purposes. [4]

Risk-Based Authentication therefore should not become an excuse to collect every signal that is technically available. The signals used should have a clear purpose in the risk decision and be handled according to the privacy requirements that apply.

Does Risk-Based Authentication require AI or machine learning?

No.

Risk-Based Authentication can be implemented using deterministic rules, risk scoring, statistical models, machine learning, or combinations of these approaches.

A straightforward policy might state that a new device combined with an unusual location requires step-up authentication. A more sophisticated implementation may combine many signals into a model that identifies abnormal behavior.

AI and machine learning can support fraud detection and identity decisioning, but they introduce additional governance considerations.

NIST SP 800-63-4 specifically recognizes the use of AI and machine learning in identity systems for activities such as fraud detection. For organizations implementing its guidance, uses of AI and ML must be documented, relevant information about models and testing must be provided to relying organizations, and privacy risk assessments must be performed for personal information processed by these systems. [2]

The important measure is therefore not whether a system uses AI. It is whether its decisions are accurate enough for the use case, understandable and governable, and capable of producing an appropriate authentication response.

What happens when an authentication attempt is high risk?

A high-risk decision should not automatically mean "block the customer."

The appropriate response depends on the nature of the risk and the action being attempted.

Possible responses include:

• requiring an additional authentication factor;
• stepping up to a stronger authentication method;
• asking the customer to re-authenticate;
• limiting a sensitive action;
• using additional verification;
• routing an exceptional case for review; or
• denying the interaction where risk cannot be sufficiently mitigated.

The authentication response should be proportionate to the interaction.

A suspicious routine sign-in and a suspicious account recovery attempt may justify very different responses. Designing RBA around a binary "allow or deny" model can miss the opportunity to use authentication itself as a way to resolve uncertainty.

This is where orchestration becomes important. Risk should inform what happens next, rather than simply produce a score that sits separately from the authentication journey.

What should organizations consider when implementing Risk-Based Authentication?

Effective Risk-Based Authentication depends as much on the decisioning model as it does on the signals being collected.

Start with the action being protected. A risk policy should reflect the consequences of authentication failure. Routine sign-in, account recovery, payments, and changes to sensitive account information may require different thresholds and responses.

Choose signals for a reason. More data does not automatically create a better risk decision. Organizations should understand why each signal is relevant, how reliable it is, and what should happen when it is unavailable.

Separate risk signals from authenticators. Device, location, behavioral, and transaction data can inform a decision, but they should not be confused with the authentication factors used to establish assurance.

Define the response as carefully as the threshold. A medium- or high-risk event needs a clear next action. That may be a passkey, another form of MFA, additional verification, or a different workflow depending on the journey.

Measure false positives and missed risk. An overly sensitive policy can repeatedly challenge legitimate customers, while a policy that is too permissive may fail to detect suspicious activity. Risk policies need to be evaluated and adjusted as behavior and threats change.

Plan for incomplete signals. Customers change devices, travel, use privacy tools, or interact through different networks. Missing or unusual context should not automatically be treated as fraud.

Consider privacy from the outset. Contextual authentication can involve significant amounts of customer data. Collection, retention, use, and access should be proportionate to the purpose of the risk decision and applicable privacy requirements. [2][4]

Keep authentication methods flexible. Risk models and threats will change. Separating the decisioning layer from the authentication methods makes it easier to introduce stronger methods or change step-up policies without rebuilding the underlying customer journey.

NIST's 2025 Digital Identity Guidelines reinforce this need for continuous evaluation, requiring organizations within scope to monitor the evolving threat environment and evaluate the effectiveness, fraud outcomes, customer experience, and privacy impacts of their identity systems over time. [2]

Related authentication terms

Adaptive authentication: Authentication that changes its requirements based on contextual or risk information. Often used interchangeably with Risk-Based Authentication.

Risk signal: Information used to provide context about an authentication attempt, such as device, network, location, behavioral, or transaction information.

Multi-factor authentication (MFA): Authentication that requires evidence from more than one distinct authentication factor.

Step-up authentication: Additional authentication requested when an interaction requires greater assurance.

Authentication Assurance Level (AAL): A NIST classification describing the level of confidence provided by an authentication process.

Passkey: A FIDO authentication credential based on public-key cryptography that can provide phishing-resistant authentication.

Phishing-resistant authentication: Authentication designed to prevent authentication data or valid authentication output from being captured and reused by an impostor verifier.

Authentication orchestration: Coordinating authentication methods, policies, signals, and customer journeys so the appropriate authentication response can be applied in context.

Transaction risk analysis: Assessment of risk associated with an individual transaction. In EU payment regulation, the term has a specific meaning and requirements for certain strong customer authentication exemptions.

Frequently asked questions