Service Principals vs Managed Identities: Which Azure Workload Identity to Use and How to Migrate

Many Azure tenants still run workloads on app registrations with client secrets that someone created years ago, even though the workload sits on Azure compute that could use a managed identity with no credential to handle at all. The two are closely related: every managed identity is a service principal in Microsoft Entra ID, but one whose credential Azure manages and you never see. This guide explains what each object is, compares them property by property, sets out when an app registration is still the right choice, and gives a phased plan to move workloads from secrets to managed identities or federated credentials with a safe rollback. It is for Azure platform engineers, Entra ID administrators and identity teams who own workload identities. For RBAC design see the Azure RBAC and Service Principals Guide; for managed identity hardening in depth see the Azure Managed Identities Security Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• A managed identity is a service principal with no credential for you to hold. Microsoft lists three service principal types: application, managed identity and legacy. The managed identity type has no application object and its credentials are not accessible to you.
• Microsoft's own order of preference is clear. Use a managed identity where possible, a federated credential from a trusted platform where the workload runs outside Azure, a certificate if neither works, and avoid client secrets.
• App registrations are still needed for four things. Signing in users, acting as a web API (the resource in a token flow), operating across multiple tenants, and running outside Azure.
• User-assigned identities suit most fleets. Microsoft's best practice guidance favours user-assigned identities for replicated, ephemeral and pre-provisioned resources, and system-assigned identities where per-resource audit or automatic clean-up matters most.
• No secret does not mean no risk. Anyone who can run code on a resource can use every identity attached to it, and managed identity tokens are cached for around 24 hours, so least privilege and assignment control still decide the blast radius.

What each identity is

In Microsoft Entra ID an application object is the global definition of an app in its home tenant, and a service principal is its local representation in a specific tenant: the object that receives role assignments and permissions and appears under Enterprise applications. A single-tenant app has one service principal; a multitenant app has one in its home tenant plus one in every tenant that consents to it. When people say "service principal" in an Azure context they usually mean an application-type service principal backed by an app registration, which authenticates with a client secret, a certificate or a federated identity credential that you configure and own.

A managed identity is an identity assigned to an Azure resource such as a virtual machine, App Service app, Function, container app or AKS cluster. Entra ID creates a managed-identity-type service principal for it. It has no app registration, its properties cannot be edited directly, and the credential behind it is created, held and rotated by Azure. Code obtains a token through the Azure Identity SDK or MSAL from the hosting environment, with no secret in configuration. Managed identities come in two forms:

• System-assigned: created as part of one Azure resource, shares its lifecycle and is deleted automatically with it. It cannot be shared. Its service principal takes the resource's name.
• User-assigned: created as a standalone Azure resource, assignable to many resources, and deleted only when you delete it.

A third, older form, the legacy service principal, was created before app registrations existed. It can hold credentials and is usable only in the tenant where it was created; treat any you find as migration candidates.

Side-by-side comparison

Credential options for app registrations, in order of preference

Microsoft's app registration security guidance sets a clear ladder. Apply it to every service principal that cannot become a managed identity.

Federated credentials work with both app registrations and user-assigned managed identities. Microsoft notes that an app is only as secure as the identity platform it trusts as a credential, so a federated credential pointing at a loosely controlled repository or cluster moves the risk rather than removing it. For federation across clouds see Cross-cloud workload identity federation.

Choosing: when to use each

Microsoft gives a direct test: use a managed identity instead of an app registration when all four conditions are true. The service runs in Azure. It does not need to sign in users. It does not act as the resource in a token flow (it is not a web API). It does not need to operate in multiple tenants. Managed identities can still call resources outside Azure that accept Entra ID tokens, including Microsoft Graph.

System-assigned or user-assigned

