6.1.4. Virtual Network Manager Security Admin Rules
An NSG belongs to whoever owns the subnet, which is exactly the problem when a central security team needs a rule that an application team cannot switch off. Security admin rules, delivered by Azure Virtual Network Manager, are evaluated before NSG rules and cannot be overridden from below.
| Security admin rules | NSG rules | |
|---|---|---|
| Written by | Central network or security admins | Individual application teams |
| Applied at | Virtual network level | Subnet or NIC level |
| Evaluation order | First | After security admin rules |
| Actions | Allow, Deny, Always Allow | Allow, Deny |
The three actions are the whole topic:
- Allow — permits the traffic here, then still hands it to the NSG, which may go on to deny it. This is a floor, not a guarantee.
- Always Allow — permits the traffic and stops evaluation. No NSG below can block it.
- Deny — blocks the traffic and stops evaluation. No NSG below can permit it.
⚠️ Exam Trap: Allow and Always Allow look interchangeable and are not. If the requirement is "application teams must not be able to block this traffic", only Always Allow satisfies it — a plain Allow leaves the final say with the NSG.
Priority runs from 1 to 4096 and lower numbers win, the same direction as NSG priorities.
Where they do not apply — worth knowing because the exception list is a favourite distractor. Security admin rules skip virtual networks containing Azure SQL Managed Instance or Azure Databricks, and skip subnets containing Application Gateway, Azure Bastion, Azure Firewall, Route Server, VPN Gateway, Virtual WAN or an ExpressRoute gateway. They also do not currently apply to private endpoints.
💡 First Principle: NSGs answer "what does this team allow into its own subnet?". Security admin rules answer "what does the organisation permit anywhere, regardless of what a team configures?" Reach for them whenever a question contains the words organisation-wide, cannot be overridden, or all current and future virtual networks.
