Getting started with Conditional Access: Comparing Entra ID Conditional Access with Cisco Duo

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

In case you missed it, in last week’s blog we broke down the differences between conditional access policies in Entra ID and Okta.

A few weeks ago I joined Red Canary’s weekly Office Hours to chat with Keith McCammon about why defenders need to pay attention to Conditional Access.

Architecture and approach

Duo is a slightly different beast. While Microsoft and Okta are full identity providers—handling primary login and then policy—Duo has traditionally been a two-factor authentication (2FA) service layered on top of existing authentication flows. Duo’s multi-factor authentication (MFA) is designed to integrate with Entra ID, Active Directory Federation Services (AD FS), and cloud apps to secure the authentication at the time of login. Duo has evolved to include its own Policy & Control framework that’s effectively conditional access. While it offers single sign-on (SSO), it is frequently positioned as a security layer that complements existing identity management systems rather than a full-fledged, full-lifecycle identity and access management (IAM) platform like Okta.

In this article, we’ll focus on the ways that Duo’s Adaptive Access Policies compare to Entra ID Conditional Access (CA).

Policy scope

Let’s cover the basics first. Duo policies can be applied globally (to all Duo-protected applications) or per application and even per group of users. For example, you might have a global Duo policy stipulating that no one can log in from certain countries and a specific policy on your Salesforce application that requires device health checks. Duo’s admin panel allows creating policy sets that you can then assign to applications. This is conceptually similar to Entra ID, where you define a CA policy and assign it to apps/users and the granularity is comparable.

MFA enforcement

Duo’s bread and butter is MFA. With Duo, any protected application will prompt for 2FA—Duo Push, SMS, call, token, etc.—by default. Duo policies can also control when to prompt. For instance, using “Remembered Devices”— Duo allows a browser to stay authenticated for x number of days before asking for 2FA again—similar to Entra ID’s persistent cookie or sign-in frequency.

Duo also can conditionally bypass MFA in certain cases: e.g., if coming from a trusted network, you might auto-approve or not prompt (if you configure it that way—though Duo generally still encourages MFA every time unless a policy says otherwise).

Device conditions

Duo can keep track of devices, their “enrollment” state, and their compliance levels with a couple features that will be familiar to folks who have read through the first two parts of this series. Similar to Okta and Entra, Duo uses apps deployed on your workstations and mobile devices to establish trust. To check the compliance or health of a device, Duo can check if the device is one of your known managed devices either via certificate (agentless) or via the Duo device health app (which reports operating system info, firewall, disk encryption status, etc.). In policy, you can then choose from “Block access from unknown devices” or “Only allow devices that pass certain health checks.” For example, Duo can enforce that a laptop has its OS up to date or that it’s not running an outdated browser with known vulnerabilities.

Duo has a bit of an all-in-one agent (Device Desktop) that can be deployed on workstations to report things like OS version, encryption, etc., at login time. With Duo, you might configure: “Windows devices must have at least Windows 10 version x and antivirus enabled; if not, block them.” This maps to Entra ID’s capability if you use Intune compliance policies (where you set compliance rules for OS version, AV, etc., and then CA requires compliance).

There are advantages and disadvantages to leaning on Duo for compliance checks and policy enforcement. From an admin view, Duo’s device policies are quite granular and user-friendly—you can toggle rules to “block Jailbroken iOS” or “block Windows below version 10.0.19042” easily. Entra ID can do that with device compliance or the new CA device filter, but it’s arguably simpler in Duo’s graphical user interface (GUI) if you’re already using Duo for MFA.

Be that as it may, if you’re already managing all your devices with Intune, it can be hard to argue that features gained in Duo outweigh the increased management overhead of deploying another agent to your environment.

Location and network

Duo offers “User location” policies to allow or block from certain countries. Duo uses the IP geolocation of the access device (client’s IP as seen by Duo’s service, typically the egress IP of the user). This is akin to the Entra ID named locations condition. Duo also has something it calls trusted networks, where you can designate certain IP ranges as trusted and have different rules (some choose to exempt logins from an internal network, for example). Capability-wise, Duo compares closely with Entra ID and Okta when it comes to geo and network conditions.

Risk-based adaptation

Long ago, Duo did not offer the same type of risk engine as Microsoft/Okta, but in 2023 they introduced Risk-Based Authentication (RBA) features for Advantage and Premier license tier customers. Duo’s RBA focuses on detecting anomalies in the MFA step. For example, Duo can block access when it detects an unusual number of push attempts (which might indicate an adversary bombing the user’s phone) or if a login attempt comes from a new location or device. Duo RBA has two main components: Risk-Based Factor Selection and Risk-Based Remembered Devices.

With Risk-Based Factor Selection, if a login seems risky, Duo can enforce a more secure MFA method. For example, instead of just a simple push, it could require the user to perform a Verified Duo Push (which involves matching a numeric code) or require a hardware token.