• Choose user-assigned for: rapidly created or ephemeral resources (many system-assigned identities can hit the Entra object creation rate limit, returning HTTP 429, and deleted ones count against the limit until purged after 30 days); replicated resources needing the same permissions; environments where identity creation needs approval; and resources that need role assignments before deployment.
• Choose system-assigned for: audit logs that must name the exact resource that acted, and permissions that must disappear with the resource.
• Combine them: a resource can hold one system-assigned identity and several user-assigned ones. Microsoft's own example uses a shared identity for broad access plus a per-resource identity for narrow permissions. Microsoft's worked example of four VMs reaching two storage accounts and a key vault needs two role assignments with one user-assigned identity and eight with system-assigned identities.

Small organisations get most of the value by enabling managed identities on their App Service, Functions and VM workloads and deleting the matching secrets. Large and multi-subscription estates should standardise user-assigned identities per workload, restrict the Managed Identity Operator and Managed Identity Contributor roles, and use Azure Policy to require managed identity on new resources. See the Azure Policy and Management Groups Guide.

Trade-offs to manage with managed identities

• Code execution equals identity use. Microsoft warns that anyone who can run code on a resource, such as editing a Logic App or running a command on a VM, can use every identity assigned to it. Treat write access to compute as access to its identities.
• Assignment is a privilege. A user who can assign identities can attach a powerful user-assigned identity to a resource they control. Limit Managed Identity Operator and Contributor, and alert on assignment changes.
• Revocation is slow through groups. Managed identity tokens are cached by Azure infrastructure per resource URI for around 24 hours and cannot be force-refreshed, so group or app role membership changes can take hours to apply. Microsoft advises assigning permissions directly to a user-assigned identity, and changing access by adding or removing that identity from resources, where fast changes matter.
• Role assignments outlive identities. Deleting an identity does not delete its role assignments. Orphans appear as "Identity not found" in the portal or ObjectType Unknown in PowerShell; remove them so they do not accumulate against subscription limits.
• Shared identities blur attribution. One user-assigned identity on twenty resources means sign-in logs show the identity, not which resource used it. Split identities where attribution matters.
• Instance metadata is a credential path. Server-side request forgery in an application on a VM can request tokens from the metadata endpoint (ATT&CK T1552.005 Cloud Instance Metadata API). Validate outbound requests in applications and keep identity scope narrow.

Migrating from secrets to managed identities or federation

1. Inventory credentials. List app registrations and legacy service principals with password or key credentials, their expiry dates and owners, using Microsoft Graph or the Entra admin center. Flag apps with more than one active credential and apps with no owner.
2. Find the consumer. Use service principal sign-in logs (IP address, resource and frequency) to find where each credential is used and what it calls.
3. Pick the target per the ladder. Azure-hosted and single-tenant: managed identity. External pipelines or clusters: federated credential. Everything else: certificate.
4. Grant equivalent, then narrower, access. Assign the new identity the roles the workload actually uses, scoped to resources rather than subscriptions.
5. Switch a pilot. Change the application to use DefaultAzureCredential or ManagedIdentityCredential (often a configuration change) on one instance or slot, and watch for authorisation errors.
6. Keep the old credential, unused, for a window. Leave the secret in place but stop distributing it, and watch its sign-ins. Rollback is pointing the app back at the secret. When sign-ins stop, delete the secret from the app registration and from the key vault.
7. Prevent regression. Configure app management policies to restrict or block new secrets and enforce certificate issuers, turn on app instance property lock, and alert on new credentials (see How to detect new credentials added to an app registration).

Threat model, failure modes and a worked scenario for each option

Service principals with their own credentials

Threat model. A client secret or certificate on an app registration can be used from anywhere, so the attacker wants to read it, or to add a new credential to an existing application, which MITRE ATT&CK tracks as T1098.001 Additional Cloud Credentials. Failure modes. Secrets with multi-year expiry, credentials added by people who are not owners, and applications left behind after the project ends. Controls. Prefer certificates or federated credentials over secrets, restrict who can add credentials, and alert on every credential addition. Decision criteria. Use a service principal with credentials only when the workload runs outside the platform and cannot federate.

Managed identities

