Edit

Share via


Change application connection & security policies for your organization

Important

Azure DevOps doesn't support Alternate Credentials authentication. If you're still using Alternate Credentials, we strongly encourage you to switch to a more secure authentication method.

This article shows how to manage your organization's security policies that determine how users and applications can access services and resources in your organization. You can access most of these policies in Organization settings.

Prerequisites

Category Requirements
Permissions

Manage a policy

To update application connection, security, or user policies for your organization, follow these steps:

  1. Sign in to your organization at https://dev.azure.com/{Your_Organization}.

  2. Select gear icon Organization settings.

    Screenshot of Organization settings button, preview page.

  3. Select Policies, then toggle the desired policy on or off.

    Screenshot of policies list and their on and off toggles.

Restrict authentication methods

To allow seamless access to your organization without repeatedly prompting for user credentials, applications can use authentication methods, like OAuth, SSH, and personal access token (PATs). By default, all existing organizations allow access for all authentication methods.

You can limit access to these authentication methods by disabling the following application connection policies:

When you deny access to an authentication method, no application can access your organization through that method. Any application that previously had access encounter authentication errors and lose access.

Enforce Conditional Access policies

Microsoft Entra ID lets tenant admins control which users can access Microsoft resources using 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. Learn more about Conditional Access policies and how to set one up for Azure DevOps in the Microsoft Entra documentation.

Conditional Access policy support on Azure DevOps

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 our web authentication stack to use Microsoft Entra tokens, Azure DevOps now enforces Conditional Access policy validation on all interactive (web) flows.

  • Meet sign-in policies when using PATs on REST API calls that rely on Microsoft Entra.
  • Remove Azure DevOps as a resource from the Conditional Access policy, which prevents 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 policy, 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 (which can happen with VPN tunneling), review your VPN configuration or networking setup. Make sure your tenant administrator includes all relevant IP addresses in the Conditional Access policies.

Azure Resource Manager audience and Conditional Access policies

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 ARM audience during sign-in and token refresh flows. This requirement meant that administrators had to allow all Azure DevOps users to bypass ARM Conditional Access policies to ensure access.

Tokens for Azure DevOps no longer require the ARM audience. As a result, you can manage Conditional Access policies more effectively without configuring specific audience settings for ARM. This approach streamlines authentication, reduces token management complexity, and lets you apply security policies more consistently across your Azure environments. Organizations can focus on broader access controls, improving compliance and security posture without being limited by audience-specific configurations.

Note

There are the following exceptions where continued access to ARM is still required:

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

Policies by Level

Policy Org-level Tenant-level
Third-party application access via OAuth
SSH authentication
Log audit events
Restrict personal access token creation
Allow public projects
Additional protections when using public package registries
Enable IP Conditional Access policy validation on non-interactive flows
External guest access
Allow team and project administrators to invite new users
Request access allows users to request access to the organization with a provided internal URL
Allow Microsoft to collect feedback from users
Restrict organization creation
Restrict global personal access token creation
Restrict full-scoped personal access token creation
Enforce maximum personal access token lifespan