Reconcile remediation permissions after changing an Azure Policy definition

Source facts

Azure Policy remediation uses the managed identity associated with the assignment to deploy or modify resources. A policy definition lists required roles in roleDefinitionIds, but changing that definition does not automatically update the assignment or its associated identity.

The portal can grant required roles when creating the identity. Later edits to roleDefinitionIds still require manually granting the new permissions, even when using the portal. SDK-created assignments and resources accessed outside the assignment scope are additional cases requiring manual permission review. Microsoft Learn.

Applicability

Identify the exact assignment, its identity, the revised policy definition and every resource scope involved. Treat a compliance evaluation and the permission to perform remediation as separate observations.

DSE recommendation

DSE recommends including an identity-grant comparison in policy-definition change review. Explain each added permission and grant only the necessary scope through the authorized access process. Do not repeatedly rerun remediation or grant broad ownership merely because the updated definition lists a role that the identity does not actually possess.

Verification

For an approved representative resource, inspect the identity’s effective assignments and run a bounded remediation. Compare deployment or modification results with the revised requirement. Retain the policy revision, identity identifier, grant scope and outcome together. Verify the intended resource state afterward rather than accepting a successful access change as proof that remediation completed.

Official references

Microsoft Learn: Remediate non-compliant resources. Source retrieved September 9, 2026.