Your Okta MFA policies can dynamically adjust their requirements based on the assessed risk of a login attempt, meaning users might not always be prompted for a second factor.
Let’s watch this in action. Imagine a user, Alice, logs in from her usual work laptop at the office. Okta’s risk engine analyzes this: known device, trusted location, normal login hours. Low risk. She might only need her password. Now, Alice logs in from a new, unfamiliar device in a foreign country at 3 AM. Okta flags this as high risk. Now, even if she’s already authenticated with her password, Okta will demand MFA.
This dynamic MFA enforcement is powered by Okta’s Risk-Based Authentication (RBA) feature. The core idea is simple: not all logins are created equal. Some are inherently more suspicious than others. Instead of a blanket "always ask for MFA" rule, RBA allows you to tailor the authentication experience. For low-risk scenarios, you can streamline access to reduce user friction. For high-risk scenarios, you can layer on additional security checks, like MFA, to protect against compromised credentials or account takeovers.
Here’s how it works internally. When a user attempts to log in, Okta collects a variety of signals:
- Location: Is this a known IP range, a new country, or a Tor exit node?
- Device: Is this a device the user has logged in from before? Is it managed by the organization? Does it have Okta’s device posture agents installed?
- Behavior: Is this login happening at an unusual time of day for this user? Is the login velocity too high (e.g., multiple logins from different locations in a short period)?
- Credential Usage: Was the password entered correctly? Was it a brute-force attempt?
Okta’s threat intelligence engine analyzes these signals and assigns a risk score to the login event. This score then feeds into your Okta sign-on policies. You configure these policies to specify what actions Okta should take based on different risk levels.
Let’s break down the levers you control. In Okta, you’ll primarily be working within Security > Authentication > Policies.
- Sign-on Policies: These are the top-level rules that dictate when and how users can access applications. You’ll create or modify these policies to include risk-based conditions.
- Conditions: Within a sign-on policy rule, you define the conditions that trigger the rule. This is where you’ll add "Risk" as a condition. You can set thresholds for "Low," "Medium," and "High" risk.
- Actions: For each risk-based condition, you define the action Okta should take. Common actions include:
- Allow: The user can proceed with just their password (or whatever is required by lower-tier policies).
- Factor Verification: Prompt the user for an MFA factor.
- Step-Up Authentication: Require an additional MFA factor, even if they’ve already completed MFA for this session.
- Block: Deny access entirely.
Consider this example rule within a sign-on policy for a critical application like your CRM:
- Rule Name: "MFA for High Risk Logins"
- Conditions:
- User’s authentication is "High" risk.
- Actions:
- Require "Factor Verification" (MFA).
This means if Okta detects a high-risk login, the user must complete an MFA challenge, regardless of other factors. You can create similar rules for "Medium" risk, perhaps requiring a less intrusive MFA method, or for "Low" risk, allowing password-only access if other conditions are met (like being on a trusted network).
The real power comes from combining these risk-based conditions with other factors. For instance, you might have a rule that says: "If the user is on a new device AND the risk is Medium or higher, require MFA." This catches scenarios where a legitimate user is trying to access from an unrecognised device, but Okta’s overall risk assessment is elevated.
Here’s a concrete example of how you might configure this in Okta. Navigate to Security > Authentication > Policies. Click on your primary sign-on policy. Click "Add Rule."
- Rule Name:
Require MFA for Medium to High Risk - Conditions:
- Click Add Constraint. Select Risk. Choose Medium from the dropdown.
- Click Add Constraint again. Select Risk. Choose High from the dropdown.
- Click Add Constraint again. Select Device. Choose Is not registered from the dropdown.
- Actions:
- Under User must authenticate with: Select MFA.
- Under On any device: Select Factor verification.
This rule ensures that if a user attempts to log in from a device that Okta doesn’t recognize, and the login attempt is flagged as either medium or high risk, they will be forced to authenticate with an MFA factor. The "On any device" setting ensures this applies universally if the risk and device conditions are met.
One aspect that often gets overlooked is how Okta’s risk engine learns and adapts. It’s not just a static set of rules. The system continuously analyzes successful and failed login attempts across your entire Okta tenant. This collective intelligence helps it refine its risk assessments over time. For example, if a specific IP range that was previously flagged as medium risk starts showing a pattern of legitimate user logins, Okta might gradually lower its risk score for that range. Conversely, a new pattern of suspicious activity could cause previously benign locations or devices to be flagged as higher risk. This continuous learning is crucial for maintaining both security and user experience, as it helps prevent false positives that frustrate users and false negatives that leave your organization exposed.
Once your risk-based policies are in place, the next logical step is to explore how to integrate this with your actual application access flows, perhaps by ensuring that applications with sensitive data always enforce MFA even when Okta’s risk score is low.