How do you detect Azure network security group changes?

Detect Azure network security group changes by watching Azure activity logs for security rule create, update, and delete operations on NSGs and their associated subnets or network interfaces. Alert on newly opened inbound access, priority changes, and removals of restrictive rules. Investigate whether the change was authorised, then verify effective rules and exposed services.

What counts as an Azure network security group change?

An NSG change is any modification that affects how Azure permits or denies traffic, including rule creation, rule edits, rule deletion, association changes, and updates that alter priority or source and destination scope. In practice, the important question is not just whether the NSG object changed, but whether the change could expand exposure on a subnet, virtual machine, or other attached workload.

That means detection should focus on the control plane events that actually modify the policy boundary. A harmless-looking metadata edit is not the same as a rule that opens inbound access from the internet, and a priority change can be just as consequential as a brand-new rule because it may cause a different rule to win.

For teams that want a broader Azure detection baseline around this control plane, the Microsoft Azure Security Guide is the most direct internal starting point because it covers Azure activity logging, NSGs, and the surrounding security posture needed to interpret those events correctly.

How should you monitor NSG rule activity and decide what is suspicious?

The most reliable method is to ingest Azure Activity Log events for NSG write and delete operations, then alert on changes that materially weaken the rule set. The highest-signal events are newly allowed inbound ports, broader source ranges, lower priority numbers that override restrictive rules, and rule removals that leave a path open by default.

Context matters. A change made during an approved deployment window by the expected platform team may be legitimate, but a rule opened from any source, or a priority shift that suddenly bypasses a deny rule, should be treated as a security event until proven otherwise. You also need to watch the effective configuration, not only the change record, because NSG associations to subnets and NICs determine whether the policy is actually enforced where you expect it.

For organisations that use Azure at scale, the relevant pattern is drift detection. A central security team can approve a baseline, but if engineers can mutate NSGs directly, the live environment will drift unless you compare intended and effective rules continuously.

The Cloud Misconfiguration Guide is useful here because NSG changes often become a security problem only when they create exposure drift, and the guide covers the guardrails and drift-detection mindset that make those changes visible.

What should you verify after an NSG change is detected?

After an alert fires, verify whether the change was authorised, who made it, what automation or deployment pipeline triggered it, and whether the resulting effective rules expose services that were previously private. The key follow-up is to determine blast radius: which subnet, NIC, workload, or service endpoint is now reachable, and from where.

You should also check whether the change affected an environment boundary, such as production versus nonproduction, or whether it exposed management ports, admin interfaces, or sensitive back-end services. If the change looks suspicious, preserve the event details, compare the before-and-after rule sets, and validate whether any related Azure resource changes occurred at the same time.

For a deeper control perspective that ties Azure permissions and network changes together, the Azure RBAC and Service Principals Guide helps you understand which identities should be able to make NSG changes and how to narrow that set before the next incident.

Risk and Threat Considerations

NSG changes are high-value because they can convert an internal service into an internet-reachable one without changing the workload itself. That creates a direct exposure risk, especially when a broad allow rule or a priority change silently overrides a restrictive baseline.

Failure mechanism: An attacker, misconfigured pipeline, or overprivileged operator changes the rule set or its attachment so that traffic is no longer filtered as intended, then uses the new path to reach a management port, application endpoint, or lateral movement target.

Impact: The result can be unauthorized access, expanded attack surface, and faster compromise of adjacent systems if the newly exposed service was assumed to be private.

Practitioner Guidance

What to prioritise: Treat delete events, priority decreases, and newly opened inbound rules as the highest-signal NSG alerts. Those are the changes most likely to create immediate exposure, especially when they affect subnets carrying production workloads.

What to verify: Confirm the effective rule outcome, not just the configuration event. In Azure, a rule change matters only if it changes reachability on the attached subnet or NIC, so validate exposure from the perspective of the network path, not the resource object alone.

Common mistake: Teams often monitor for rule creation but miss association changes or priority shifts. That gap allows a dangerous rule to become active without any obvious “new allow rule” pattern in the logs.

Practitioner takeaway: The best detection strategy is to pair Azure control-plane logging with exposure validation, because the security question is not merely whether an NSG changed, but whether the live network boundary became weaker as a result.

Related resources from NHI Mgmt Group

• Guide: Cloud Network Security Guide
• How should security teams govern automated AD and Azure AD group changes?
• How can security teams detect domain group changes that may indicate privilege abuse?
• How do you detect changes to Domain Admins group membership?
• How do you block RDP and SSH from the internet in Azure network security groups?