🚨 Azure Error: 'InUseNetworkSecurityGroupCannotBeDeleted' — Cause, Fix, and Troubleshooting Guide

What this error means

Azure refuses to delete a network security group while anything still references it. The InUseNetworkSecurityGroupCannotBeDeleted error means the NSG is currently associated with at least one subnet or network interface, and Azure will not orphan those associations. The literal message enumerates the references:

{
  "code": "InUseNetworkSecurityGroupCannotBeDeleted",
  "message": "Network security group /subscriptions/1111.../resourceGroups/net-rg/providers/Microsoft.Network/networkSecurityGroups/app-nsg cannot be deleted because it is in use by the following resources: /subscriptions/1111.../resourceGroups/net-rg/providers/Microsoft.Network/virtualNetworks/app-vnet/subnets/web-subnet. In order to delete the network security group, remove the association with the resource(s).",
  "details": []
}

The message lists the exact subnet and/or NIC ids holding the reference — the fix is to dissociate every one of them and then retry the delete.

What users report

• az network nsg delete or an IaC destroy fails with InUseNetworkSecurityGroupCannotBeDeleted.
• The message lists one or more subnet or networkInterfaces resource ids.
• A terraform destroy hangs or errors on the NSG resource while dependent resources are still present.
• Deleting a resource group that contains the NSG stalls because the NSG cannot be removed in the current ordering.

Tenant and app configuration causes

• Subnet association — the NSG is attached to a subnet (subnet.networkSecurityGroup), the most common reference and easy to miss because the subnet lives on the VNet, not the NSG.
• NIC association — one or more network interfaces have the NSG set directly on networkInterface.networkSecurityGroup.
• Stale references after partial cleanup — the VM/NIC was deleted but the NIC lingered, or the subnet was recreated with the NSG re-attached by IaC.
• IaC ordering — Terraform/Bicep tries to delete the NSG before removing the subnet association it also manages, or a subnet association resource is managed separately and not torn down first.

Confirming tenant configuration

Ask the NSG directly which subnets and NICs reference it — the API returns both collections:

az network nsg show \
  --resource-group net-rg --name app-nsg \
  --query "{subnets:subnets[].id, nics:networkInterfaces[].id}" -o json

If you only have the error text, parse the ids it listed. To confirm a subnet reference:

az network vnet subnet show \
  --resource-group net-rg --vnet-name app-vnet --name web-subnet \
  --query "networkSecurityGroup.id" -o tsv

And to find any NIC still pointing at the NSG:

az network nic list \
  --query "[?networkSecurityGroup.id!=null && contains(networkSecurityGroup.id,'app-nsg')].{Name:name, RG:resourceGroup}" \
  -o table

Resolution

Dissociate from the subnet by clearing the NSG reference (the --remove clears the property):

az network vnet subnet update \
  --resource-group net-rg --vnet-name app-vnet --name web-subnet \
  --network-security-group ""

Dissociate from each NIC:

az network nic update \
  --resource-group net-rg --name app-nic-01 \
  --network-security-group ""

Then delete the NSG once no references remain:

az network nsg delete --resource-group net-rg --name app-nsg

For Terraform, ensure the subnet-to-NSG association is its own azurerm_subnet_network_security_group_association resource (or that the subnet block no longer sets the NSG) so destroy removes the association before the NSG. Re-run terraform destroy after correcting the ordering.

Avoiding tenant drift

• Subnet references hide on the VNet. The NSG’s subnets list is the fastest source of truth — start there, because a subnet association is easy to overlook when you are looking at NICs.
• Recreated subnets re-attach the NSG. If IaC recreates a subnet with the NSG inline, the association comes right back; move it to an explicit association resource to control teardown order.
• Flow logs and diagnostic settings. An NSG with flow logs enabled may need the flow log resource removed first in some configurations — check if a delete still fails after dissociation.
• Don’t force-delete the resource group. Deleting the whole RG to sidestep the ordering can remove more than intended; dissociate cleanly instead.

Related tenant errors

• NicInUse — the same “still attached” pattern for network interfaces.
• InUseSubnetCannotBeDeleted — a subnet cannot be deleted while resources (including this NSG) reference it.
• SubnetIsFull — another subnet lifecycle error worth knowing when reworking a VNet.