How can I ensure a NSG rule configuration on a NSG

Question

How can I ensure a NSG rule configuration on a NSG

Christoph Dambacher 86

Hello together,

I am currently working with Azure Policies to enforce and ensure specific rule configurations on Network Security Groups.

One use case is the prevention / remediation of rule changes to a specific rule, which means if a specific rule is changed, we want to modify it back to a specific configuration defined in the Azure Policy.

All our tests with Azure Policies with the effects DeployIfNotExists and Modify were not successful as the NSG rule change does not trigger the reevaluation process.

Any thoughts on how to get this solved?

Siva shunmugam Nadessin 10,905 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-01-20T19:55:53.3633333+00:00
Hello Christoph Dambacher,

Thank you for posting your query on Microsoft Q&A portal.

Here are some thoughts to help you tackle this issue:

Use of "DeployIfNotExists" and "Modify": These effects are typically used to ensure resources meet certain configurations. However, it sounds like you're facing issues with them not reevaluating NSG rules after a change. Unfortunately, if the properties of the NSG rule aren't being modified through the Azure Policy evaluation, it may not trigger a reevaluation.

Consider using "AuditIfNotExists": This could help you identify when the NSG rules deviate from your defined policy configuration. While it won't enforce changes directly, it could provide insights into when rule modifications occur, allowing you to take manual or automated remediation steps.

Utilize Flow Logs: Enabling NSG flow logs can provide deeper insights into the traffic flow and potential access issues, which may help identify why your policies aren’t behaving as expected.

Security Administration Rules: Look into creating a security admin configuration with rules that take precedence over NSG rules. This way, you may ensure that your critical NSG rules stay intact despite changes.

Re-evaluation Issues: If the rule changes aren't triggering the reevaluation process, check the following:

Policy Assignment: Ensure the policy is assigned correctly to the right scope (subscription/resource group).

Policy Effectiveness: Verify conditions under which the policy should act; make sure they align with the modifications you're trying to detect.

Permissions: Ensure the identity running the policy has adequate permissions to enforce those changes.

To assist better, could you specify some details:

Have you confirmed the effects of your policy in the compliance and deployment status within the Azure portal?

Are there any particular modification events or logs that you've tracked to see if they correlate with the policy evaluations?

What specific configurations are you trying to enforce that aren't getting applied?

I hope this helps guide you toward a solution! If you have further questions or if there's anything more specific you'd like to dig into, just let me know!

References:

Configuring and Troubleshooting NSG Rules

Manage NSG Flow Logs Using Azure Policy

Understanding NSGs

If the above answer helped, please do not forget to

and Upvote it as this may help other community members to refer the info if facing a similar issue. Your contribution to the Microsoft Q&A community is highly appreciated.

Christoph Dambacher 86

Hi,

thanks for your thoughts on this here.

The effect is confirmed and the resource appears as non-compliant after the change on the NSG rule. But as mentioned the redeployment is not triggered. Means that there is something evaluating, but no deployment is triggered (effect is DINE).

The events I see in the activity log are only "Create or Update Security Rule" but there is no related policy event that correlates.

Below some more details to the policy itself what is happening in the if and then clause. I try to check on an existing rule and if this rule is modified or not present, I want to have the configuration deployed.

"if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Network/networkSecurityGroups"
          }
        ]
      }

