The Identity Explosion: Why Workload Identities Matter

In most enterprise tenants I audit, the organization has no idea how many non-human identities exist. They count Azure AD users. They account for their service accounts. But they miss the real picture: service principals, managed identities, federated credentials, and legacy service accounts scattered across VMs, on-premises systems, and cloud infrastructure.

The industry rule of thumb is now 3–7 non-human identities per human user. In a 2,000-person organization with 2,000 licensed users, you're looking at 6,000–14,000 workload identities. Most of my clients discover this only when they're hit with a renewal spike they didn't plan for.

Microsoft Entra Workload Identity Premium is not cheap. At approximately £2.50–£3.00 per workload identity per month under EA commitment, a mid-market firm can suddenly face an extra £150,000–£300,000 per year in licensing costs they never budgeted. And unlike user licensing, workload identity pricing doesn't scale linearly with your business—it scales with your infrastructure complexity.

This article breaks down exactly what you're paying for, how to count correctly, and how to negotiate defensibly in your EA.

The Three Types of Workload Identity

Before we talk licensing, we need clarity on what constitutes a "workload identity" in Microsoft's definition. There are three primary categories, and they're often confused in enterprise environments.

1. Service Principals

A service principal is the instance of an application registered in your Entra ID tenant. When you register an app (e.g., a custom web app, an automation runbook, a third-party SaaS connector), you create an application object. That application object gets a service principal when it's instantiated in your tenant.

2. Managed Identities

Managed identities are Microsoft's answer to the secret management problem. Instead of storing credentials in configuration files or vaults, an Azure resource (VM, Function, Logic App, App Service) gets its own identity managed by Entra ID. No secrets to rotate; Azure handles the token lifecycle.

3. Federated Credentials & OIDC

Federated credentials allow external identity providers (GitHub Actions, GitLab CI, third-party systems) to authenticate directly to Azure without long-lived secrets. The external system proves its identity via OpenID Connect, and Entra ID trusts that identity.

What's Free vs. What Requires Workload Identity Premium

This is where most organizations get tripped up. Microsoft's free tier for workload identities is genuinely robust. But the moment you apply enterprise security controls, you hit the paywall.

Feature Free (Entra ID) Workload Identity Premium
Service Principals ✓ Create, authenticate, basic management ✓ Same + advanced controls
Managed Identities ✓ System-assigned and user-assigned ✓ Same + conditional access
Token Signing Certificates ✓ Automatic rotation ✓ Same
Federated Credentials / OIDC ✓ Set up and use ✓ Same
Conditional Access for Workloads ✗ Not available ✓ Required for policy enforcement
Identity Protection Signals ✗ Manual only ✓ Anomaly detection for compromised principals
Risk-Based Detection ✗ Not available ✓ Detects suspicious token use
Workload ID Health Dashboard ✗ Basic logging only ✓ Unified insights

The critical line: Conditional Access for service principals is premium-only. If you need to enforce policies like "this service principal can only authenticate from this subnet" or "only issue tokens during business hours," you need the premium license.

Workload Identity Premium Pricing and Unit Economics

Microsoft doesn't publish exact Workload Identity Premium pricing in the public price list—it's typically negotiated at EA time. But the market rate (as of March 2026) is approximately:

Let's do the math. A 2,000-person organization with 8 workload identities per user (moderate complexity) has 16,000 workload identities:

Scenario Count Monthly Cost Annual Cost
16,000 IDs @ £2.75/ID (standard) 16,000 £44,000 £528,000
16,000 IDs @ £2.00/ID (bulk EA) 16,000 £32,000 £384,000
Tenant-wide unlimited (negotiated) Unlimited £15,000–£25,000 £180,000–£300,000

The difference between per-unit and unlimited licensing is critical. If you're buying 16,000 IDs at £2.75 each, you're paying £528k annually. But if your CSR agrees to a tenant-wide commitment at £250k/year, you're breaking even at 6,061 identities—and you get unlimited growth above that with no additional cost.

Conditional Access for Workload Identities: The Primary Premium Driver

Conditional Access is the feature that moves workload identity licensing from "nice to have" to "you need this." And it's where most enterprises discover they're underestimating their security posture.

What Conditional Access Enables for Workloads

