Network security groups attached to no subnet and no network interface
What does ZopNight detect here?
Azure network security groups only filter traffic once they are associated with a subnet or a NIC. ZopNight flags an NSG whose `subnets` and `networkInterfaces` associations are both empty, meaning its rules protect nothing, and reports it as a $0 governance cleanup rather than a cost saving.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1361 |
| Category | orphan |
| Severity | low |
| Metric | none — pure configuration read |
| Threshold | no subnet or NIC association |
| Source | ZopNight |
| Permissions used | Microsoft.Network/networkSecurityGroups/read |
Where it applies
An NSG that guards nothing
A network security group is a list of allow and deny rules. It does nothing until it is associated: the Azure virtual network FAQ explains that you can apply NSGs to individual subnets, to NICs attached to a virtual network, or to both. An NSG with neither kind of association filters no traffic at all.
Orphaned NSGs pile up when VMs and their NICs are deleted but the NSG is not, when subnets are rebuilt, or when a template creates one per VM. ZopNight prices them at $0, but they add noise to every audit and every rule review, and an old NSG with permissive rules can be reattached by mistake.
Listing unassociated NSGs
An NSG’s subnets and networkInterfaces properties list what it is attached to. Filter for NSGs
where both are empty, then inspect a candidate:
az network nsg list \ --query "[?subnets==null && networkInterfaces==null].{name:name, group:resourceGroup, location:location}" -o table
az network nsg show --resource-group <rg> --name <nsg> \ --query "{subnets:subnets, nics:networkInterfaces, rules:securityRules[].name}"How ZopNight decides an NSG is unattached
ZopNight reads the NSG’s own association properties when it scans the subscription and records whether the group is linked to any subnet or NIC. The rule fires only when that record says, explicitly, that it is linked to neither. There is no metric, threshold or lookback window: this is a configuration check repeated on every evaluation. Customer tags named “associated” are ignored, since a tag is not proof of anything.
When nothing is reported
If the association state could not be read, the NSG is left alone; unknown is never treated as unattached. An NSG attached to even one subnet or one NIC is in use and is not flagged. Rules that are dangerously open on NSGs that are in use are a separate problem, covered by Azure NSG Open to Internet.
A hygiene finding with no dollar figure
The finding always shows a $0 current cost and a $0 saving. ZopNight never reads a price for it, so it cannot invent one. The value is operational: fewer stale rule sets, cleaner audits, and one less object that could be attached to the wrong subnet with rules nobody remembers writing.
Cleaning up an orphaned NSG
- Check whether the NSG was meant to protect a subnet or NIC that exists today. If so, associate
it, for example with
az network vnet subnet update --network-security-group <nsg>. - Review its security rules for anything worth keeping in another NSG.
- If it is truly unused, delete it:
az network nsg delete --resource-group <rg> --name <nsg>. - If your team keeps some unassociated NSGs on purpose, record why in a tag so reviewers know.