Azure NSG rule cleanup: How to find and remove unused rules

To find and remove unused Azure NSG rules safely, start with the effective security rules applied across the relevant network interface, subnet, and applicable security-admin layers. Use Azure NSG resource logs, virtual network flow evidence, change records, and ownership information to identify no-hit, expired, duplicate, temporary, or overly broad candidates. Then validate each candidate against application dependencies, business cycles, and recovery paths before narrowing or deleting it through an approved change with rollback and post-change monitoring. Treat no recent traffic as a reason to investigate, not proof that deletion is safe.

The process becomes harder as Azure estates grow because the rule visible in one NSG may not represent the effective outcome. NSGs can be associated with a subnet, a network interface, or both; security-admin rules can add another policy layer; and ownership is often split across platform, cloud-security, network, and application teams. A rule that appears obsolete locally may still support a partner connection, maintenance window, or recovery path.

This is why mature teams treat cleanup as part of cloud network security policy management: the decision must connect the Azure configuration to the business purpose and the broader hybrid path.

The difference between an unused rule and an unattached NSG

An unattached NSG is an NSG object that is not currently associated with a subnet or network interface. An unused rule is different: it sits inside an associated NSG but appears not to match traffic during the observed period. The first is primarily an association and ownership question. The second requires rule-level evidence and application validation. A low-frequency payroll job, disaster-recovery route, or quarterly vendor process can appear inactive during a short review window and still be required.

Start with the effective security rules on the affected network interface. Azure aggregates rules from the NIC and its subnet, and the effective view also includes applicable security admin rules. Check direction, priority, protocol, ports, source, destination, service tags, and application security groups. Confirm whether another rule provides the same intended access or whether removing one rule changes the effective outcome.

Then examine traffic and operational context. A rule counter or flow record can show observed activity, but the observation window must cover business cycles, maintenance, failover tests, seasonal demand, and low-frequency integrations. Find the owner and the original request. Review exceptions, planned migrations, incident procedures, and application dependencies. Application connectivity management is especially useful here because the rule should be evaluated as part of a required communication path, not as an isolated line of configuration.

Consider a temporary inbound rule created for a partner implementation. It has no hits during the last 30 days, and the project ticket is closed. That combination makes it a strong candidate, but the final decision still depends on whether the partner performs a quarterly data transfer, whether a replacement path is live, and whether the source range or service tag changed after the rule was created. The safer action may be deletion, a narrower rule, a documented exception with an expiration date, or a longer observation period. The evidence should drive that choice.

1. Scope the review: Choose subscriptions, resource groups, applications, environments, and an observation period that reflects real operating cycles.

2. Build the inventory: Record NSGs, associations, custom rules, priorities, directions, service tags, application security groups, owners, and recent changes.

3. Classify candidates: Separate unattached NSGs from no-hit, duplicate, redundant, temporary, expired, and overly broad rules. Each category needs different evidence.

4. Collect multiple signals: Combine effective rules, NSG diagnostics, flow or resource logs, posture recommendations, change records, and application information.

5. Validate the business need: Ask application and service owners to confirm expected traffic, recovery dependencies, exceptions, and upcoming changes.

6. Approve and stage the change: Use a scoped change request, testing plan, maintenance window, and rollback path. Avoid modifying several related controls at once.

7. Monitor and document: Check connectivity and telemetry after implementation, record the outcome, and retain the decision evidence for future reviews and audits.

This workflow turns policy cleanup and optimization into a repeatable lifecycle rather than an occasional deletion exercise.

Prioritization matters, too. Start with candidates that have a clear owner, strong evidence, limited blast radius, and a straightforward rollback. Keep ambiguous rules in a review queue with an assigned owner and next decision date. This prevents a cleanup campaign from stalling because a few difficult cases are mixed with changes that are ready to proceed.

• Deleting a rule because it has no recent hits, without checking the length and coverage of the observation window

• Reviewing an NSG in isolation instead of checking effective rules across subnet, NIC, and applicable admin-rule layers

• Treating an unattached NSG and an inactive rule as the same type of finding

• Changing several controls in one window, making impact and rollback difficult to isolate

• Trying to delete Azure default security rules instead of reviewing custom rules and effective behavior

• Following outdated instructions that recommend creating new NSG flow logs

• Closing the change without monitoring results or retaining approval and validation evidence

A governed process for security policy changes reduces these handoff gaps by keeping scope, approval, testing, rollback, and evidence connected.

Within the AlgoSec Horizon platform, Horizon ACE centralizes Azure NSG policy visibility across subscriptions, regions, and VNets. It can identify unused rules using Azure NSG resource-log activity, show when a rule was last used, surface risky rules and affected assets, and allow authorized teams to edit or delete rules and commit the changes to Azure.

Across Horizon, application context and governed change workflows help teams determine which business service depends on the access, involve the accountable owner, implement the smallest justified change, and retain evidence of the decision and result. For higher-impact remediation, Horizon FireFlow can support the change lifecycle from planning and risk analysis through implementation and validation. This helps reduce policy bloat and unnecessary exposure without treating a no-hit finding as proof that a rule is safe to remove.

How can you tell whether an Azure NSG rule is unused?

Look for little or no observed traffic across a representative period, then validate the effective rule set, application dependencies, owner, business cycle, exceptions, and recovery use. Inactivity makes a rule a candidate for review; it does not make deletion automatically safe.

What is the difference between an unused rule and an unattached NSG?

An unattached NSG is not associated with a subnet or network interface. An unused rule belongs to an associated NSG but appears not to match traffic. The former needs association and ownership validation; the latter needs deeper rule, traffic, and application analysis.

What changes now that NSG flow logs are being retired?

Do not build a new cleanup process around NSG flow logs. Plan for virtual network flow logs and combine them with effective rules, diagnostics, resource logs, application context, and change evidence. Existing deployments should follow Microsoft’s migration guidance before September 30, 2027.

Ready to make cloud policy cleanup more application-aware? Schedule a demo to see how AlgoSec Horizon supports policy visibility and governed change across hybrid environments.