Is Azure DevOps Sign-ins Secure? Update Entra ID Conditional Access Policies Before the Deadline

Are You Making This Dangerous Mistake with Azure DevOps? How to Fix Your Conditional Access Policies Now.

If your company uses Microsoft Entra to manage who can access Azure DevOps, you need to pay close attention. A change is coming that could leave your projects exposed if you don’t act. Microsoft is changing how it protects your sign-ins. The old way will stop working soon. You need to update your security rules, called Conditional Access policies, to keep your work safe.

This is a simple change, but it is very important. Think of it like changing the lock on your front door. If you don’t use the new lock, the door is left open. This guide will walk you through everything you need to know. We will explain what is changing, why it’s happening, and exactly what you need to do.

The Old Method Is Being Retired

Right now, your security rules for Azure DevOps might be connected to a broader service called Azure Resource Manager (ARM). This was like using one master key for several different doors. Starting September 2, 2025, Microsoft will begin turning off this old connection for Azure DevOps. By September 18, 2025, this change will be complete for everyone.

After this date, Azure DevOps will no longer check the security rules you set for the ARM service. Instead, it will look for rules made specifically for Azure DevOps itself. This change is a good thing. It makes security more direct and stronger. It ensures that the rules you want for Azure DevOps are applied right at its own front door, not at a shared entrance down the hall.

The key takeaway is that if you were relying on security policies for the Windows Azure Service Management API (which has the App ID 797f4846-ba00-4fd7-ba43-dac1f8f63013), those rules will no longer protect Azure DevOps logins.

The Dangers of Inaction

Failing to update your policies is a serious risk. If you do nothing, you might create a security gap without even knowing it. Here’s what could happen:

• Unprotected Access: People might be able to log into your Azure DevOps without any security checks. This could expose your source code, project plans, and other sensitive data.
• Failed Security Measures: Important security rules may not work. This includes things like multi-factor authentication (MFA), which asks for a second form of proof that it’s really you. It also includes rules that require users to be on a company-approved, compliant device.
• Compliance Issues: Your organization might fall out of compliance with its own security standards or industry regulations. This could lead to failed audits and other serious consequences.

In short, the security you thought you had for Azure DevOps could disappear overnight. This is why it is so important to check and update your policies now.

How to Secure Your Azure DevOps Access

You need to make sure you have a Conditional Access policy that directly includes Azure DevOps. This is easier than it sounds. Here is a simple way to think about it and the steps to take.

Step 1: Check Your Current Policies

First, you need to see what rules you already have.

1. Go to the Microsoft Entra admin center.
2. Navigate to Protection > Conditional Access.
3. Look at your list of policies. Check any policies that apply to “All cloud apps” or that specifically target the old Windows Azure Service Management API (797f4846-ba00-4fd7-ba43-dac1f8f63013). These are the ones that need your attention.

Step 2: Update or Create a New Policy

If you find a policy that needs to be updated, or if you don’t have one that covers Azure DevOps, you need to make a change. The goal is to specifically add Azure DevOps to a policy.

Here’s how to create a new, secure policy:

1. In the Conditional Access section, click on Create new policy.
2. Give your policy a clear name, like “Azure DevOps – MFA and Compliant Device”.
3. Under Users, choose who this rule applies to. You can start with a small group of users to test it first.
4. Under Target resources > Cloud apps, select Select apps.
5. In the search box, type Azure DevOps. You will see it appear with its unique App ID: 499b84ac-1321-427f-aa17-267ca6975798. Select it and click Select.
6. Under Access controls > Grant, choose the security you want. For example, you can require multi-factor authentication and require the device to be marked as compliant.
7. Finally, turn the policy on by setting Enable policy to On. Then click Create.

By creating this rule, you are telling Microsoft Entra to enforce these security measures every time someone tries to sign into Azure DevOps.

Who Is Not Affected by This Change?

There is one group of administrators who may not need to do anything. If you already have a very broad Conditional Access policy that meets all the following conditions, you are likely already covered:

• The policy applies to All users.
• The policy applies to All cloud apps.
• The policy does not have an exclusion that specifically leaves out Azure DevOps.

In this situation, your wide-reaching security net already protects Azure DevOps sign-ins. However, it is still a very good idea to check your policies to be absolutely sure. Relying on broad rules can sometimes have unintended side effects, and a specific policy for a critical tool like Azure DevOps is a better practice.

How to Confirm Everything Is Working

After you have updated your policies, you should check to make sure they are working as expected. You can do this by using the Microsoft Entra ID sign-in logs.

• Look at the sign-in events for the Azure DevOps application.
• Check the Conditional Access tab in the details of a sign-in event. It will show you which policies were applied and whether they were successful.

To use Conditional Access, your organization will need Microsoft Entra ID P1 or P2 licenses. There is no difference in how this feature works between these two license types. This change is about pointing your existing security tools to the right place to keep your vital development environment secure.