Guide to risk-based authentication

RBA is part of the broader practice of identity and access management (IAM), which deals with provisioning and protecting digital identities and user access permissions in an IT system. For RBA, organizations use criteria such as location, device, IP address, time and behavioral patterns to assess the risk level of an access request. The more red flags that a user shows, the more rigorous the authentication process becomes.

A typical risk-based authentication process might proceed as follows: A user enters their username and password in an enterprise single sign-on (SSO) platform. An RBA tool collects and evaluates the relevant metadata for this particular login attempt. The tool then calculates a risk score based on these factors. For example, is the user signing in from a new location? Is the user requesting access to a particularly sensitive database?

Based on that risk score, the appropriate security policies are applied to prevent unauthorized access. Broadly, the authentication tool will allow access, request additional verification or block the login and alert the security team if the risk of a data breach or account takeover is deemed high.

Risk-based authentication works by evaluating a login attempt or system access request, assigning a risk score, enforcing security policies and logging the event to help evaluate future requests.

The RBA process starts with the evaluation of a login attempt or access request. RBA tools can use several contextual signals to determine risk level. Common factors include device, location, time and sensitivity.

1. The security posture of the device from which the login or request originates plays a large role in determining the risk level. If the user has never used this device before, device patches are not up to date or the operating system or other software versions are unusual, the risk score will increase.
   
   
2. The location of the attempt, tracked by geolocation, IP address and network type can increase the risk score if it is unusual. Another red flag is if the location is impossible for the user to have reached since their previous login. For example, if the same user logs in from Chicago in the morning and Tokyo by the afternoon, that will be treated as a red flag.
   
   
3. Login attempts at an unusual time of day can also indicate suspicious activity, such as a user logging in outside of normal work hours. An excessive number of access requests in a short period can also elevate the risk level.
   
   
4. The sensitivity of the requested asset or behavior can also trigger enhanced authentication measures. For example, a request to read a sensitive database might require two-factor authentication (2FA), while a request to edit that same database might require three or more factors.

Based on the context, the RBA tool assigns the access request an overall risk score. The higher the risk score, the stronger the authentication challenge.

• A login attempt that is evaluated as low risk uses the network’s standard authentication measures, often just a password or passkey.
  
  
• A medium-risk request triggers extra verification measures, such as a one-time password (OTP) from an authentication app, a push notification to a registered device, a physical security key or biometric authentication.
  
  
• High-risk login attempts might automatically deny access and trigger an alert for the security team.

If the login attempt is classified as medium or high risk, the authentication system takes stricter measures to verify (or block) the attempt.

Multifactor authentication—which verifies a user’s identity by requiring at least two distinct proofs, such as a password and a biometric scan—is one of the most common methods used to escalate verification challenges. RBA implementations might also use fully passwordless authentication methods, such as passkeys or physical security keys.

This process of adding more authentication steps based on risk is sometimes called “step-up authentication.” Increasingly higher-risk access requests, or access to increasingly sensitive materials, require extra steps to verify identity.

For very high-risk attempts, the login might be automatically blocked, and a legitimate user might need to contact an administrator to proceed.

Most RBA tools log each access request. Logs capture basic metadata, risk signals associated with the attempt, the risk score, challenge and outcome. This data is stored to inform future evaluations.

1. Metadata can include the criteria that are used to evaluate risk such as user, time, device, IP address and the application being accessed.
   
   
2. Risk signals are the conditions that are evaluated for each of these steps, such as whether the device is known or not, the specific location or whether a VPN is being used.
   
   
3. The risk evaluation is the risk score and the corresponding “bucket” the attempt falls into (low, medium or high risk).
   
   
4. The authenticator also records the challenge methods used to verify the login attempt and the ultimate disposition of the attempt (access granted, restricted or denied).

Logging this information creates a baseline for normal behavior that the authentication system can use for future evaluations. The logs are sometimes used to train machine learning models that help evaluate risk. Logs also help identify patterns among suspicious logins, inform investigations of breaches and maintain compliance with regulations such as the Health Insurance Portability and Accountability Act (HIPAA) or the European Union’s General Data Protection Regulation (GDPR).

RBA is also useful for authenticating logins by nonhuman identities, digital identities attached to bots, AI agents, apps, services, workloads, devices or other nonhuman users.

With the rise of agentic AI and the increased automation of IT infrastructure, NHIs have come to represent a greater proportion of login attempts and access requests. NHIs have different characteristics from human users and therefore pose different risks. Factors such as geographic location, travel time and MFA use are not applicable to NHIs, so administrators must evaluate different signals to ensure that an NHI login attempt is legitimate.

Common risk factors evaluated in RBA for NHIs include:

• Credential risk such as expired certificates, the use of a secret known to be compromised or credentials that have not been rotated in a timely fashion.
  
  
• Network anomalies such as an unknown IP address newly associated with a known application.
  
  
• Anomalous behavior that deviates from the system baseline, such as more frequent API calls or an increased number of access requests from the same AI agent.
  
  
• Overprivileged accounts that give NHIs more permissions than they need for the tasks they are trying to accomplish.

If a nonhuman identity’s behavior is judged risky, an RBA system can respond in one of two ways. It can ask for more proof of the NHI’s identity. Instead of biometrics or OTPs, this proof would be something such as a cryptographic key, hash or code-signing certificate. The RBA can also respond by narrowing the NHI’s permissions—for example, issuing a shorter-lived token or rate-limiting the NHI’s calls. 

Risk-based authentication differs from continuous authentication primarily in the timing of the authentication process. While RBA occurs at the time of a login or access attempt, continuous authentication runs in the background throughout the entire session.

Continuous authentication monitors users after access has been granted and reevaluates their behavior continuously. If a user’s behavior deviates from the norm, continuous authentication might issue step-up authentication challenges.

While they might have technical differences, the two authentication methods are often used together. Continuous authentication monitors user activity throughout the session, and RBA risk scoring helps determine when to issue new authentication challenges and how strict those challenges should be.

Adaptive authentication is any authentication method that dynamically adapts its requirements instead of using a single, static authentication challenge for each request. RBA also adjusts authentication challenges, but it does so based specifically on risk.

While these distinctions can be made, there is no unanimous agreement on where to draw the line—or whether to draw it at all. Some vendors treat RBA and adaptive authentication as synonyms. Others treat RBA as a type of adaptive authentication. Some treat them as entirely distinct, with adaptive authentication referring only to dynamic authentication methods that are unrelated to risk level. 

Benefits of RBA include streamlining the organization’s security posture, strengthening compliance and enhancing the practice of zero trust security.