How do you configure managed identities for Azure virtual machines and scale sets?

How managed identities work on Azure VMs and scale sets

Managed identities are an Azure-native way to give a VM or scale set an identity that Azure can authenticate on its behalf. You enable the identity on the resource, then use that identity when the workload needs to access services such as Key Vault, Storage, or Microsoft Graph. The key design choice is whether the identity should be tied to one resource or shared across several.

For a system-assigned managed identity, Azure creates and removes the identity with the VM or scale set itself. That makes it a good fit when the access path should end automatically with the resource lifecycle. A user-assigned managed identity is created as a separate Azure resource, so you can attach it to one or many compute resources when they need the same access pattern.

That lifecycle difference matters because it changes how you plan access scope, reuse, and cleanup. A system-assigned identity reduces leftover identity objects when the resource is deleted, while a user-assigned identity gives you a stable identity object you can move or share without reissuing application credentials. For reference on the broader workload-identity model, see the Cloud Workload Identity Guide.

What you actually configure in Azure

The practical configuration is simple, but the governance behind it is not. First, turn on the managed identity for the VM or scale set. Then grant only the Azure permissions the workload needs, at the narrowest possible scope. In Azure, that usually means role assignments on the resource, resource group, or subscription, depending on the task the workload must perform. If you are using user-assigned identities, keep track of which machines are attached to which identity so the same privilege set is not spread accidentally across unrelated systems.

When the workload needs to sign in to another Azure service, the code or platform retrieves a token from the Azure identity platform rather than storing a secret in the guest OS. That is the main operational benefit: fewer static credentials, less secret distribution, and a smaller chance that a long-lived secret leaks through image builds, scripts, or configuration files. The same pattern is covered in NHIMG’s Microsoft Azure Security Guide.

Managed identity is still only one half of the control. The other half is authorization. If you grant broad Reader, Contributor, or data-plane access too early, the identity becomes a convenient route to overreach instead of a safer replacement for a password or certificate. The Azure RBAC and Service Principals Guide is useful when you need to reason about role scope, assignment boundaries, and managed identity abuse.

How to avoid privilege creep and operational drift

Managed identities work best when they are treated as part of an access lifecycle, not as a one-time setup. Review assignments regularly so the identity does not accumulate permissions for old integrations, test hooks, or temporary migrations. In larger environments, user-assigned identities are especially prone to privilege creep because one identity can quietly become the common access path for several resources and several teams.

A second practical issue is ownership. If nobody can explain why a user-assigned identity exists, which workload uses it, and who is responsible for it, you have an identity governance problem even if the technical configuration is valid. That is where service-account-style review habits still apply. For a broader checklist of lifecycle, ownership, and access-control failure modes, see Top 10 NHI Issues and the Service Account Security Guide.

Scale sets add one more consideration: the identity must work consistently across instances that may be created, replaced, or healed automatically. That makes attachment and scope design more important than manual onboarding steps. If you need a stable identity shared across many compute nodes, user-assigned identities are usually the cleaner pattern. If you want the identity to disappear with the resource, system-assigned is usually safer and easier to retire.

Risk and Threat Considerations

Managed identities reduce secret handling, but they also concentrate trust. If an attacker compromises a VM or scale set instance and can use its managed identity, the compromise can extend beyond the host into whatever Azure resources that identity can reach. The main security failure is usually not the identity feature itself, but excessive permissions, weak scope boundaries, or reused user-assigned identities with too much reach.

Failure mechanism: The workload identity is valid, but the attached Azure roles are broader than the workload actually needs, so compromise of the host becomes compromise of the authorized resource set.

Impact: Attackers can read data, alter cloud resources, or move laterally into adjacent services without stealing a password or API key, which makes detection harder and blast radius larger.

Practitioner Guidance

What to verify: Confirm whether the workload truly needs a shared identity or whether a system-assigned identity is enough. Then verify every role assignment against the workload’s current data and control needs, not its historical needs.

Common mistake: Treating user-assigned identities as a convenience default for every VM or scale set. That often creates a reusable privilege object that outlives the original use case and becomes harder to audit.

Decision rule: If the identity should die when the compute resource is deleted, use system-assigned. If multiple resources must present the same identity to downstream services, use user-assigned, but place tighter governance around attachment, scope, and review.

Practitioner takeaway: The safest managed-identity design is the one that makes access easy for the workload but hard to overextend, so lifecycle and authorization scope should be decided together.

Related resources from NHI Mgmt Group

• How do you enforce SSH key authentication on Azure Linux virtual machines?
• Why do non-human identities complicate zero trust architecture?
• Why do non-human identities increase zero trust risk?
• When should organisations prioritise Zero Standing Privilege for non-human identities?