Machine Identities in Azure

Last Updated on June 23, 2026 by Arnav Sharma

As an architect who has spent years helping organisations rebuild their Azure identity posture from the ground up, I keep running into the same conversation: a security team can name every human user with privileged access, but cannot tell me how many machine identities in Azure are quietly holding standing permissions to their key vaults, storage accounts, and databases. Azure managed identities were built to solve exactly this problem, but only when they are understood and governed properly. This guide walks through what managed identities are, the two types Azure supports, how to configure managed identities correctly, and how they now extend into workload identity federation for modern, secretless architectures. If you only take one thing from Microsoft Learn’s own documentation and this guide combined, make it this: using managed identities correctly is the single highest-leverage change you can make to your Azure identity posture this year.

What Is a Machine Identity in Azure?

At a high level, every identity in an Azure tenant falls into one of two categories: human identities and machine identities, also called non-human identities. A human identity belongs to a person who signs in with a username, a password, and increasingly multi-factor authentication. A machine identity represents software, not a person, and it needs to authenticate just as rigorously.

Human Identities vs Non-Human (Machine) Identities

Human identities are the accounts your staff use every day in Microsoft Entra ID. Non-human identities are everything else: device identities, workload identities, and the applications and services that run without a person sitting behind the keyboard. The distinction matters for security architecture because human identities are protected by sign-in risk policies, conditional access, and behavioural anomaly detection, while machine identities have historically been protected by something much weaker, a credential sitting in a configuration file, an environment variable, or a CI/CD pipeline secret store.

Where Managed Identities Fit Among Workload Identities

In Microsoft Entra, workload identities include applications, service principals, and managed identities. A managed identity is, internally, a special type of service principal that can only be associated with Azure resources. That distinction is worth sitting with: every managed identity is a service principal, but not every service principal is a managed identity. A standard service principal (commonly used for app registrations and external automation) still requires you to manage a client secret or certificate. A managed identity removes that requirement entirely. Microsoft Entra ID issues, stores, and rotates the credential automatically, and your code never sees it.

Why Machine Identities in Azure Outnumber Human Identities

This is not a marginal trend. Industry research on non-human identity sprawl has repeatedly found that machine identities now outnumber human identities by ratios that frequently exceed 100:1 in large enterprise cloud environments, and the gap keeps widening as automation, microservices, and AI agents proliferate. Every Azure Function, every Logic App, every AKS pod, and every CI/CD pipeline that needs to talk to a downstream resource is a candidate for its own identity.

The risk this creates is not abstract. When a managed identity is assigned to a compute resource, every permission granted to that identity becomes available to anything running on that resource. If a developer or an attacker can execute code on the VM or App Service, they inherit whatever access the identity carries. Security teams that treat managed identity creation as a low-stakes configuration step, rather than a privileged access decision, are the ones who end up with a single compromised App Service exposing a subscription-wide Contributor role. Minimising that blast radius is the single most important discipline in managing machine identities in Azure, and it starts with understanding the two identity types Azure gives you.

The Two Types of Managed Identities in Azure

Azure supports two types of managed identities, and the choice between them is an architectural decision, not a preference.

System-Assigned Managed Identities

A system-assigned managed identity is created directly on an Azure resource, such as an Azure Virtual Machine, and its lifecycle is tied to that resource. Enable it, and Azure Resource Manager creates a service principal in Microsoft Entra ID behind the scenes. Delete the resource, and the identity is deleted with it. This is useful when you want a clean one-to-one relationship between a workload and its identity, with no risk of an orphaned credential lingering after decommissioning.

User-Assigned Managed Identities

A user-assigned managed identity is created as a standalone Azure resource, independent of any single virtual machine, app, or function. You can then assign that same identity to multiple resources. Its lifecycle is decoupled from any one resource: delete the virtual machine, and the user-assigned identity persists until you explicitly remove it. This decoupling is exactly why user-assigned managed identities are recommended in a broader range of scenarios than system-assigned managed identities, particularly where several resources need identical access to the same downstream services.

