Entra Workload ID: which identities need licences?

An automation application has permission to read company data through Microsoft Graph. An administrator adds it to a group protected by Conditional Access and expects it to connect only from the corporate network. Yet the application continues signing in from elsewhere. The cause may have nothing to do with a user exception: the application uses its own identity, and a policy assigned to a group is not enforced on its service principal.

Microsoft Entra Workload ID Premium is licensed according to the identities using premium features. It is not included in ordinary premium user plans, and licences are not assigned to individual identities as they are to employees. First check whether the selected feature supports that identity type. Buying another licence will not make an unsupported application a supported policy target.

This article covers application identities in a corporate Entra tenant. Licensing, Conditional Access scope, ID Protection and continuous access evaluation were checked against Microsoft documentation on 20 October 2026. The suggested records and numerical model are our proposed decision aids, not findings from a security audit of a particular company.

Identify who is signing in

The workload identities overview distinguishes applications, service principals and managed identities. An app registration describes an application; a service principal represents its identity in a particular directory. A managed identity is a special identity managed for the relevant service. Do not treat these terms as three automatically separate paid licences in your inventory.

An application acting on behalf of a signed-in person is different from an application making independent calls with its own application permissions. A service account created as an ordinary user remains a user identity. Calling an account a “robot” does not change its type.

For each data flow, record who requests the token, which resource it targets and whether it uses delegated user permissions or application permissions. Your own single-tenant application can call Microsoft Graph; Microsoft's operation of the target API does not turn the client into a Microsoft application excluded from this protection. Here, the relevant identity is the client service principal signing in.

Three features, different boundaries

“Protecting machine identities” is too broad a description for an order. The Workload ID FAQ and individual feature guides distinguish Conditional Access, risk detection and access reviews.

ID Protection for workload identities defines the scope of risk detections. Seeing a risk associated with a multitenant application does not establish that you can apply the same blocking policy as for your own single-tenant automation.

Managed identities are not excluded from every governance tool. The FAQ explicitly describes reviews of service principals assigned to privileged roles, including managed identities. For those reviews, assess Workload ID Premium for the identities reviewed and Entra ID P2 for reviewers. This does not establish managed identity support in Conditional Access.

One unlocking licence does not cover the whole tenant

The licensing FAQ makes two points together: licences are not individually assigned to workload identities, and one licence in a tenant can technically unlock features for all. It also requires the appropriate number of licences for identities using premium features. Availability in the portal is therefore not an inventory of entitlements.

Do not automatically budget for every Enterprise applications entry. Separate supported identities using premium features, other identities and any separate access reviews. Several policies for one service principal do not, by themselves, require several Workload ID licences for that identity.

Hypothetical example: a company records 40 workload identities and introduces the following scope. All features counted are supported for the relevant identities; this example excludes other products and the price of a particular offer.

Do not count the six identities using two features again: the result is not 21. Equally, one licence is insufficient merely because the portal lets you configure all policies. Nor does this proposal justify 40 licences without checking actual scope.

If you later include the five managed identities in a supported premium review of privileged assignments, the budget changes. Subject to the FAQ's conditions, add five Workload ID licences and separately verify the reviewers' P2 rights. Zero in the original table means no premium feature is used within that model, not that every managed identity activity is free.

Target the correct object

The Conditional Access guide requires policies to target service principals directly as workload identities. A group containing the principal does not replace this assignment. Use the Object ID from Enterprise applications, rather than the registration's Object ID in App registrations. These are different objects even if their display names match.

Block access is the available grant action in the blocking policy described. Do not plan interactive MFA as a solution for an unattended application. Define which requests should be blocked or allowed, then verify the service's actual public egress IP. The administrator's laptop IP may differ from the application's cloud egress.

Changing egress addresses require an operational design, rather than another arbitrary exception. Allowing a range that covers a substantial part of a public cloud can weaken the intended protection. Check stable egress, actual operation and appropriately limited application permissions before enabling enforcement.

Token issuance is not every API call

Conditional Access is evaluated here when the service principal requests a token. A successful policy change does not establish universal, immediate invalidation of every previously issued token across every service.

Continuous access evaluation for workload identities has additional prerequisites: a supported single-tenant identity, a client declaring the cp1 capability and claims challenge handling. Current documentation names Microsoft Graph as the only supported resource provider for this workload CAE scenario. Managed identities and third-party multitenant SaaS are outside its scope.

Test obtaining a new token, calling with an existing token and the client's response to a challenge separately. Automation that simply repeats a failed request can stop processing data after a security change even though the server correctly denies access. Verify completed work and controlled error reporting too.

A verifiable implementation procedure

1. Inventory client identities. Record the service principal Object ID, application type, owner, authentication method, target APIs and required permissions. Distinguish actual user service accounts.
2. Assign a specific feature. CA, premium risk reporting or a privileged access review. For each identity, check support before determining licensing scope.
3. Count distinct beneficiaries of premium features. Record overlaps so that the same principal is not counted again for every policy.
4. Start a limited Report-only pilot. Verify direct targeting, actual egress IPs and Service principal sign-ins results. This mode evaluates impact without blocking access.
5. Test permitted and prohibited sources. Record the time, client identity, applied policy and token issuance. Then check access to the target API.
6. Test existing tokens and CAE separately where used. Verify resource provider support, client capability declaration and claims challenge handling.
7. Prepare remediation and rollback. The application owner must distinguish policy blocks, invalid credentials and ordinary service outages. Rolling back a policy should not leave a compromised secret in use.

If your work has so far focused on employees and MFA, also review user Conditional Access licensing scope. Both inventories belong in the same security design, but use different counting units and support boundaries.