Entra Workload Identities Explained: Service Principals vs Managed vs Federated

I often get asked to explain what an Entra workload identity is, and what options are available when designing authentication for non-human access in Microsoft Entra ID. This post is intended as a practical guide to workload identities from an Entra perspective, focusing on what they are, how they work, and when to use each option.

We’ll cover the three core workload identity patterns available today:

• Service Principals
• Managed Identities
• Federated Workload Identities
  

This article focuses on understanding and choosing between them. In the next post, we’ll look at how to secure workload identities properly and avoid common pitfalls.

TLDR: I’ve created a quick summary table and flow chart at the end of the article for quick reference to help you decide which type of identity you should be using.

What is an Entra Workload Identity?

A workload identity is a non-human identity used by an application, service, script, or automation to authenticate to Entra ID and access resources such as Azure, Microsoft Graph, or SaaS services.

Unlike user identities, workload identities:

• Are designed for automation
• Authenticate programmatically
• Should follow least privilege principals
• Must be protected from credential theft and misuse
  

Choosing the right workload identity has a significant impact on your overall security posture.

Service Principals

Service Principals are the most traditional and widely used workload identity type. They are created through the Entra Application Registration process and represent an application or workload that needs access to resources.

A service principal defines what an application is allowed to do by assigning Entra roles, Azure RBAC roles, or application permissions.

Authentication Model

Service principals authenticate using one of the following:

• Client Secret (a long-lived password)
• Certificate (recommended over secrets)
  

To obtain an access token, the application presents:

• Client ID
• Tenant ID
• Client Secret or Certificate
  

If these values are valid, Entra ID issues an access token.

Whilst certificates are the preferred option, there is an inherent security risk we should address. When we create a certificate we generate a public and private key pair. We upload the public key to the service principal (app registration) and retain the private key somewhere secure – ideally somewhere like Azure KeyVault. I have seen several cases where the private key is uploaded to a local certificate store on a virtual machine. When this is added to the computer store, anyone that has access to the certificate has the same rights as the service principal creating a potential for a lateral movement attack.

Where It’s Used

Service principals can be used anywhere credentials can be supplied, for example:

• CI/CD pipelines
• Terraform or ARM/Bicep deployments
• Third-party SaaS integrations
• Custom-built applications
  

This flexibility is also their biggest weakness.

The Good and the Bad

Pros	Cons
✅ Works anywhere	❌ Secrets expire
✅ Very flexible	❌ Secrets leak (logs, repos, pipelines)
✅ Simple mental model	❌ Rotation is manual
	❌ Broad blast radius if compromised
	❌ Certificate management overheads

Service principals are the least secure of the three options. Where possible, they should be treated as a legacy approach and replaced with managed or federated identities.

---

Managed Identities

A managed identity is a specialised type of service principal that is fully managed by Azure and tightly bound to an Azure workload.

Azure handles:

• Identity creation
• Credential issuance
• Secret rotation
• Token lifecycle
  

There are two types of managed identity.

User-Assigned Managed Identity

A user-assigned managed identity is created as a standalone Azure resource.

Key characteristics:

• Can be assigned to multiple workloads
• Lifecycle is independent of the workloads
• Survives resource deletion
  

This makes them ideal when:

• Multiple resources need the same identity
• Permissions should be managed centrally
• You want consistency across workloads
  

System-Assigned Managed Identity

A system-assigned managed identity is created directly on an Azure resource.

Key characteristics:

• Tied to a single workload
• Automatically deleted when the resource is deleted
• Cannot be reused elsewhere
  

This is the best option when:

• The identity should live and die with the resource
• Permissions should be tightly scoped
• You want the smallest possible blast radius
  

Authentication Model

Azure automatically issues tokens to the workload via the Azure fabric.

There are no secrets, no certificates, and no manual rotation.

Examples:

• A virtual machine running a PowerShell script authenticates using its managed identity
• Azure Data Factory accesses Blob Storage via its managed identity
  

In both cases, no credentials are stored or passed around. Behind the scenes, a managed identity uses the Azure Instance Metadata Service (IMDS) endpoint to acquire access tokens from Entra ID.

Where It’s Used

Most Azure services now support managed identities. The official list is available in Microsoft Learn.

Rule of thumb:

• Use system-assigned when the identity should belong to exactly one resource
• Use user-assigned when multiple workloads need to share the same identity
  

The Good and the Bad

Pros	Cons
✅ No secret management	❌ Only works inside of Azure Workloads
✅ Identity can only be used by the Azure Workloads its assigned to	❌ Harder to reuse across multiple environments
✅ Cannot be exfiltrated	❌ Could grant significant access to anyone who has access to the underlying workload
✅ Very strong security posture

Managed identities should be your default choice for Azure-hosted workloads.

---

Federated Workload Identity

Federated Workload Identity (also called Workload Identity Federation) extends the managed identity model to non-Azure workloads.

The goal is to remove long-lived credentials by establishing a trust relationship between Entra ID and an external identity provider using OIDC.

For a practical implementation example, see my guide on Using Federated Workload Identities with Azure DevOps and Terraform.

Authentication Model

The flow can be simplified into three steps:

1. The external workload obtains an OIDC token from its own Identity Provider
2. Entra ID validates the token using a federated identity credential
3. Entra issues a short-lived access token for the service principal
   

At no point are secrets stored in the workload.

Where It’s Used

Federated identities work anywhere OIDC is supported, including:

• GitHub Actions
• Azure DevOps service connections
• AKS workloads
• Workloads running in AWS or Google Cloud
  

The Good and the Bad

Pros	Cons
✅ Secretless authentication	❌ Can be more complex to setup (although has improved over more recent years)
✅ Strong least-privilege	❌ Requires correct claims mapping
✅ Short-lived tokens	❌ Debugging auth failures can be complicated
✅ Not Azure-bound

This is the most secure option for non-Azure-hosted workloads.

---

Comparison Table

Identity type	Who issues the credential	Where it runs	Who manages secrets
Service Principal	You	Anywhere	You
Managed Identity	Azure	Azure only	Azure
Federated Identity	External IdP (OIDC)	Anywhere	Nobody stores secrets

Here is a simple visual flow to help you decide which identity type to use

---

Summary

Workload identities are a foundational security building block in Entra ID.

• Use managed identities for Azure workloads whenever possible
• Use federated identities for non-Azure workloads that support OIDC
• Treat service principals with secrets as legacy and phase them out
  

Choosing the right identity model dramatically reduces credential risk and improves your overall security posture.

No matter which identity you choose, follow these principles:

✅ One identity per workload – Avoid sharing identities across multiple applications or environments

✅ Least privilege access – Grant only the permissions required for the specific task

✅ Short-lived credentials – If using service principals, configure secrets to expire within 90 days or less

✅ Document ownership – Maintain an inventory of which team owns each workload identity

Next week we will look at ways to secure and monitor these identities.