Restricting Azure Resource Operations by IP After Azure Portal Authentication

Question

Restricting Azure Resource Operations by IP After Azure Portal Authentication

U R 20

It is possible to restrict IP addresses before authentication by using Conditional Access policies.

In this context, we would like to know whether it is possible to restrict resource operations by IP address after authentication (after logging in to the Azure Portal).

Is this possible?

Or is the only option to configure IP restrictions on the resource side through network settings? Alternatively, is it possible to implement this using Azure Policy?

Rukmini 35,655 Reputation points Microsoft External Staff Moderator

2026-03-17T00:29:36.8766667+00:00
Hey there! Once you’re signed into the Azure Portal, there isn’t a built-in mechanism to block or allow specific IP addresses for management-plane operations (that is, clicking around in the Portal or using ARM APIs)—Conditional Access handles the sign-in itself, but after you’re authenticated, those requests aren’t filtered by source IP.

What you can do is lock down the data-plane (the actual resource endpoints) by forcing every resource to live behind IP-based network restrictions. For example:

• App Service

– Use Access Restrictions to build an allow/deny list of IPv4, IPv6 or VNet subnets

– You get an implicit “deny all” when you have any rule defined

– Supports multi-source rules (up to eight IP ranges or service tags in one rule)

– Diagnostic logs show every matched allow or deny rule

(See “Access Restrictions overview” and “Set up Azure App Service access restrictions” below)

• Storage, Key Vault, Cosmos DB, etc.

– Each of these services has a “firewall/network rules” section where you can whitelist IPs or subnets

– You can disable public access entirely and require requests to come from allowed networks

To make sure every new or existing resource actually has those network rules in place, you can use Azure Policy. There are built-in or DeployIfNotExists policies that:

Audit any resource missing its firewall/networkRules configuration

Automatically deploy default deny/allow rules when a resource is created

That way you get a guardrail—anybody who spins up a new storage account (or App Service, or Key Vault, …) is forced to include the IP restrictions you define.

Key takeaway:

– You cannot natively block Portal/ARM calls by IP once someone’s logged in.

– You must rely on each resource’s network-level firewall (NSG, service endpoints, Private Endpoint, built-in IP restrictions).

– You can use Azure Policy to enforce or audit those firewall settings.

Hope that clears things up! If you let me know which specific resource types you’re targeting (App Service vs. Storage vs. Key Vault vs. Cosmos DB, etc.), I can point you at the exact policy definitions or CLI/PowerShell snippets.

Reference list

Access restrictions overview (App Service) https://learn.microsoft.com/azure/app-service/overview-access-restrictions

Set up Azure App Service access restrictions (IP and multi-source rules) https://docs.microsoft.com/azure/app-service/app-service-ip-restrictions

Virtual network service endpoints overview https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/virtual-network/virtual-network-service-endpoints-overview.md

Diagnostic logging for IP restrictions (App Service) https://learn.microsoft.com/azure/app-service/overview-access-restrictions#diagnostic-logging

Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.
U R 20 Reputation points

2026-03-17T04:21:58.3933333+00:00

Hi **Rukmini
**
Thank you for your response.

Is it possible to use Azure Policy to prevent users connecting from IP addresses other than specific allowed IP addresses from creating resources?

If it is possible, I would like to understand that resource operations can be controlled by IP address not only through resource network settings, but also through Azure Policy.
Rukmini 35,655 Reputation points Microsoft External Staff Moderator

2026-03-17T16:15:23.75+00:00
Hello U R

No, Azure Policy cannot be used to limit or stop the creation of resources based on the source IP address of the user.

Azure Policy does not have access to request context, such as the caller's IP address or network location; it simply assesses resource configurations and attributes. As a result, IP-based requirements for management-plane operations (such as resource creation or modification) cannot be enforced.

IP-based control can be obtained by using:

Conditional Access in Microsoft Entra ID → to restrict access at sign-in time based on IP

Network constraints at the resource level (such as firewalls and private endpoints) → to manage data-plane access

Azure Policy → only to enforce that such network restrictions are configured, not to evaluate IP itself

