Set up Conditional Access policies on Azure DevOps

With Microsoft Entra ID, tenant admins control which users access Microsoft resources through Conditional Access policies. Admins set specific conditions users must meet to gain access, such as:

• Membership in a specific Microsoft Entra security group
• Location or network requirements
• Use of a particular operating system
• Use of a managed and enabled device

Based on these conditions, you can grant access, require more checks like multifactor authentication, or block access entirely. For more information, see Conditional Access policies in the Microsoft Entra documentation.

Prerequisites

Create a Conditional Access policy for Azure DevOps

1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
2. Browse to Entra ID > Conditional Access > Policies.
3. Select New policy.
4. Enter a name for your policy. Create a meaningful standard for the names of your policies.
5. Under Assignments, select Users or workload identities.
   1. Under Include, select All users.
   2. Under Exclude:
      • Select Users and groups.
        • Choose your organization's emergency access or break-glass accounts.
6. Under Target resources > Resources (formerly cloud apps) > Include, Select resources, add "Azure DevOps" or "Microsoft Visual Studio Team Services" resource (resource ID: 499b84ac-1321-427f-aa17-267ca6975798) to the list of target resources.
7. Under Access controls > Grant, select Grant access, Require authentication strength, select Multifactor authentication, and then select Select.
8. Confirm your settings and set Enable policy to Report-only.
9. Select Create to enable your policy.

After confirming your settings by using policy impact or report-only mode, move the Enable policy toggle from Report-only to On.

Conditional Access behavior on web

When you sign in to the web portal of a Microsoft Entra ID-backed organization, Microsoft Entra ID validates all Conditional Access policies set by tenant administrators. After modernizing the web authentication stack to use Microsoft Entra tokens, Azure DevOps enforces Conditional Access policy validation on all interactive (web) flows.

• Meet sign-in policies when you use personal access tokens (PATs) on REST API calls that rely on Microsoft Entra.
• Remove Azure DevOps as a resource from the Conditional Access policy to prevent Conditional Access policies from applying.
• Enforce MFA policies on web flows only. Block access for non-interactive flows if users don't meet a Conditional Access policy.

IP-based conditions

If you enable the IP Conditional Access policy validation on non-interactive flows organization policy on the Organization Settings page, Azure DevOps checks IP fencing policies on non-interactive flows, such as when you use a PAT to make a REST API call.

Azure DevOps supports IP-fencing Conditional Access policies for both IPv4 and IPv6 addresses. If Conditional Access policies block your IPv6 address, ask your tenant administrator to update the policy to allow your IPv6 address. Also, consider including the IPv4-mapped address for any default IPv6 address in all Conditional Access policy conditions.

If users access the Microsoft Entra sign-in page from a different IP address than the one used to access Azure DevOps resources (common with VPN tunneling), review your VPN configuration or networking setup. Confirm that your tenant administrator includes all relevant IP addresses in the Conditional Access policies.

Azure Resource Manager audience

Azure DevOps doesn't depend on the Azure Resource Manager (ARM) resource (https://management.azure.com) when you sign in or refresh Microsoft Entra access tokens. Previously, Azure DevOps required the Azure Resource Manager audience during sign-in and token refresh flows, which meant administrators had to allow all Azure DevOps users to bypass Azure Resource Manager Conditional Access policies.

If you previously set up a Conditional Access policy for Azure Resource Manager or the associated Microsoft Azure classic deployment model application, that policy no longer covers Azure DevOps sign-ins. Set up a new Azure DevOps Conditional Access policy for continued coverage.

The following groups still require access to Azure Resource Manager. Consider adding them as exclusions to any Azure Resource Manager or Microsoft Azure classic deployment model Conditional Access policies.

• Billing administrators need access to Azure Resource Manager to set up billing and access subscriptions.
• Service Connection creators require access to Azure Resource Manager for Azure Resource Manager role assignments and updates to managed service identities (MSIs).

Continuous Access Evaluation

Azure DevOps supports Continuous Access Evaluation (CAE) via Microsoft Entra ID, which enables near real-time enforcement of Conditional Access policies. With CAE, access tokens can be revoked immediately when critical events occur—such as when a user is disabled, a password changes, or a location/IP shift happens—without waiting for token expiration. This approach enhances security, reduces operational overhead, and improves resilience during identity service outages.

App developers who use the latest .NET client library version (20.259.0-preview and later) should support CAE-enabled tokens by gracefully handling claims challenges.

Use AI to manage Conditional Access policies

If you have the Azure DevOps MCP Server configured, you can use AI assistants to review and manage Conditional Access policy settings for your Azure DevOps organization using natural language prompts. The MCP Server provides your AI assistant with secure access to your Azure DevOps data, allowing you to check policy configurations and organization security settings without navigating through multiple portals.

Example prompts for Conditional Access policies

Related content

• Change application connection & security policies for your organization