Getting started with Conditional Access: Comparing Entra ID Conditional Access with Okta

Microsoft Entra ID is not the only player in town for conditional access (CA) policies. Many organizations use Okta Workforce Identity (Okta)  or Duo Security (Cisco Duo) to protect identities and manage access. While the core goals are similar—enforce MFA, check device security, consider risk—the implementation and capabilities differ.

In this blog, the second in our series on getting started with conditional access, we provide an in-depth comparison of how Microsoft and Okta implement similar policies and how they are different.

In case you missed it, I recently joined Red Canary’s weekly Office Hours to chat with Keith McCammon about why defenders need to pay attention to Conditional Access.

Okta Identity Cloud (Adaptive MFA) vs. Entra ID Conditional Access

Policy scope and structure

Microsoft Entra ID Conditional Access acts as a centralized policy engine evaluating every app sign-in against a set of “if, then” rules. Similarly, Okta uses sign-on policies that can be defined at the organization level and for individual applications. In Okta, you typically have a default sign-on policy and then custom policies per app or group of users, each containing ordered rules with conditions.

Both systems essentially do if-then logic but Entra ID’s CA is unified: policies are tenant-wide and can target all or multiple apps, whereas Okta attaches policies to either the whole org or specific apps with a priority order.

This means in Okta you might write one rule for a Salesforce app sign-on requiring multi-factor authentication (MFA) and another for a different app, whereas in Entra ID you could have one CA policy that covers many apps. While Entra ID lets you include or exclude specific apps, its policies typically enforce the same access controls for targeted resources, making it ideal for broad, organization-wide security requirements. Okta in contrast, excels when different workloads demand distinct security requirements.

Conditions and signals

Both Okta and Entra ID consider similar signal types: who the user is, where they’re coming from, device information, etc. Microsoft’s CA has rich conditions out of the box: user/group, cloud app, IP location (formerly known as “locations”), device platform, device state (compliant/hybrid joined), client app type, and Identity Protection risk level.

Okta offers conditions in its policy rules such as group membership, network zone, device trust, location, and risk level (with Adaptive MFA). For example, Okta admins can define a rule (“If user is outside of the corporate network—as defined by an IP zone—or on an untrusted device, then prompt for MFA.) Okta uses the concept of network zones, which can be static IP ranges or dynamic (geolocation-based) zones. You can configure Okta to block or prompt based on country by creating a dynamic zone for that country. Both systems let you implement geo-blocking (Entra ID calls it country Named Locations , Okta calls it dynamic zones) and trusted IP ranges (Entra ID calls it “trusted locations,” Okta calls it network zones).

Device trust and compliance

Microsoft’s approach to device-based access uses its endpoint management integration: devices registered in Entra ID and optionally marked compliant via Intune. Okta, in contrast, has a feature called Device Trust and the newer Okta Device Context (in Okta Identity Engine) to ensure a device is managed. Okta’s device trust relies on distributing certificates or having the Okta Verify app installed with management attestation.

For example, Okta can integrate with Intune or other mobile device management (MDM) tools to verify they are managed, but it can get complicated to get Okta to verify the compliance state of the workstation via Intune. Okta has introduced the concept of Okta FastPass with Okta Verify, which can cryptographically register a device (Windows, macOS) to Okta and serve as a passwordless factor—this gives Okta its own notion of a “managed device” if the device is enrolled in Okta Verify and meets certain conditions.

In practice, making a policy like “only allow managed devices” can be more straightforward in Entra ID if you’re already in the Microsoft ecosystem (just leverage Entra ID join/Intune). In Okta, it’s doable but requires setup (e.g., deploy certificates via MDM, configure Okta device trust policies). Both can achieve a similar end: blocking untrusted endpoints. Microsoft’s CA does it by device state, Okta by device trust policies.

Multi-factor authentication

Both Entra ID and Okta support a variety of MFA methods and can require MFA based on conditions. Okta’s Adaptive MFA is very similar to Entra ID’s conditional MFA: you can prompt for MFA for all logins or only when certain conditions are met.

Okta and Entra ID both now have “phishing-resistant MFA” options—Entra ID via authentication strength (e.g., require phishing-resistant methods only) and Okta via policy conditions or factor settings (e.g., only allow FIDO2 or Okta Verify Push with a number challenge for certain apps).