Threat model. Microsoft states that with managed identities you do not manage credentials and they are not even accessible to you, so theft of a stored secret is off the table. The attacker instead needs code execution on a resource that holds the identity. Failure modes. A user-assigned identity shared across many resources, so compromise of one reaches the permissions of all, and user-assigned identities left orphaned because, unlike system-assigned ones, they have an independent lifecycle and must be deleted explicitly. Controls. One identity per workload where practical, least-privilege role assignments, and a regular check for user-assigned identities with no attached resource. Decision criteria. Use a managed identity whenever the workload runs on a supported platform resource.

Detection and measurement

Monitor the Entra audit log for credentials added to applications and service principals, new federated identity credentials, owner changes and consent grants, since adding a credential to an existing app is a common persistence method (ATT&CK T1098.001 Additional Cloud Credentials). Watch the service principal and managed identity sign-in logs for new source IPs and resources, and the Azure Activity Log for managed identity assignments and role assignment changes. See How to audit Entra workload identity federated credentials and the Azure Monitor, Activity Log and Diagnostic Settings Guide.

• Apps with client secrets: count, trending down; target zero outside documented exceptions.
• Azure-hosted workloads on managed identity: percentage of workloads that meet Microsoft's four conditions and use one.
• Credential age and expiry: apps with credentials expiring in 30 days, and with credentials unused for 90 days.
• Orphaned role assignments: count of assignments to deleted principals, target zero.
• Ownership coverage: app registrations with at least one current owner, reviewed every few months.
• Broad roles on workload identities: Owner or Contributor at subscription scope held by service principals or managed identities, falling each quarter.

Common failure patterns

• Secrets kept "just in case". A workload moves to a managed identity but the old secret stays valid on the app registration for years. Delete it once sign-ins stop.
• One app registration for everything. A shared deployment app with Contributor on every subscription and secrets in several pipelines. Split by pipeline and use federated credentials.
• Federated credentials with loose subjects. Trust that matches any branch or any service account lets more workloads obtain tokens than intended.
• Managed identity with subscription-wide Contributor. Convenient during build, then never narrowed, so any code execution on the host becomes subscription control.
• Unreviewed owners. Former staff or guest accounts remain owners of app registrations and can add credentials.
• Orphaned role assignments and unused user-assigned identities. Left behind after resources are deleted, they clutter reviews and hide real access.

Where identity governance fits

Both object types are non-human identities and belong in the NHI inventory with an owner, purpose, credential type and review date. User-assigned identities and app registrations need explicit decommissioning because nothing deletes them automatically. See the Non-Human Identity (NHI) Guide, the NHI Offboarding and Decommissioning Guide and the Entra ID Applications and Consent Guide.

Framework mapping

Practitioner checklist

• List every app registration and legacy service principal with a secret or certificate, with owner and expiry.
• Apply Microsoft's four-condition test and move every qualifying workload to a managed identity.
• Move external pipelines and clusters to federated credentials with subjects pinned to repository, branch or service account.
• Replace remaining secrets with CA-issued certificates held in a key vault.
• Configure app management policies to restrict secret lifetimes or block secrets, and enforce trusted certificate issuers.
• Turn on app instance property lock for every app, multitenant ones first.
• Restrict Managed Identity Operator and Contributor roles, and scope every workload identity's roles to resources.
• Delete orphaned role assignments and unused user-assigned identities quarterly.
• Alert on credentials added to apps, federated credential changes and identity assignments.

Standards and references

• Microsoft Learn: What are managed identities for Azure resources?
• Microsoft Learn: Application and service principal objects in Microsoft Entra ID
• Microsoft Learn: Managed identity best practice recommendations
• Microsoft Learn: Security best practices for application properties
• Microsoft Learn: Workload identity federation
• Microsoft Learn: Add and manage application credentials
• NIST: SP 800-53 Rev. 5
• OWASP: Non-Human Identities Top 10 2025

Related NHI Mgmt Group resources: Azure Managed Identities Security Guide, Azure RBAC and Service Principals Guide, Entra ID Applications and Consent Guide, Cloud Workload Identity Guide, Secrets Management Guide.