Consider four virtual machines that all need access to two storage accounts. With system-assigned managed identities, each VM gets its own identity and you end up managing eight separate role assignments. With a single user-assigned managed identity attached to all four VMs, you manage two role assignments instead, and administrative overhead drops accordingly.

Factor	System-Assigned	User-Assigned
Lifecycle	Tied to the parent resource	Independent Azure resource, managed separately
Reuse across resources	No, one-to-one only	Yes, one identity to many resources
Role assignment overhead	Grows linearly with resource count	Stays flat as resources scale
Best fit	Unique, resource-specific permission sets where automatic cleanup matters	Shared access patterns across many resources

If your infrastructure requires that every resource holds a genuinely unique set of permissions and you want that identity deleted automatically when the resource is deleted, a system-assigned managed identity is the right call. If multiple resources need the same access, a user-assigned managed identity reduces both the number of distinct identities and the number of role assignments you have to track.

How Managed Identities Work Under the Hood

Internally, managed identities are service principals of a special type that can only be used with Azure resources. When you enable a system-assigned managed identity on a virtual machine, Azure Resource Manager sends a request to the Managed Identity Resource Provider, which issues a certificate to that identity behind the scenes. Your application code never handles that certificate directly. Instead, it requests a token from a local metadata endpoint available to the compute resource, and Microsoft Entra ID returns a short-lived access token your code can present to any downstream service that supports Microsoft Entra authentication.

Azure takes care of rolling the credentials that back the identity for the life of the resource. When the managed identity is deleted, whether automatically through resource deletion or manually for a user-assigned identity, the corresponding service principal is removed from the tenant as well, leaving no orphaned credential behind for someone to find later.

Configuring Managed Identities for Azure Resources

Configuring managed identities for Azure resources follows the same basic pattern regardless of which compute service you are using: Azure Virtual Machine, Virtual Machine Scale Set, Azure App Service, or any other supported hosting platform.

Enabling a System-Assigned Managed Identity (Azure Portal)

In the Azure Portal, open your virtual machine, navigate to the Identity blade, switch the System Assigned tab to On, and save. Azure Resource Manager creates the underlying service principal automatically, and you can confirm it by checking Microsoft Entra ID’s Enterprise Applications list for an entry matching your resource name.

Creating a User-Assigned Managed Identity (Azure CLI)

A user-assigned managed identity is created as a standalone resource before it is attached to anything. To create a user-assigned managed identity on Microsoft Azure, a typical Azure CLI flow looks like this:

az identity create --name my-workload-identity --resource-group my-rg --location australiaeast
az vm identity assign --name my-vm --resource-group my-rg --identities my-workload-identity

The first command creates the identity in Microsoft Entra ID and returns its client ID, principal ID, and resource ID. The second command assigns it to an existing virtual machine. The same identity resource ID can then be assigned to any number of additional resources using the equivalent assignment command for that resource type.

Enabling Managed Identities via an Azure Resource Manager Template

For infrastructure-as-code workflows, an Azure Resource Manager template can enable a managed identity declaratively as part of resource deployment, which is the preferred approach for teams that manage identity configuration through version-controlled pipelines rather than manual Portal changes.

Whichever path you choose, the resources that support managed identities for azure span far beyond virtual machines, including Azure App Service, Azure SQL, Azure Key Vault, and Azure Storage, each of which can accept a managed identity as the authenticating principal instead of a connection string or access key. Across Microsoft Azure, this consistent pattern, that machine identities represent software workloads rather than people, is what lets the same configuration approach scale from a single VM to a fleet of containerised services.

Authenticating to Azure Services with Managed Identities

Once a managed identity is enabled and assigned, your workload uses it to authenticate to Azure services that support Microsoft Entra authentication. In practice, this means your code calls the Azure SDK or the Microsoft Authentication Library, which handles the token request to the local metadata endpoint and the subsequent exchange for a Microsoft Entra ID access token, without ever touching a credential directly.