Remember the problem we looked at in part one of this series, where long running sessions need some help from Entra conditional access evaluation to make sure risk doesn’t change after login? Duo is on the same track with Risk-Based Remembered Devices. This feature allows Duo to shorten the “remember me” interval if things look risky, effectively not remembering the device if an anomalous sign-in happens. The risk signals Duo uses includes things like IP history for the user (if an IP or ASN is new for that user) and potentially device fingerprinting changes. This is somewhat narrower than Microsoft’s risk evaluation capabilities, but it addresses specific attacks like cookie replay or MFA fatigue by enforcing second-factor prompts more stringently when something odd is detected.

In terms of monitoring for compromised credentials, Duo doesn’t have a direct concept; instead it relies on the primary authentication source (AD or SSO) or third-party tools to handle credential compromise detection. Duo primarily focuses on enforcing security policies at the point of authentication.

Mapping conditional access policies in Duo

Looking back at our five must-have conditional access policies, let’s correlate them to Duo:

1. Block legacy authentication

Duo itself doesn’t directly block legacy protocols like IMAP because typically Duo isn’t invoked for those protocols (unless you front-end them with a proxy that calls Duo). However, if you integrate Duo with, say, Exchange via modern auth, legacy will be turned off in Exchange anyway. So Duo doesn’t solve legacy auth – you handle that at source (Exchange, etc.). In Microsoft’s case, if using Duo with Office 365, you’d still implement the block legacy auth in Entra ID or Exchange Online, because Duo can only work when modern auth triggers it.

2. Require MFA for all users

This is essentially what Duo does; any app you protect with Duo will require MFA by default. Duo’s global policy can enforce MFA for all applications unless a rule says otherwise. Duo even has a setting to force enrollment, ensuring users register a 2FA device. So yes, Duo covers this strongly.

3. Require MFA for risky sign-ins

Duo can’t detect a “risk” before primary authentication but its RBA might detect some anomalies during the 2FA process (like new IP, etc.) and could force a stronger factor or re-prompt for credentials if integrated with Duo’s SSO. However, in many deployments, Entra ID/AD FS/Okta would be the one detecting risky sign-ins and possibly not even invoking Duo if risk is high and they decide to block. If Entra ID and Duo are both in play (some use Entra ID as primary and Duo as secondary via CA custom controls), you’d rely on Entra ID’s risk to decide to call Duo or not. If Okta is primary and Duo is just a factor, Okta’s risk engine could decide to invoke Duo or deny. So Duo’s RBA is more about adjusting the MFA prompt behavior.

4. Block or remediate compromised accounts

Duo doesn’t have a feature to automatically disable an account with leaked credentials​​—that would be up to Active Directory (AD) or your IdP, but you can knock a user into a “bypass” status or deactivate them in Duo if you suspect a compromise.

5. Require trusted (compliant or joined) devices for sensitive resources

Duo shines here—you can definitely require a device certificate or the Duo device health check. For instance, you can set a Duo policy on your HR app: “Only allow access if the Duo device health app reports the device is healthy and corporate.” This is analogous to Entra ID’s compliant device policy and, in practice, many companies use Duo for exactly this if they don’t have Intune. Duo’s approach is tool-agnostic: it can check if a device has a certain certificate (maybe one your IT issued) or if certain registry keys exist. It’s not as deeply integrated with an endpoint management platform unless you use their own agent. While Entra ID’s device compliance might piggyback on a full mobile device management (MDM) solution, with more device lifecycle management, Duo’s is more point-in-time posture check. Both are valid; in fact, some organizations layer Duo on Entra ID specifically to get the device health policy feature for non-Intune devices.

Integration with Microsoft

It’s worth noting that you can use Duo with Entra ID Conditional Access: Entra ID has an option for “custom controls” where a third-party like Duo can act as the MFA provider. In that case, Entra ID would evaluate sign-in risk, device, etc., and then, if policy says require MFA, it will hand off to Duo for the second factor. This setup is common when organizations prefer Duo’s MFA across all apps. In such a scenario, you get the best of both—Entra ID’s primary auth and conditional signals, plus Duo’s device health and strong MFA. The downside is added complexity and cost (licenses for both).

Licenses

To use features comparable to what we discussed: Duo Advantage or Premier editions are needed for device health and risk-based policies. The Essentials (base) tier gives MFA and some basic policies but not the advanced RBA or device checks. As we discussed in our first blog, it’s similar to Entra ID P1 vs P2; advanced stuff costs more.

Conditional access sets a baseline

The five policies we discussed—blocking legacy auth, requiring MFA, leveraging sign-in and user risk, and enforcing device trust—form a common baseline for protecting identity. Microsoft Entra ID makes implementing these straightforward if you have the licenses, and it natively ties into the rich telemetry Microsoft gathers (which is a big advantage). Okta and Duo offer comparable features, though you may need higher-tier plans and a bit of integration work (especially for device trust).

Each solution has its nuances but the overarching goal is the same: reduce the attack surface and stop identity-based attacks. By adopting these conditional access policies, you are significantly hardening your identity layer; often the first and favorite target of adversaries.