How to restrict Microsoft Azure access to specific IP addresses using Conditional Access

Many organizations use Microsoft Azure to build, host, and scale applications and infrastructure without the need for on-premises hardware. Azure supports cloud hosting, data storage, analytics, virtual desktops, and more.

Because it hosts critical systems like virtual machines, cloud infrastructure, and business data, it is crucial to implement layered security controls such as multi-factor authentication and role-based access.  

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.

Why it’s important to restrict Azure access to specific IP addresses

Restricting Azure management access by IP address is a critical control for securing cloud environments and preventing unauthorized administrative activity.

Key benefits include:

• Prevent unauthorized changes to cloud resources
• Protect critical infrastructure and configurations
• Reduce risk from compromised credentials
• Strengthen Zero Trust security posture
• Maintain compliance with security standards

As outlined in the article, this approach ensures Azure management access is limited to trusted locations, reducing the risk of unauthorized access or configuration changes from untrusted IPs.

Step-by-step: How to restrict Microsoft Azure access to specific IP addresses using Conditional Access

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

Unlike third-party SaaS apps, Azure does not have a single enterprise application to target. The correct app depends on what you want to restrict. Review the table below before creating your policy.

IMPORTANT: Windows Azure Service Management API does not cover Azure DevOps. That 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 workloads 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 — 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 permanent administrative lockout of your Azure environment.

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 critical and not optional.

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 location.
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. Examples:
   • Single IP address: 203.0.113.10/32
   • IP range (CIDR): 203.0.113.0/24
   • Multiple sites: Create a separate Named Location for each site, then reference all of them in the policy.
7. Click Create.

Step 2: Create the Conditional Access policy

Create a policy that blocks Azure management 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.

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 your Named Location from 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 untrusted 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. This step is especially important for Azure management due to the breadth of access it controls.

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 an administrator 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 or service account 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.

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 one hour. Users with active CLI sessions using cached tokens may retain access until their token expires.

Summary

The following summarizes the full configuration process:

Prerequisites

Confirm license, Security Defaults disabled, break-glass account identified, static IP(s) confirmed

Step 1

Create a Named Location with your trusted IP address(es) in Entra ID

Step 2

Create a CA policy targeting Windows Azure Service Management API, excluding the Named Location, with Block access

Step 3

Validate in Report-only mode — pay particular attention to automation and pipeline sign-ins

Step 4

Switch Enable policy to On

FAQs 

What Azure services does this policy restrict? 
This policy restricts access to the Azure management plane, including the Azure portal (portal.azure.com), Azure CLI, Azure PowerShell, and Azure Resource Manager (ARM) API. 

Does this restrict access to applications running in Azure? 
No. This policy does not affect workloads such as virtual machines, web apps, or databases. It only controls administrative access to Azure resources. 

Which application should I target in Conditional Access? 
You should target Windows Azure Service Management API to cover Azure portal, CLI, and ARM API access. Optionally, add Microsoft Admin Portals if you also want to restrict access to admin centers like Entra ID and Microsoft 365. 

Does this include Azure DevOps? 
No. Azure DevOps is a separate service with its own Conditional Access application. You must create a separate policy if you want to restrict it. 

Why is a break-glass account required? 
Because this policy can block all administrative access, a break-glass account ensures you can still access Azure if the policy is misconfigured. It is a critical safeguard, not optional. 

Can this work with dynamic IP addresses? 
No. This configuration requires static IP addresses. Dynamic IPs will lead to unreliable enforcement. 

What is a Named Location? 
A Named Location is a list of trusted IP addresses or CIDR ranges defined in Microsoft Entra ID and used as a condition in Conditional Access policies. 

Why should I use Report-only mode first? 
Report-only mode allows you to validate policy behavior safely before enforcing it, helping prevent accidental lockouts of administrators. 

What should I check during validation? 
Pay special attention to automation tools, scripts, pipelines, and service principals. These often run from external or dynamic IPs and may require exclusion before enabling the policy. 

Will this immediately terminate existing Azure sessions? 
No. Existing sessions (portal or CLI) are not immediately terminated. The policy takes effect on the next sign-in or token refresh, typically within about one hour. 

What happens if the policy is misconfigured and enabled? 
Because this policy affects all Azure management access, a misconfiguration can lock all administrators out of the Azure portal, CLI, and APIs simultaneously. This is why validation in Report-only mode and excluding a break-glass account are critical.