For any organization with serious zero-trust aspirations, Conditional Access on workload identities is non-negotiable. If a developer account is compromised, an attacker can pivot to service principals and assume the service principal's permissions. Conditional Access prevents lateral movement by restricting when and where those principals can act.

Common Mistake: Many organizations implement Conditional Access policies targeting user sign-in but exclude service principals. This creates a compliance gap. If your policy says "MFA for all sign-in," you need to audit whether that policy applies to workload identities. If not, you're licensing blindly.

Identity Protection for Workload Identities

Workload Identity Premium adds anomaly detection at the token level. If a service principal's token is being used from an unusual location, at an unusual time, or with unusual API calls, the system can flag it—or even block it—automatically.

Risk Signals Covered

Identity Protection doesn't replace secrets management or role-based access control. But it adds a crucial detection layer. For a compromised service principal, Identity Protection can alert you within seconds of the first suspicious token use.

The Discovery Challenge: How to Count Your Workload Identities

Before you can license correctly, you need an accurate count. And here's the problem: most organizations have no idea how many workload identities they actually have.

Where Workload Identities Hide

App Registrations (Entra ID → App registrations)

These are the obvious ones. You can count them directly in the Azure portal. But many organizations have deprecated apps still registered, test applications, and one-off integrations that clutter the count.

Enterprise Applications (Entra ID → Enterprise applications)

Every SaaS app your organization has ever provisioned (Slack, Salesforce, Datadog, etc.) creates a service principal in your tenant. You might have licensed the user accounts but not budgeted for the principal itself.

Managed Identities (distributed across Azure resources)

System-assigned managed identities on Azure VMs, Functions, Logic Apps, and App Services. If you have 500 VMs with system-assigned identities, that's 500 managed identities. Most organizations don't have a central inventory of these.

Service Accounts (on-premises and hybrid)

Legacy service accounts on Windows servers, SQL Server, and application servers. If your organization has synchronized these to Entra ID (via Azure AD Connect or Entra Cloud Sync), they count as workload identities.

Discovery Process

Here's how I audit a tenant:

  1. App Registrations count: Export from Entra portal → filter out deprecated
  2. Enterprise Apps count: Total minus user accounts and groups
  3. Managed Identities: Query Azure Resource Manager for system-assigned across all subscriptions; count user-assigned from Key Vaults and resource groups
  4. Service Accounts: Query Active Directory for accounts with servicePrincipalName attributes; check Azure AD Connect sync rules
  5. Federated Credentials: Audit each service principal for OIDC configurations
Pro Tip: Use Azure CLI or PowerShell to automate this. Microsoft Graph API provides Get-MgServicePrincipal and Get-MgManagedIdentity queries. A single script can give you accurate counts in 10 minutes.

Typical Counts by Organization Size

Organizations with mature CI/CD pipelines (GitHub Actions, Azure DevOps, GitLab), multi-tenant applications, or heavy Azure automation tend toward the higher end.

Managed Identities vs. Service Principals: The Cost Optimization Play

Here's a strategic licensing insight most organizations miss: if you're building new infrastructure, managed identities are your primary lever for cost reduction.

When Each Is Used

Service Principals:

Managed Identities:

The Cost Optimization Play

If you're currently using a service principal for a job that's running on an Azure VM, you can migrate to a system-assigned managed identity. The cost-per-workload-identity doesn't change, but you reduce the attack surface and eliminate credential rotation.

For new projects: mandate managed identity-first architecture. You still need Workload Identity Premium for Conditional Access and Identity Protection, but you control identity sprawl by design.

EA Negotiation Strategy: Getting the Best Rate

Workload Identity Premium is one of the few Microsoft security products where the unit economics are negotiable. Here's how to approach your EA renewal.

Step 1: Conduct a Real Audit

Before you talk to your CSR, run the discovery process above. Get your actual count—not an estimate. If you're off by 50%, your commitment will be wrong.

Step 2: Understand Your Options

Step 3: Benchmark Against Entra Bundle Options

If you're licensing Entra ID P1 or P2 for users, ask your CSR whether bundling Workload Identity Premium offers a discount. Some customers can negotiate better rates by committing to a larger security suite.

Step 4: Negotiate Phased Deployment

If your discovery reveals you have 20,000 workload identities but you're only applying Conditional Access to 8,000 in Year 1, propose:

This can reduce your first-year commitment and give you negotiating leverage in renewals.

