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.
\nThe 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.
\nIdentify 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.
\nDSE 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.
\nUse 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.
\nMicrosoft Learn: Examples to delegate Azure role assignment management with conditions – Azure ABAC. Source retrieved September 9, 2026.
", "content_text": "Source facts\nMicrosoft’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.\nThe 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.\nApplicability\nIdentify 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.\nDSE recommendation\nDSE 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.\nVerification\nUse 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.\nOfficial references\nMicrosoft Learn: Examples to delegate Azure role assignment management with conditions – Azure ABAC. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nMicrosoft’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.\n\nThe 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).\n\n## Applicability\n\nIdentify 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.\n\n## DSE recommendation\n\nDSE 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.\n\n## Verification\n\nUse 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.\n\n## Official references\n\n[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." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/dse-20260909-357-reassess-delegated-role-assignment-denylists-when-roles-change/", "url": "https://update.dsesecurity.com/updates/dse-20260909-357-reassess-delegated-role-assignment-denylists-when-roles-change/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-357-reassess-delegated-role-assignment-denylists-when-roles-change/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Reassess delegated role-assignment denylists when roles change", "item": "https://update.dsesecurity.com/updates/dse-20260909-357-reassess-delegated-role-assignment-denylists-when-roles-change/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-357-reassess-delegated-role-assignment-denylists-when-roles-change/#article", "identifier": "https://update.dsesecurity.com/updates/dse-20260909-357-reassess-delegated-role-assignment-denylists-when-roles-change/", "url": "https://update.dsesecurity.com/updates/dse-20260909-357-reassess-delegated-role-assignment-denylists-when-roles-change/", "headline": "Reassess delegated role-assignment denylists when roles change", "description": "Blocking known privileged role IDs does not automatically block a future role with equivalent role-assignment permissions.", "abstract": "Blocking known privileged role IDs does not automatically block a future role with equivalent role-assignment permissions.", "articleBody": "Source facts\nMicrosoft’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.\nThe 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.\nApplicability\nIdentify 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.\nDSE recommendation\nDSE 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.\nVerification\nUse 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.\nOfficial references\nMicrosoft Learn: Examples to delegate Azure role assignment management with conditions – Azure ABAC. Source retrieved September 9, 2026.", "datePublished": "2026-09-10T00:25:59+00:00", "dateModified": "2026-09-10T02:01:55+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-357-reassess-delegated-role-assignment-denylists-when-roles-change/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/dse-20260909-357-reassess-delegated-role-assignment-denylists-when-roles-change/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Reassess delegated role-assignment denylists when roles change" }, "articleSection": [ "Cybersecurity", "Networks & Infrastructure" ], "keywords": [ "Cybersecurity", "Networks & Infrastructure", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 230, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Examples to delegate Azure role assignment management with conditions - Azure ABAC | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/role-based-access-control/delegate-role-assignments-examples" } } ] } }