"then": {
        "effect": "[parameters('effect')]",
        "details": {
          "evaluationDelay": "AfterProvisioning",
          "type": "Microsoft.Network/networkSecurityGroups/securityRules",
          "existenceCondition": {
            "count": {
              "field": "Microsoft.Network/networkSecurityGroups/securityRules[*]",
              "where": {
                "anyOf": [
                  {
                    "allOf": [
                      {
                        "field": "Microsoft.Network/networkSecurityGroups/securityRules/direction",
                        "equals": "Inbound"
                      },
                      {
                        "field": "Microsoft.Network/networkSecurityGroups/securityRules/access",
                        "equals": "Deny"
                      },
                      {
                        "field": "Microsoft.Network/networkSecurityGroups/securityRules/sourceAddressPrefix",
                        "equals": "*"
                      },
                      {
                        "field": "Microsoft.Network/networkSecurityGroups/securityRules/destinationAddressPrefix",
                        "equals": "*"
                      },
                      {
                        "field": "Microsoft.Network/networkSecurityGroups/securityRules/priority",
                        "equals": 4096
                      }
                    ]
                  },
                  {
                    "allOf": [
                      {
                        "field": "Microsoft.Network/networkSecurityGroups/securityRules/direction",
                        "equals": "Inbound"
                      },
                      {
                        "field": "Microsoft.Network/networkSecurityGroups/securityRules/access",
                        "equals": "Deny"
                      },
                      {
                        "field": "Microsoft.Network/networkSecurityGroups/securityRules/sourceAddressPrefix",
                        "equals": "*"
                      },
                      {
                        "field": "Microsoft.Network/networkSecurityGroups/securityRules/destinationAddressPrefix",
                        "equals": "*"
                      },
                      {
                        "field": "Microsoft.Network/networkSecurityGroups/securityRules/priority",
                        "equals": 4095
                      }
                    ]
                  }
                ]
              }
            },
            "greater": 0
          },
          "deployment": {
            "properties": {
              "mode": "incremental",
              "template": {
                "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
                "contentVersion": "1.0.0.0",
                "parameters": {
                  "nsgName": {
                    "type": "string"
                  },
                  "location": {
                    "type": "string"
                  },
                  "denyRulePriority": {
                    "type": "int"
                  }
                },
                "variables": {},
                "resources": [
                  {
                    "type": "Microsoft.Network/networkSecurityGroups/securityRules",
                    "apiVersion": "2023-05-01",
                    "name": "[concat(parameters('nsgName'), '/denyAllInbound')]",
                    "location": "[parameters('location')]",
                    "properties": {
                      "description": "Default deny all inbound (remediation by Azure Policy)",
                      "protocol": "*",
                      "sourcePortRange": "*",
                      "destinationPortRange": "*",
                      "sourceAddressPrefix": "*",
                      "destinationAddressPrefix": "*",
                      "access": "Deny",
                      "priority": "[parameters('denyRulePriority')]",
                      "direction": "Inbound",
                      "sourceAddressPrefixes": [],
                      "destinationAddressPrefixes": [],
                      "sourceApplicationSecurityGroups": [],
                      "destinationApplicationSecurityGroups": []
                    }
                  }
                ],
                "outputs": {}
              },
              "parameters": {
                "nsgName": {
                  "value": "[field('name')]"
                },
                "location": {
                  "value": "[field('location')]"
                },
                "denyRulePriority": {
                  "value": "[parameters('denyRulePriority')]"
                }
              }
            }
          },
          "roleDefinitionIds": [
            "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
          ]
        }
      }

Siva shunmugam Nadessin 10,905 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-01-21T19:27:34.38+00:00
Hello Christoph Dambacher,

Here’s a breakdown of the issue and potential solutions:

1.Evaluation and Effect (DINE): The policy is evaluating and marking the resource as non-compliant. However, it is not triggering the redeployment. This indicates the condition for the evaluation is being met, but the deployment part isn’t being invoked.

2.Activity Log: You are seeing "Create or Update Security Rule" events, but no related policy event that would correlate to the triggering of the policy effect. This may indicate that the deployment section of the policy isn't getting triggered properly.

3.Policy Structure: Based on your policy, you're trying to deploy a new NSG security rule if certain existing rules (Inbound Deny rules with specific priority) are not present or modified.

Potential Causes:

Incorrect Evaluation of Condition: The condition is based on the existence of the security rules in the NSG. If the evaluation condition isn’t correctly assessing the rules (due to how the rules are being counted or interpreted), it might be marking the resource as non-compliant but not triggering deployment.

Evaluation Delay: You’ve specified evaluationDelay: AfterProvisioning. This means that the evaluation happens after provisioning. It’s important to ensure that the system is not evaluating prematurely or incorrectly at the wrong stage in the lifecycle.

Policy Assignment: The policy may not be assigned to the correct scope (management group, subscription, resource group, etc.) or may have specific exclusions that prevent the deployment from being triggered.

Role Assignment Issues: The role definition (roleDefinitionIds) assigned might not have sufficient permissions or might be misconfigured, preventing the deployment from executing properly.

Suggested Solutions:

1. Review the existenceCondition Logic:

Ensure that the rules you're evaluating exist under the correct conditions. The way you've written the existenceCondition looks for specific rules with defined parameters (priority 4096 and 4095). If these rules are not present, it should trigger deployment. Double-check that the count and condition are properly triggering.

Consider adding more detailed logging or diagnostic steps to ensure that the condition is being evaluated correctly.

2. Test with effect: DeployIfNotExists (DINE):

Verify the policy effect. Sometimes, instead of using a custom deployment template, the DeployIfNotExists effect can be used to check for rule existence and trigger remediation directly. If that’s a potential option for you, consider trying the DeployIfNotExists effect instead of DINE to see if that triggers the deployment.

