System-Assigned Managed Identity Silently Loses Access After a VM Rebuild

Symptom

An application running on an Azure VM that authenticates to Key Vault, Storage or another resource using a system-assigned managed identity begins failing with authorization errors after the VM is deleted and recreated with an identical name, size and resource group. The role assignment appears to still exist in the Azure portal, the VM name is unchanged, and no application code or configuration was modified, yet every managed identity token request that previously succeeded now returns an access-denied response from the downstream resource.

False Assumption

The team assumes that because the VM name, resource ID path and assigned RBAC role are identical to before, the managed identity backing that VM is the same identity as well. Engineers frequently treat a system-assigned managed identity as a property of the resource name rather than as a separate, disposable object created and destroyed alongside the resource’s lifecycle. This leads to the assumption that deleting and recreating a VM with the same name is a like-for-like replacement with no identity-level consequence.

Root Cause

A system-assigned managed identity is not a persistent identity tied to a resource name; it is a service principal object in Microsoft Entra ID that is created when the resource is provisioned and permanently deleted when the resource is deleted. The identity has its own unique object ID (principalId), separate from the VM’s resource ID. When a VM is deleted, Azure deletes the associated service principal. Recreating a VM with the same name provisions a brand-new system-assigned identity with a new object ID. Existing RBAC role assignments and Key Vault access policies that were granted to the original object ID do not automatically transfer to the new object ID, because Azure RBAC role assignments bind to the principal’s object ID, not to the resource name or display name. The old role assignment becomes an orphaned reference to a principal that no longer exists, and the new VM’s identity has no equivalent grant unless it is explicitly re-created.

Impact

Applications using the managed identity for authentication fail at runtime with authorization errors from the target resource, while infrastructure-as-code definitions, portal views of the VM, and the resource group’s role assignment list can appear unchanged, making the fault look like a transient permissions or networking issue rather than an identity mismatch. In automated rebuild scenarios such as scale set instance refreshes, image-based redeployments or disaster recovery failover, this can silently disable access for every recreated instance, and because the original role assignment record often remains visible in some views until Azure prunes it, on-call engineers may spend significant time on network and Key Vault firewall diagnostics before recognising the identity itself changed.

Diagnosis

Confirm the object ID currently associated with the VM’s system-assigned identity and compare it against the principal ID referenced by the failing role assignment or access policy. A mismatch, or a role assignment referencing a principal ID that no longer resolves to any object, confirms the root cause.

1. Retrieve the VM’s current system-assigned identity principal ID from the Azure resource itself.
2. List the role assignments scoped to the target resource (Key Vault, Storage account or subscription/resource group) and inspect the principal ID on each assignment relevant to the VM’s expected access.
3. Attempt to resolve that principal ID against Microsoft Entra ID to determine whether it still exists as a valid service principal.
4. Compare the two principal IDs; if they differ, or the role assignment’s principal ID no longer resolves, the identity was recreated and the authorization grant was never reissued.

Correction

Grant the required role or access policy to the VM’s current system-assigned identity object ID, and remove the stale role assignment referencing the deleted principal once the new grant is confirmed working.

1. Capture the new VM’s system-assigned identity principal ID after the rebuild.
2. Create a new role assignment (or Key Vault access policy entry) scoped to the target resource, using the new principal ID and the same role definition that was previously granted.
3. Validate that the application can successfully acquire a token and complete an authenticated call to the target resource using the new identity.
4. Once validated, remove the orphaned role assignment that still references the deleted principal ID, to avoid confusion in future audits and to keep the access list accurate.

For environments where VMs are rebuilt routinely (scale sets, ephemeral build agents, disaster recovery), consider using a user-assigned managed identity instead of a system-assigned one. A user-assigned identity is a standalone Azure resource with its own lifecycle, independent of any single VM; it can be created once, granted the required roles, and then attached to and detached from VMs as they are recreated, so role assignments persist across rebuilds without manual reissue.

Validation

Confirm the fix by verifying both the identity binding and an end-to-end authenticated call succeed before considering the incident closed.

• Confirm the VM’s system-assigned identity principal ID matches the principal ID on the active role assignment for the target resource.
• Confirm the application successfully authenticates and completes a real operation against the target resource (for example, retrieving a secret from Key Vault or listing a blob container) using the managed identity token, not a fallback credential.
• Confirm no error logs reference authorization failures for the managed identity token path over a representative monitoring window after the fix.
• Confirm the stale role assignment referencing the old, deleted principal ID has been removed or is explicitly documented as intentionally retained.

Rollback

If granting the new role assignment causes unexpected access (for example, broader scope than intended, or conflicts with an existing policy), remove the newly created role assignment or access policy entry for the new principal ID; this returns the resource’s access list to its pre-correction state without affecting the VM itself or any other identity. Because the correction only adds an access grant and does not modify the VM, delete other identities, or change existing unrelated role assignments, rollback carries no risk to running workloads other than restoring the original (broken) authorization state for this specific identity path. Confirm rollback succeeded by re-listing role assignments on the target resource and verifying the new principal ID grant is absent.

Prevention

Treat system-assigned managed identity as ephemeral and coupled to the resource’s lifecycle in all design and runbook documentation, and prefer user-assigned managed identities for any VM, scale set or resource that may be deleted and recreated as part of normal operations, redeployment, or disaster recovery. Where system-assigned identities remain in use, include a post-rebuild step in deployment automation or runbooks that reissues role assignments for the new principal ID as an explicit, auditable action rather than relying on manual discovery after an outage. Regularly review role assignments across Key Vaults, storage accounts and subscriptions for principal IDs that no longer resolve to any active object, as these are a reliable signal of orphaned grants left behind by resource recreation.