Restrict Microsoft Azure Access to a Specific IP Address Using Conditional Access

Overview

This article walks through restricting Microsoft Azure access to one or more approved IP 
addresses using Conditional Access in Microsoft Entra ID. This is commonly used to ensure 
that the Azure portal, Azure CLI, and Azure Resource Manager API can only be accessed 
from a corporate network, reducing the risk of unauthorized cloud resource access or 
configuration changes from untrusted locations.

The approach uses two components working together: 

• Named Locations:  A saved list of trusted IP addresses or CIDR ranges defined in 
  Entra ID. 
• Conditional Access policy:  a policy that blocks Azure management access originating 
  from any IP not on the trusted list. 

Choosing the Right Target Application

Important: Windows Azure Service Management API does not cover Azure DevOps. This is a separate service with its own Conditional Access app. If you need to restrict Azure DevOps access by IP, a separate policy targeting the Azure DevOps app is required. Additionally, this policy applies to the Azure management plane only. Access to worklaods running inside Azure (virtual machines, web apps, databases, etc.) is not controlled by this policy.

Prerequisites

Before proceeding, confirm the following are in place:

• Microsoft Entra ID P1 or P2 license - required for Conditional Access.
• Conditional Access Administrator role or higher in Microsoft Entra ID.
• Security Defaults Disabled in Entra ID - Security Defaults and Conditional Access cannot run simultaneously.
• Known static IP address -  the public IP address or CIDR range of each approved location.
• Break-glass admin account -  must be excluded from this policy to prevent administrative lockout.

Important: This policy restricts access to the Azure management plane for all users in scope, including administrators. A misconfigured or prematurely enabled policy can lock all administrators out of the Azure portal and CLI simultaneously. The break-glass account exclusion is not optional — it is critical.

Step 1: Create a Named Location for Your Trusted IP(s)

A Named Location defines the trusted IP addresses that Entra ID will reference as a condition in the policy.

1. Sign in to the Microsoft Entra admin center at entra.microsoft.com
2. Navigate to Protection > Conditional Access > Named locations.
3. Select + IP ranges locations.
4. Name the location. For example: Trusted - Corporate Office
5. Check the Mark as trusted location checkbox.
6. Click + and enter your approved IP address or CIDR range. 

7.  Click Create.

Step 2: Create the Conditional Access Policy

Create a policy that blocks DocuSign access from any location not on your trusted list.

1. In the Entra admin center, navigate to Protection > Conditional Access > Policies.
2. Select + New policy.
3. Name the policy. For example, Block Azure Management - Outside Trusted IPs

Assignments: Users

1. Under Assignments > Users, select All users.
2. Under Exclude, add your break-glass admin account. Also consider excluding any automation service principals or managed identities that access Azure Resource Manager from dynamic IPs.

Assignments: Target Resources

1. Under Target Resources, select Cloud apps > Select apps.
2. Search for and select Windows Azure Service Management API.
3. Optionally, also add Microsoft Admin Portals if you want to restrict access to the Entra admin center, Microsoft 365 admin center, and Intune admin center by the same IP rule.

Please Note:  Windows Azure Service Management API and Microsoft Admin Portals can be added to the same policy. However, if you need different IP rules for Azure management versus admin portals, create two separate policies, one targeting each app.

Conditions: Locations

1. Under Conditions > Locations, set Configure to Yes.
2. Under Include, select Any location.
3. Under Exclude, select Selected locations, then choose the Named Location you created in Step 1.

Tip: This configuration reads: apply this policy to sign-ins from any location, 
except the trusted named location. Any Azure portal, CLI, or ARM API access originating outside the trusted IP will be blocked by the grant control below.

Access Controls: Grant

1. Under Access Controls > Grant, select Block access.
2. Click Select to confirm.

Enable Policy

1. Set Enable policy to Report-only.
2. Click Create.

Important: Do not set this policy to On immediately. A block policy targeting Azure management applied to All users will prevent all administrators from accessing the Azure portal, CLI, and ARM API from any untristed IP. Always validate thoroughly in Report-only mode before enabling enforcement.

Step 3: Validate the Policy

Before enabling enforcement, confirm the policy is evaluating sign-ins correctly.

1. In the Entra admin center, navigate to Identity > Monitoring & health > Sign-in logs. 
2. Filter by the Windows Azure Service Management API application.
3. Open a sign-in from a user on your trusted IP and confirm the Conditional Access 
tab shows Would succeed. 
4. Identify any sign-ins from automation tools, pipelines, or scripts that access ARM from IPs not in your Named Location. These will show as Would fail and must be excluded before enforcement.
5. Once all expected sign-in patterns show as Would succeed and unexpected ones show as Would fail, proceed to Step 4.

Tip:  Use the What If tool under Protection > Conditional Access to simulate how a specific user signing in from a specific IP would be evaluated without waiting for a real sign-in event.

Step 4: Enable the Policy

1. In the Entra admin center, navigate to Protection > Conditional Access > Policies.
2. Select the policy created in Step 2.
3. Change Enable policy from Report-only to On.
4. Click Save.

From this point forward, any Azure portal, CLI, or ARM API access attempt from an IP address not included in your Named Location will be blocked at authentication. Users will receive an access denied message and will not be able to manage Azure resources from untrusted IPs.

Please Note: Existing Azure portal sessions at the time of policy enablement will not be immediately terminated. The block takes effect on the next sign-in or token refresh, typically within 1 hour. Users with active CLI sessions using cached tokens may retain access until their token expires.

Summary

The following table summarizes the full configuration process.