"then": { "effect": "DeployIfNotExists", "details": { "evaluationDelay": "AfterProvisioning", "type": "Microsoft.Network/networkSecurityGroups/securityRules", "existenceCondition": { "count": { "field": "Microsoft.Network/networkSecurityGroups/securityRules[*]", "where": { "anyOf": [ { "allOf": [ { "field": "Microsoft.Network/networkSecurityGroups/securityRules/direction", "equals": "Inbound" }, { "field": "Microsoft.Network/networkSecurityGroups/securityRules/access", "equals": "Deny" }, { "field": "Microsoft.Network/networkSecurityGroups/securityRules/sourceAddressPrefix", "equals": "*" }, { "field": "Microsoft.Network/networkSecurityGroups/securityRules/destinationAddressPrefix", "equals": "*" }, { "field": "Microsoft.Network/networkSecurityGroups/securityRules/priority", "equals": 4096 } ] }, { "allOf": [ { "field": "Microsoft.Network/networkSecurityGroups/securityRules/direction", "equals": "Inbound" }, { "field": "Microsoft.Network/networkSecurityGroups/securityRules/access", "equals": "Deny" }, { "field": "Microsoft.Network/networkSecurityGroups/securityRules/sourceAddressPrefix", "equals": "*" }, { "field": "Microsoft.Network/networkSecurityGroups/securityRules/destinationAddressPrefix", "equals": "*" }, { "field": "Microsoft.Network/networkSecurityGroups/securityRules/priority", "equals": 4095 } ] } ] } }, "greater": 0 }, "deployment": { ... } // Keep your existing deployment template } }

3. Ensure Role Permissions:

Check that the role assigned (b24988ac-6180-42a0-ab88-20f7382dd24c) has the appropriate permissions. Specifically, make sure the role has permissions to modify NSG rules and trigger deployments.

You can also try using the Contributor role to see if permissions are too restrictive.

4. Ensure Proper Policy Assignment Scope:

Make sure the policy is correctly assigned to the right scope (subscription, resource group, etc.), and that it’s not being blocked by exclusions or filters that could prevent the deployment from triggering.

5. Debug the Deployment Process:

Use Azure Policy Insights to debug the policy evaluation process. This can help you understand why the deployment isn't being triggered.

Review activity logs in more detail, especially logs that show Azure Policy evaluations, to check if there are any errors or unexpected results during the policy evaluation phase.

6. Force Re-evaluation (if applicable):

Sometimes, Azure Policies might not trigger immediately after the rule changes. You can trigger a re-evaluation of the policy by using the az policy state trigger command, or by reapplying the policy manually.

Let me know if you need further clarification or more assistance with any of these steps!
Christoph Dambacher 86 Zuverlässigkeitspunkte

2026-01-22T16:26:12.1766667+00:00
Hi,

thanks again for the detailed help.

The existenceCondition logic from our point of view seems to be correct. We face the challenge also for built-in policies.

We are already using DeployIfNotExists (DINE) as effect which is not present here but present in a parameter.

Role permissions shouldn't be an issue here as I guess we would see then some deployment issued regarding missing permissions in the logs.

Assignment scope is verified. We can see the non-compliant state of the policy.

There are no additional insights from the logs available as there are no policy specific events triggered.

Triggering the reevaluation will unfortunately not help in our use case as this would require manual checks as well.

Could it be the problem that the Azure policy is just checking the NSG itself and the modification of a NSG rule only logged and counted as the modification of the sub resource NSG rule?
How can it be evaluated correctly in that case?
It is the same with Diagnostic Settings.

1 Antwort

Ihre Antwort

Christoph Dambacher 86 Zuverlässigkeitspunkte

2026-01-22T16:26:12.1766667+00:00

Hi,

thanks again for the detailed help.

The existenceCondition logic from our point of view seems to be correct. We face the challenge also for built-in policies.

We are already using DeployIfNotExists (DINE) as effect which is not present here but present in a parameter.

Role permissions shouldn't be an issue here as I guess we would see then some deployment issued regarding missing permissions in the logs.

Assignment scope is verified. We can see the non-compliant state of the policy.

There are no additional insights from the logs available as there are no policy specific events triggered.

Triggering the reevaluation will unfortunately not help in our use case as this would require manual checks as well.

Could it be the problem that the Azure policy is just checking the NSG itself and the modification of a NSG rule only logged and counted as the modification of the sub resource NSG rule?
How can it be evaluated correctly in that case?
It is the same with Diagnostic Settings.

Answer 1

Hello Christoph Dambacher,

From your description, it sounds like you're facing an issue where the Azure Policy correctly evaluates the condition (finding the NSG is non-compliant), but the action (such as deployment of a new rule) isn't being triggered as expected. You've already ruled out a few potential causes like role permissions and assignment scope, so let's focus on other possibilities.

Here are a few insights and recommendations to address the situation:

1. NSG Rule Evaluation as a Sub-resource:

Yes, it's possible that Azure Policy might treat modifications to NSG rules as updates to a "sub-resource" of the NSG itself. This could be why you're seeing modifications on the NSG but not on individual security rules. If the NSG rule is evaluated as a sub-resource, the policy might not detect it as a discrete change.

Solution:

Explicit Targeting of the Rule Resource: When dealing with resources that are part of a parent-child relationship (e.g., NSG and security rules), you might need to explicitly target the security rule resource (Microsoft.Network/networkSecurityGroups/securityRules) in your policy, as you've already done.

In cases like this, the existenceCondition should focus not just on the NSG but on specific rules within it.

Recommendation:

· You might need to reference specific rules more granularly in your conditions. Ensure that your policy targets the securityRules sub-resource directly, as you are doing, but confirm whether that’s being interpreted as a valid target.

· Deployment using Sub-resource References: In some cases, especially with nested resources like security rules, Azure might not trigger the deployment directly under the NSG but under the rule. Ensure your template is specifically handling security rule updates at that granular level.

2. Policy Evaluation with DeployIfNotExists:

Since you're using DeployIfNotExists (DINE), ensure that the condition is triggering at the right time. Azure Policy should be able to detect when a rule is missing or needs to be deployed, but if there's a timing issue or it's not correctly interpreting the absence of rules, the deployment might not be triggered.

Solution:

Evaluation Delay Timing: You are using evaluationDelay: AfterProvisioning, but consider if this could be misinterpreting the state of resources. Try adjusting the timing to see if earlier evaluation (e.g., BeforeProvisioning) yields different results.
Also, ensure that DINE is using the correct scope for checking the rule’s existence, especially since Azure policies can sometimes behave differently based on whether you're dealing with resources directly or through child/sub-resources.

3. Diagnostic Settings and Logs:

If you're not seeing specific logs related to the policy effect, it's important to verify whether the policy is triggering but failing to complete successfully or not triggering at all. You mentioned there's no "policy event" in the logs, which suggests it might be a problem with how the policy is being evaluated, rather than permissions or assignment scope.

Solution:

Enable Policy Insights and take a deeper look at any Azure Policy evaluation errors or warnings that might not be immediately obvious in the Activity Log.
Sometimes, using Azure Policy Insights or Azure Resource Graph Explorer can give more granular details about what’s happening during the evaluation phase.

4. NSG Rule Deployment Template:

Ensure the deployment template is properly configured for the DeployIfNotExists effect. If the template itself isn’t correctly deploying the rule, even if the policy is evaluated as non-compliant, the issue might be in the template.

Solution:

Test the deployment template independently (outside of the policy) to ensure it can successfully deploy the NSG rule.
Ensure that the parameters passed to the deployment are valid and match the required values for creating the specific rule.
You might also want to verify whether the template is doing what is expected by manually applying it in a sandbox environment.

5. Reevaluating the Condition with Diagnostic Rules:

It's also possible that your policy is correctly assessing the state of the NSG, but the rule is still being marked compliant when it should not be. If the policy isn’t detecting changes or there’s an issue with how rules are evaluated within a given scope (e.g., NSG rules as part of a larger resource group or subscription), the condition might need adjustment.

Solution:

Consider adding more diagnostic logging for the policy evaluation itself, perhaps at a broader scope like the subscription level, to capture any subtle issues with how the policy is evaluating NSG rules.

6. Check for Policy Caching or Delays:

Sometimes, Azure policies can take a little while to reflect changes in state, especially for resources like NSGs and security rules.

Solution:

Use the Azure Policy Remediation feature to manually force a re-run of the policy evaluation, which might trigger the missing deployment.
If you're working in a larger-scale environment, you might also want to check for any caching or delayed policy execution issues.

Conclusion:

The most likely issue seems to be the way Azure is treating security rules as sub-resources of the NSG and possibly not triggering deployment actions correctly. Double-check the deployment template, explicitly ensure that the policy is evaluating the security rules themselves, and verify that all conditions are being met as expected.

If all else fails, revisiting the Deployment templates (and testing them independently) or adjusting the evaluation delay could yield better results.

Let me know if any of these suggestions help or if you need further clarification!

Siva shunmugam Nadessin 10,905 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-01-23T21:06:25.9033333+00:00

Hello Christoph Dambacher,

Just checking in to see if the solution shared above help you to resolve your issue. please reach out to us If you have any further questions.

Thanks
Christoph Dambacher 86 Zuverlässigkeitspunkte

2026-02-02T07:49:25.73+00:00

Hi,

the issue still persists and we were not able to solve it.

Let's take another example for our problem.

We have the following built-in policy: Enable logging by category group for Key vaults (microsoft.keyvault/vaults) to Log Analytics.

I would assume that if I am changing or deleting a diagnostic setting the reevaluation would be triggered to check if the diagnostic setting still exists as it should be.

But this is also not working, and I know it was working in the past.

Or do I misunderstand the policy functionality? :)

Best regards

Christoph

How can I ensure a NSG rule configuration on a NSG

References:

1 Antwort

Ihre Antwort