8.3 Azure Virtual Network Manager Security Admin Rules
Key Takeaways
- Security admin rules are global rules applied at the virtual network level through network groups, whereas NSGs are applied at the subnet and NIC level, and security admin rules are always evaluated first.
- The three actions are Allow, which is non-terminating and hands evaluation on to NSGs, Always Allow, which terminates evaluation and cannot be overridden by an NSG, and Deny, which terminates evaluation and drops the traffic.
- Security admin rule priority is an integer from 1 to 4,096 where a lower number wins, and supported protocols are TCP, UDP, ICMP, ESP, AH, and Any.
- Only one security admin configuration can be deployed to a region; to apply multiple policy sets in a region you add multiple rule collections inside a single configuration.
- Security admin rules are skipped at the virtual network level for Azure SQL Managed Instance and Azure Databricks, and at the subnet level for Application Gateway, Bastion, Azure Firewall, Route Server, VPN Gateway, Virtual WAN, and ExpressRoute gateway subnets.
Azure Virtual Network Manager Security Admin Rules
Network security groups are owned by whoever owns the subnet or the NIC. That is a feature when application teams need autonomy, and a liability when a central security team must guarantee that port 3389 is never exposed to the internet anywhere in the estate. Security admin rules in Azure Virtual Network Manager (AVNM) close that gap: they are global rules, written once by the network governance team, that apply to every virtual network in a targeted network group — and they cannot be overridden by a team's own NSG.
1. Security Admin Rules vs. Network Security Groups
| Dimension | Security admin rules | NSG rules |
|---|---|---|
| Audience | Network admins, central governance team | Individual application or service teams |
| Applied on | Virtual networks (via network groups) | Subnets and NICs |
| Evaluation order | Higher priority — evaluated first | Lower priority — evaluated after |
| Actions | Allow, Deny, Always Allow | Allow, Deny |
| Parameters | Priority, protocol, action, source, destination | Priority, protocol, action, source, destination |
The division of labour is the point: the governance team sets a floor that application teams cannot drill through, and application teams still tighten their own subnets on top of it.
[!IMPORTANT] Security admin rules do not depend on NSGs existing. They function as default security rules on their own, which is what makes them effective against the most common real-world failure — an application owner who never created an NSG at all.
2. The Three Actions and Their Terminating Behaviour
This is the highest-value fact in the objective.
| Action | Effect | Terminating? | NSGs still evaluated? |
|---|---|---|---|
| Allow | Permits the traffic on the specified port, protocol, direction, and prefixes | No | Yes — the NSG can still deny it |
| Always Allow | Permits the traffic regardless of lower-priority rules or user-defined NSGs | Yes | No — evaluation stops, traffic goes to the resource |
| Deny | Blocks the traffic; it is never delivered | Yes | No |
Reading the difference correctly
- Allow is deliberately permissive-but-not-final. Use it when the central team wants to permit a flow but leave application teams free to restrict it further.
- Always Allow is the override. Use it for a flow that must survive a misconfigured or overly aggressive NSG — a monitoring agent, a domain controller path, a health-check source.
- Deny is the guardrail. It stops the traffic before an NSG is ever consulted, so no application team can accidentally re-open the port.
[!NOTE] Eventual consistency. Security admin rules are applied to resources in a virtual network after a short delay, and new resources added to a covered virtual network receive the rules with the same delay. A VM created seconds ago may briefly not yet be governed.
3. Rule Fields
| Field | Rule |
|---|---|
| Priority | Integer 1 to 4,096; lower value = higher priority. A Deny at priority 10 overrides an Allow at priority 20 |
| Action | Allow, Deny, or Always Allow |
| Direction | Inbound or Outbound |
| Protocol | TCP, UDP, ICMP, ESP, AH, or Any |
| Source / destination types (optional) | IPv4 or IPv6 addresses and CIDR blocks (comma-separated for multiples), or service tags |
| Ports (optional) | Specific source or destination ports |
Service tags are supported, with three documented exceptions that security admin rules do not support: AzurePlatformDNS, AzurePlatformIMDS, and AzurePlatformLKM.
Deployment constraint
You can deploy only one security admin configuration to a region, although multiple connectivity configurations can coexist in the same region. To apply what feels like several policies in one region, create multiple rule collections inside a single security configuration.
4. High-Risk Ports Microsoft Recommends Blocking
Microsoft publishes a list of ports that should not be exposed to the internet and that make a natural first security admin configuration.
| Port(s) | Protocol | Why it is high risk |
|---|---|---|
| 20, 21 | TCP | Unencrypted FTP |
| 22 | TCP | SSH — brute-force target |
| 23 | TCP | Telnet — unauthenticated, unencrypted |
| 69 | UDP | TFTP — unauthenticated, unencrypted |
| 111, 135, 593 | TCP/UDP | RPC and endpoint mapper services |
| 161, 162 | TCP/UDP | SNMP and SNMP trap — weak or absent authentication |
| 445 | TCP | SMB — a well-known attack vector |
| 512, 514 | TCP | Rexec and remote shell — unauthenticated remote commands |
| 873 | TCP | Rsync — unencrypted file transfer |
| 2049 | TCP/UDP | Network File System |
| 3389 | TCP | RDP — common brute-force target |
| 5800, 5900 | TCP | VNC remote frame buffer |
| 11211 | UDP | Memcached |
Where a specific virtual network legitimately needs one of these ports, you create an exception rather than weakening the global rule.
5. Where Security Admin Rules Do Not Apply
Some services enforce their own network intent policies, so AVNM skips them. Knowing this list prevents you from choosing a security admin rule as the answer to a problem it cannot solve.
Skipped at the virtual network level
A virtual network containing either of these services is skipped entirely:
- Azure SQL Managed Instance
- Azure Databricks
You can request an exemption via a Microsoft form. Alternatively, set AllowRulesOnly in the configuration's applyOnNetworkIntentPolicyBasedServices property so that only Allow rules are applied to such virtual networks — Deny rules are not applied. When several network manager instances set different values for the same virtual network, the setting from the manager with the highest scope wins.
Skipped at the subnet level
Subnets hosting these services are skipped, while other subnets in the same virtual network are still governed:
- Azure Application Gateway
- Azure Bastion
- Azure Firewall
- Azure Route Server
- Azure VPN Gateway
- Azure Virtual WAN
- Azure ExpressRoute Gateway
Application Gateway is the one exception with an exception: security admin rules can be applied to an Application Gateway subnet if every gateway in that subnet is provisioned with network isolation enabled.
[!NOTE] Security admin rules also do not currently apply to private endpoints that fall under the scope of a managed virtual network.
A central security team deploys an Azure Virtual Network Manager security admin configuration containing a rule that denies inbound TCP 3389 from the Internet service tag at priority 100. An application team insists their jump host must remain reachable over RDP and creates an NSG rule at priority 100 allowing TCP 3389 inbound from their office IP range. What happens to the RDP traffic?
An enterprise applies a security admin configuration to a network group that includes a virtual network hosting an Azure SQL Managed Instance, and another virtual network containing a subnet with an Azure Firewall. After deployment they observe that neither the managed instance virtual network nor the Azure Firewall subnet is governed. Which explanation is correct?