In short, both platforms are robust when it comes to MFA enforcement. The key difference is if your organization primarily uses Microsoft 365, Entra ID’s MFA is very tightly integrated (e.g., Office apps know how to prompt with Entra ID). Okta often sits in front of apps via SAML/OIDC, so for O365 integration it can get complex (modern authentication with Okta involves federating Entra ID to Okta and using Okta MFA—which is totally doable, but you may lose some of Microsoft’s risk-based features).

Risk-based authentication

Entra ID Identity Protection uses Microsoft’s risk analysis (impossible travel, unfamiliar sign-in properties, leaked credentials, etc.) and surfaces user risk and sign-in risk that we discussed in policies #3 and #4 in part 1 of this blog series. Okta has its version of this in Adaptive MFA with risk scoring. Okta’s risk engine assigns a risk level to each sign-in (low/medium/high) based on factors like IP reputation, geo, device, user behavior, and known threats.

The difference is mostly behind the scenes: Microsoft’s risk detections include a very broad signal set (including things like credentials seen in dark web dumps, which Okta may not have unless integrated with a third-party), whereas Okta’s solution tends to focus on behavioral and environmental anomalies.

Both are effective in their realms. If anything, Microsoft’s might catch more types of risk (thanks to their telemetry from Microsoft accounts, etc.) while Okta’s is customizable within its ecosystem. From an admin perspective, enabling Okta’s risk-based policies is straightforward if you have the right license (it’s part of Okta Advanced MFA or Identity Assurance packages); check out part 1 of our series for more information on the prerequisites for Entra ID Conditional Access policies.

User risk (compromised credentials)

Entra ID assigns a user risk score of “high” to users when they have one or more risks on their account, including leaked credentials. Okta doesn’t natively scan external breaches for your users (unless you hook in an API or have a service). However, Okta ThreatInsight will block known malicious IPs automatically if enabled.

If you wanted an Okta policy analogous to Entra ID’s user risk policy, you might want to integrate something like a breach notification system. Okta can force password changes via policy (for example, if a user is flagged as high risk, you could have a rule to prompt them to reset their password or just lock them out). But out of the box, Okta’s “risk” mitigation mostly pertains to sign-in anomaly risk, not a persistent user risk score like Entra ID’s, meaning Entra ID has a bit of an edge here with its built-in leaked credential detection.

Enforcement options

Both Entra ID and Okta share common outcomes: allow, allow with conditions (MFA, device, etc.), or block. Entra ID CA’s unique outcomes include things like session controls (like requiring an app to be opened in session proxy or requiring a password change—though the latter is Entra ID Identity Protection-specific). Okta’s policies can force password resets if certain conditions are met (like after a certain number of days since last change or using their API if needed), but typically Okta outcomes are: allow, prompt for MFA, or deny. Okta doesn’t have a native “force password change on risky login” trigger in the UI—Entra ID provides that as a baked-in option (user risk policy).

Admin experience

Some security teams prefer Okta’s explicit rule listing per app: you can see exactly which conditions apply to that app. In Entra ID, you have to review multiple CA policies to understand what affects a given app or user (Entra ID provides a “What If” tool, but there’s no single screen listing all policies by app). This can lead to some admin confusion in Entra ID if you accumulate too many policies. On the flip side, Entra ID’s logging for CA events is very detailed and integrated with its security portal; it also shows exactly which policy is blocked or granted access.

Lots to like about both

In summary, both Okta and Entra ID can help implement the critical policies we outlined in the first blog in our series.  And while in part one we focused on Microsoft, Okta can serve the same use cases: For example – enforce MFA – Okta can auto-enroll users in MFA similar to Entra ID’s MFA registration policy, & block legacy apps – if using Okta as IdP, you’d simply not allow basic auth to your apps—e.g., for Office 365, you’d disable basic auth on Exchange side or through Okta’s Office 365 integration settings.

When comparing the two, keep in mind:

• Okta excels in multi-app and non-Microsoft scenarios, and it now has a solid risk engine for adaptive authentication.
• Entra ID excels in Microsoft-centric device/user integration and has very mature risk intel. Many organizations use a combination (e.g., Okta for primary SSO but still leverage Entra ID Conditional Access for Office 365 by federating and using Entra ID’s controls as well).

Two not-so-shocking recommendations

• If you already pay for Microsoft 365 E5 or equivalent, you have these CA features included – leveraging them is a no-brainer.
• If you’re an Okta shop, ensure you turn on Okta ThreatInsight and Adaptive MFA policies to block risky logins and require MFA in similar scenarios.

Stay tuned

Continuing this series, we’ll compare Microsoft Entra ID Conditional Access policies to the core functionalities in Cisco Duo.