# Reassess delegated role-assignment denylists when roles change

> Blocking known privileged role IDs does not automatically block a future role with equivalent role-assignment permissions.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-357-reassess-delegated-role-assignment-denylists-when-roles-change/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:25:59+00:00
- Modified: 2026-09-10T02:01:55+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Blocking known privileged role IDs does not automatically block a future role with equivalent role-assignment permissions.

## Potentially affected

Azure role-assignment delegation using conditions that exclude selected role definitions.

## DSE recommendation

Review the permitted role set explicitly and include new or changed role definitions in delegation review.

## Article

## Source facts

Microsoft’s example that permits most roles while excluding selected privilege-granting roles carries a specific warning: a newly added built-in or custom role containing role-assignment permission would not be blocked automatically. The condition would need updating to include that role.

The examples also distinguish add and remove operations because their condition attributes have different sources. Targeting both requires separate conditions rather than one shared expression. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/role-based-access-control/delegate-role-assignments-examples).

## Applicability

Identify the delegate’s actual role assignments, condition expressions and intended permitted roles. Do not assume a list of familiar privileged role names exhausts every route to the same permission.

## DSE recommendation

DSE recommends comparing an explicit approved-role set with a denylist approach before delegating assignment management. If exclusions are retained, assign responsibility for reviewing new and modified role definitions and for updating the condition when necessary. Review both creation and removal authority. Keep any examples’ identities and role identifiers separate from approved values for the real scope.

## Verification

Use nonproduction identities to test an allowed assignment and a deliberately excluded assignment through both supported operation paths. Review a candidate role containing assignment-management permission before making it available to the delegate. Capture the evaluated condition and expected denial together; a successful test against yesterday’s role list is not continuing evidence for tomorrow’s catalog.

## Official references

[Microsoft Learn: Examples to delegate Azure role assignment management with conditions – Azure ABAC](https://learn.microsoft.com/en-us/azure/role-based-access-control/delegate-role-assignments-examples). Source retrieved September 9, 2026.

## Primary reference

- Name: Examples to delegate Azure role assignment management with conditions - Azure ABAC | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/role-based-access-control/delegate-role-assignments-examples
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Reassess delegated role-assignment denylists when roles change,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-357-reassess-delegated-role-assignment-denylists-when-roles-change/
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.