The two most common downstream targets in real deployments are Azure Key Vault and Azure Storage. Rather than storing a Key Vault access policy secret or a storage account key in application configuration, you grant the managed identity an RBAC role on the Key Vault or Azure Storage account, and your application authenticates using that identity at runtime. This single change eliminates one of the most common sources of credential leakage in cloud environments: secrets committed to source control or left in plaintext configuration files.

Role Assignments and the Managed Identity Operator Role

Granting a managed identity access to a resource is a role assignment, the same RBAC mechanism used for human identities and standard service principals. The discipline that matters here is least privilege: if a managed identity only needs to read from a storage account, do not grant it Contributor or Owner at the subscription scope. Scope every role assignment to the narrowest resource boundary that satisfies the workload’s actual requirement.

One role worth knowing specifically is the Managed Identity Operator role, which allows a security principal to assign a user-assigned managed identity to a resource without granting broader control over the identity’s other permissions. This is useful when you want to separate the team that creates and governs identities from the team that deploys workloads and attaches identities to them, keeping identity governance centralised even as resource deployment is distributed.

Mature identity management programs in Azure AD environments treat every role assignment to a managed identity as equivalent in sensitivity to a human privileged access grant, not as a minor configuration detail. The credentials backing a managed identity are automatically managed by the platform, which removes the operational burden of manual rotation and the kind of missed security updates that plague hand-rolled secret management, but automatic credential handling does not substitute for deliberate scoping of what that identity can access azure to do. Every one of the protected resources a managed identity can reach should map back to a documented business reason, reviewed on the same cadence as your privileged access reviews for human accounts.

Workload Identity Federation: Extending Machine Identities Beyond Azure

Managed identities solve credential-free authentication for workloads running inside Azure, but plenty of real-world scenarios involve a workload running somewhere else, a GitHub Actions pipeline, an on-premises server, or another cloud provider, that still needs to reach Azure resources. This is where workload identity federation comes in.

Workload identity federation lets you establish a trust relationship between an external identity provider and a user-assigned managed identity in Microsoft Entra ID. Instead of storing a long-lived client secret for that external system, you configure a federated identity credential that defines which external token, identified by its issuer and subject, should be trusted. The external workload presents its own OIDC token, and any system that does support entra id can validate the trust relationship and access microsoft entra to receive a short-lived Entra ID access token in exchange, all without a static secret ever existing in either system. There is a limit of 20 federated identity credentials per managed identity or app registration, which is worth planning around if you are federating many distinct external systems.

This pattern has become especially relevant as organisations move agentic AI workloads into production. An agent running on Azure compute, authenticated by a managed identity, can use workload identity federation to reach external services or APIs without ever holding a static credential, extending the same secretless model that protects your virtual machines and app services to your CI/CD pipelines and your AI agent fleet alike.

Governance and Lifecycle: Treating Machine Identities Like What They Are

A managed identity created without a governance plan is a credential nobody is watching. Three practices keep that from happening.

First, apply conditional access for workload identities wherever your licensing tier supports it, so that machine identities are subject to risk-based controls similar to those protecting human sign-ins, rather than being implicitly trusted simply because they originate from inside Azure.

Second, treat the lifecycle of every managed identity as deliberately as you would a privileged human account. User-assigned identities in particular need an owner and a decommissioning trigger, because nothing deletes them automatically when the workloads using them are retired. Audit Microsoft Entra ID periodically for managed identities with no resource assignments and no recent token activity, and remove them.

Third, resist the urge to reuse a single broadly-permissioned user-assigned identity across unrelated workloads purely for convenience. The administrative savings are real, but so is the blast radius if that identity is ever compromised through one of the resources it is attached to. Match the identity type and its permission scope to the actual sensitivity of what it protects, whether that is an Azure SQL database, a Key Vault holding production secrets, or a storage account with regulated data.