# Delegate firewall rule-group editing without granting policy-hierarchy changes

> Match application-team permissions to the documented Firewall Policy delegation pattern.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260917-119-delegate-firewall-rule-group-editing-without-granting-policy-hierarchy-changes/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-17T16:33:01+00:00
- Modified: 2026-09-17T16:42:35+00:00
- Last reviewed by DSE: 2026-09-17
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Match application-team permissions to the documented Firewall Policy delegation pattern.

## Potentially affected

Use this review for a proposed application-team delegation model. Identify the team policy, inherited base policy, rule groups and existing effective permissions. The example's restrictions should be verified against the actual role assignments rather than assumed from a custom role's name.

## DSE recommendation

DSE recommends an explicit allowed-and-denied task list before granting access.

## Article

## Source facts

Microsoft’s Firewall Policy hierarchy example uses a custom role to give application teams selective access to rule collection groups. In the documented outcome, those users cannot delete the firewall or policy, change policy hierarchy, or update DNS and threat-intelligence settings. The example assigns the role at the relevant application-team policy. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/firewall-manager/rule-hierarchy).

## Applicability

Use this review for a proposed application-team delegation model. Identify the team policy, inherited base policy, rule groups and existing effective permissions. The example’s restrictions should be verified against the actual role assignments rather than assumed from a custom role’s name.

## DSE recommendation

DSE recommends an explicit allowed-and-denied task list before granting access. Have security owners identify the rule groups the team may edit and the policy controls they must retain centrally. Review the current source’s role definition and assignment scope, then check for other grants that could undermine the intended separation. Preserve ownership and access-review evidence with the delegation.

## Verification

With an approved test identity, confirm a permitted rule-group edit in a test policy. Assess restricted operations through effective permissions and safe authorization checks, without deleting a production object as a test. Record the identity, assignment scope and outcomes. Resolve broader inherited access before claiming that the delegation is limited to rule editing.

## Official references

[Microsoft Learn: Use Azure Firewall policy to define a rule hierarchy](https://learn.microsoft.com/en-us/azure/firewall-manager/rule-hierarchy).

## Primary reference

- Name: Use Azure Firewall policy to define a rule hierarchy | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/firewall-manager/rule-hierarchy
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Delegate firewall rule-group editing without granting policy-hierarchy changes,” DSE Security, https://update.dsesecurity.com/updates/dse-20260917-119-delegate-firewall-rule-group-editing-without-granting-policy-hierarchy-changes/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.