Entra ID Workload Identities

Microsoft Entra Workload ID (sometimes called Workload Identities) is the product line for governing non-human identities in Entra ID: service principals, managed identities, applications, and the credentials they use. As organisations have migrated to the cloud, the count of non-human identities has exploded — and they're now a major attack surface.

Related: service principal best practices for how to build them, secret rotation for keeping them alive, over-consented permissions cleanup for right-sizing them, and — for the retired cloud-infrastructure product — Entra Permissions Management.

What counts as a workload identity

• Service principals — instances of applications in your tenant (every enterprise app has one).
• Managed identities — Entra-managed identities for Azure resources (Azure Functions, VMs, App Service).
• Workload identity federation trust relationships — credentials issued by external identity providers (GitHub Actions, AWS, GCP, Kubernetes) that your tenant trusts.
• Application credentials — client secrets, certificates, federated identity credentials.

Each is a sign-in target that an attacker can use.

Why this matters

Non-human identities tend to:

• Outnumber human identities by 10–50× in mature tenants.
• Have static credentials that don't rotate as often as user passwords.
• Hold broader permissions than they need.
• Not have MFA (most can't — they're not interactive).
• Get forgotten when the app or script that created them goes away.

A compromised service principal with overbroad Graph permissions can do enormous damage silently.

What Workload Identities provides

The product adds capabilities specifically for non-human identities:

• Conditional Access for workload identities — apply CA policies (location restrictions, risk-based blocking) to service principal sign-ins, not just users.
• Identity Protection for workload identities — detect compromised service principals, anomalous patterns, leaked credentials.
• Access reviews for workload identities — periodic recertification of which apps still need their permissions.
• Lifecycle workflows — automated handling of disused service principals.

Practical hygiene

For any Microsoft 365 tenant, basic workload-identity hygiene includes:

• Inventory enterprise apps regularly in entra.microsoft.com → Enterprise applications.
• Disable apps not in use — disabled service principals can't sign in.
• Restrict user consent — limit who can grant Graph permissions to third-party apps.
• Use certificate-based authentication rather than client secrets where possible — secrets leak; certificates are harder to mishandle.
• Use managed identities for Azure-hosted workloads — no credentials to manage at all.
• Use workload identity federation for GitHub Actions, AWS, GCP, Kubernetes — short-lived federated credentials rather than long-lived secrets.

Licensing

Workload Identities premium features require Microsoft Entra Workload ID Premium — a separate licence priced per workload identity (tiered free / standard / premium). The free tier covers basic visibility; premium adds Conditional Access for workload identities, risk detection, and access reviews.

For tenants with significant SaaS or custom-app footprint, Workload ID is increasingly part of the security baseline alongside human-identity protections.