Resource operations cannot be managed by IP address using Azure Policy. Only the resource/network and authentication layers (Conditional Access) enable IP-based limitations; Azure Policy does not.

Let me know if any further queries - feel free to reach out!
Rukmini 35,655 Reputation points Microsoft External Staff Moderator

2026-03-18T19:03:07.33+00:00

Hello U R Following up to see if the above provided information was helpful. If you have any further queries do let us know.
Rukmini 35,655 Reputation points Microsoft External Staff Moderator

2026-03-25T19:31:59.9666667+00:00

Hello U R Following up to see if the above provided information was helpful. If you have any further queries do let us know.

1 answer

Your answer

U R 20 Reputation points

2026-03-17T04:21:58.3933333+00:00

Hi **Rukmini
**
Thank you for your response.

Is it possible to use Azure Policy to prevent users connecting from IP addresses other than specific allowed IP addresses from creating resources?

If it is possible, I would like to understand that resource operations can be controlled by IP address not only through resource network settings, but also through Azure Policy.
Rukmini 35,655 Reputation points Microsoft External Staff Moderator

2026-03-17T16:15:23.75+00:00

Hello U R

No, Azure Policy cannot be used to limit or stop the creation of resources based on the source IP address of the user.

Azure Policy does not have access to request context, such as the caller's IP address or network location; it simply assesses resource configurations and attributes. As a result, IP-based requirements for management-plane operations (such as resource creation or modification) cannot be enforced.

IP-based control can be obtained by using:

Conditional Access in Microsoft Entra ID → to restrict access at sign-in time based on IP

Network constraints at the resource level (such as firewalls and private endpoints) → to manage data-plane access

Azure Policy → only to enforce that such network restrictions are configured, not to evaluate IP itself

Resource operations cannot be managed by IP address using Azure Policy. Only the resource/network and authentication layers (Conditional Access) enable IP-based limitations; Azure Policy does not.

Let me know if any further queries - feel free to reach out!
Rukmini 35,655 Reputation points Microsoft External Staff Moderator

2026-03-18T19:03:07.33+00:00

Hello U R Following up to see if the above provided information was helpful. If you have any further queries do let us know.
Rukmini 35,655 Reputation points Microsoft External Staff Moderator

2026-03-25T19:31:59.9666667+00:00

Hello U R Following up to see if the above provided information was helpful. If you have any further queries do let us know.

Answer 1

Conditional Access can already evaluate IP/location both at initial sign-in and on refresh-token use, so it is the built‑in way to restrict access to Azure management endpoints (Azure portal, ARM, CLI, PowerShell) by IP at and after authentication.

Specifically:

Conditional Access policies can be applied to the Azure management “cloud apps” (Azure portal, Azure Resource Manager APIs, Azure PowerShell, Azure CLI, etc.) and can require that users access them only from approved locations (IP ranges) and/or require MFA or compliant devices.
Location conditions are evaluated when the user signs in and again when a refresh token is used to get a new access token (by default about once an hour). This means a change in client IP is detected and enforced during the session lifecycle, not only at the very first sign‑in.

However:

Conditional Access evaluates authentication and token issuance, not individual resource data‑plane operations.
For data‑plane or resource‑specific traffic (for example, Cosmos DB, storage, app backends), IP restrictions must be implemented on the resource side (firewalls, virtual networks, WAF rules, etc.).
Azure Policy is for governance/compliance of resource configuration (for example, enforcing that certain network/firewall settings are present), not for per‑request IP filtering at runtime.

So, to restrict operations by IP after portal login:

Use Microsoft Entra Conditional Access to restrict and condition access to Azure management endpoints by IP/location (and other signals) across the session.
Use each resource’s own network/firewall features (IP firewall, VNet integration, WAF IP rules, etc.) to restrict data‑plane access.
Use Azure Policy only to enforce that those network/firewall configurations are in place, not as a runtime IP filter.

References:

Share via

Restricting Azure Resource Operations by IP After Azure Portal Authentication

1 answer

Your answer