EA Negotiation Insight: Microsoft's Workload Identity Premium sits at an interesting price point. It's expensive enough to matter ($3m+/year at 20k IDs), but not so expensive that it moves the needle on overall EA commitment. Use this to your advantage. If your org is worth $5m+ annually to Microsoft, a better Workload Identity Premium rate is often the easiest concession to win.

Common Mistakes in Workload Identity Licensing

After 20 years of licensing audits, I see the same five mistakes repeatedly. Here's how to avoid them.

Mistake 1: Applying Conditional Access Policies Without Licensing

You create a Conditional Access policy targeting "all users and service principals." It works fine for 3 months. Then an attacker uses a service principal to move laterally, and you realize the policy wasn't enforced. Microsoft doesn't block the policy; it just doesn't apply to unlicensed workload identities.

Fix: Audit every Conditional Access policy. For each policy that targets service principals, verify Workload Identity Premium is licensed for all affected principals.

Mistake 2: Double-Counting Service Principals

You count app registrations as service principals. But you also count enterprise applications. And some apps appear in both lists. Suddenly your count is 30% too high, and your EA commitment is bloated.

Fix: Distinguish between service principal instances (the actual object in your tenant) and application objects (the definition). One app registration can have multiple service principal instances (multi-tenant). Count the instances, not the definitions.

Mistake 3: Ignoring Service Accounts That Are Synced to Entra ID

You have 200 service accounts on Windows servers. They're synchronized to Entra ID via Azure AD Connect. Microsoft counts them as workload identities. You didn't, so your count is off by 200.

Fix: Query Entra ID for all user objects with servicePrincipalName attributes. These are hybrid service accounts.

Mistake 4: Committing to Per-ID Pricing When Unlimited is Better

You think you have 10,000 workload identities. Your CSR quotes £2.50 per ID: £300k/year. But a month in, you discover you actually have 18,000 IDs. Your commitment is suddenly £540k/year. Meanwhile, the CSR could have offered you tenant-wide unlimited for £250k/year.

Fix: Run discovery first. If your count is uncertain, negotiate unlimited instead of per-unit. The risk of overcommitting is higher than the cost of unlimited.

Mistake 5: Not Clarifying MACC Interaction

You're buying a 3-year Defender E5 bundle (which includes MACC). You assume Workload Identity Premium is included in the MACC. Your CSR says it's additive. Now you've committed to £400k extra by mistake.

Fix: Get the MACC entitlement document in writing. List what's included (Defender, Entra ID P2, DLP, etc.) and what's not. Workload Identity Premium coverage varies by MACC agreement.

FAQ: Workload Identity Licensing

Do I need Workload Identity Premium if I only have a few service principals?
It depends. If those service principals never need Conditional Access policies, you don't need the premium license. But if you're enforcing zero-trust (and you should be), you need it. The break-even point is usually around 100–200 principals, where the cost of unlicensed Conditional Access violations exceeds the licensing cost.
Do managed identities count the same as service principals for licensing?
Yes. Both count as "workload identities" for licensing purposes. The difference is in risk profile (managed identities are lower-risk) and operational overhead (managed identities require no credential management), not cost.
Can I negotiate tenant-wide unlimited licensing in a mid-market EA?
Yes, but it's not automatic. If your organization spends $5m+/year on Microsoft, unlimited licensing is often negotiable at a lower all-in cost than per-ID licensing. If you spend $1–2m/year, it's rare but possible if you can justify growth to the CSR.
What happens if I use Conditional Access on service principals without licensing?
The policy creates successfully. It shows as "enabled." But it silently doesn't enforce for unlicensed workload identities. You won't get an error message. The principal simply authenticates as if the policy doesn't exist. This is a compliance and security risk.
How often do I need to re-audit my workload identity count?
At least annually, and again 6 months before your EA renewal. If you have rapid cloud adoption, quarterly is better. Workload identities grow organically with CI/CD pipeline expansion and cloud-native architecture adoption. One unplanned SaaS integration can add 50+ principals overnight.

Need Help Licensing Workload Identities Correctly?

We've negotiated Workload Identity Premium for 500+ organizations. Whether you're auditing your current estate, preparing for renewal, or rebuilding your identity architecture, we can help you get it right—and negotiate the rate that reflects your organization's size and cloud maturity.

Request a Security Licensing Review Download Security Licensing Guide

Related Reading