Okta Adaptive MFA: Risk-Based Authentication Setup (2026)

Okta’s Risk-Based Authentication (RBA) doesn’t just add MFA; it intelligently decides when you need it, often before a user even realizes they’re in a risky situation.

Let’s see RBA in action. Imagine a user, Sarah, logs in from her usual office IP address. She’s accessing a low-sensitivity app. Okta’s RBA engine, processing the login event, sees "low risk" based on factors like her known location and the application’s sensitivity. The result? She gets straight in, no MFA prompt.

Now, Sarah is traveling and logs in from a public Wi-Fi network in a new city, trying to access a high-sensitivity app. The RBA engine flags this as "high risk." It consults the configured policies and determines that MFA is required. Sarah is prompted for her Okta Verify push notification or a TOTP code.

Here’s the core problem RBA solves: the trade-off between security and user friction. Traditional MFA often means prompting users every time, which is secure but annoying. RBA aims to minimize those prompts for legitimate, low-risk access while ensuring strong authentication for suspicious activity.

Okta’s RBA works by evaluating a multitude of signals during each authentication attempt. These signals are fed into a risk engine that assigns a risk score. This score is then compared against policies you define to determine the appropriate authentication action.

Key Signals Okta Considers:

• Location: Is the login from a known or new IP address? Is it a country the user has never accessed from before?
• Device: Is the user logging in from a known, trusted device, or an unknown one? Is the device compliant with Okta’s device trust policies?
• Network: Is the IP address associated with known anonymizers (like Tor exit nodes or VPNs)? Is it a common proxy IP?
• Behavioral Anomalies: Is this login attempt significantly different from the user’s typical behavior patterns (e.g., time of day, frequency of logins)?
• Application Sensitivity: What is the configured sensitivity level of the application being accessed?

Setting Up Risk-Based Authentication in Okta:

1. Enable Risk-Based Authentication:

   • Navigate to Security > Authenticators.
   • Under "Relying on Okta’s risk engine," click Manage Integrations.
   • Ensure Okta ThreatInsight is enabled (this is a prerequisite for some advanced risk signals).
   • Click Add Authenticator and select Okta.
   • Under "Risk-based authentication," toggle Enable risk-based authentication to On.

2. Define Authentication Policies: This is where you tell Okta what to do based on the risk score.

   • Navigate to Security > Authentication Policies.

   • Create a new policy or edit an existing one.

   • Within a policy, you’ll see rules. For each rule, you can define conditions. One crucial condition is "Risk level."

   • You can set rules for:

     • Low: Typically allows access without MFA.
     • Medium: May require a second factor.
     • High: Almost always requires a second factor.
     • Very High: May require additional verification steps or block access.

   • Example Rule Configuration:

     • Rule Name: "Require MFA for Medium/High Risk"
     • Conditions:
       • User’s risk level: Medium or High
       • Application: Select the relevant applications or groups of applications.
     • Actions:
       • Authentication methods: Require authenticators
       • Select authenticators: Choose the MFA factors you want to allow (e.g., Okta Verify Push, Security Key, Google Authenticator).

3. Configure Individual Authenticators:

   • Navigate to Security > Authenticators.
   • For each MFA authenticator (e.g., Okta Verify, YubiKey), ensure it’s configured and available for use.
   • Under Okta Verify, for example, you can configure settings like "Number of push notifications allowed" or "Number of days before re-authentication."

4. Assign Policies to Applications:

   • Navigate to Security > Authentication Policies.
   • Under the "Policies" tab, click Add a policy.
   • Give it a name (e.g., "High Security App Policy").
   • Click Add Rule and configure it as described in step 2, specifying the desired risk levels and required authenticators.
   • Once the policy is created, go to Applications > Applications.
   • Select the application you want to apply this policy to.
   • Go to the Sign On tab.
   • Under Sign On Policy, click Edit.
   • Change the policy to your newly created RBA-aware policy.

The magic happens when Okta’s risk engine analyzes the login attempt against your defined policies. If Sarah logs in from a new IP address accessing a sensitive app, and her risk score crosses the "Medium" threshold you set in your policy, Okta will automatically enforce the MFA rule you configured for that risk level.

One aspect that often trips people up is the interplay between the "Risk level" condition in Authentication Policies and the actual authenticator enrollment. If your policy requires "Okta Verify Push" for Medium/High risk, but the user hasn’t enrolled in Okta Verify, they will be blocked. You need to ensure users are enrolled in the MFA factors you’re requiring for higher risk levels. This often involves setting up enrollment policies that prompt users for MFA setup as part of their initial login flow or before accessing certain applications.

The next step is often exploring how to leverage Okta’s Device Trust and integrate it with RBA for even more granular control.