Conditional Access for Workload Identities in Entra ID

A stolen client secret or certificate for an Entra ID service principal works from anywhere on the internet, because the service principal cannot do MFA and most tenants apply no Conditional Access to it at all. Conditional Access for workload identities closes part of that gap: it lets you block a service principal's token requests unless they come from named network locations, or when Entra ID Protection rates the service principal as risky. This guide covers what the feature does and does not cover, licensing, how to design location and risk policies, how to roll them out in report-only mode without breaking pipelines, continuous access evaluation, monitoring, and the controls you still need for the identities it cannot reach. It is for identity engineers, cloud platform teams and security architects who own Entra ID tenants. Finding and removing unused service principals first is covered in How to find and remove stale service principals in Entra ID.

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

It applies to single-tenant service principals you own. Managed identities, multitenant apps and Microsoft or third-party SaaS apps are out of scope, so plan other controls for them.
Block is the only grant control. Policies say "block this service principal unless it signs in from these locations" or "block it when its risk is high"; there is no MFA or device equivalent.
Assign service principals directly. Policies assigned through a group containing a service principal are not enforced for that service principal, so target each workload identity explicitly, or use all service principals in the tenant with exclusions.
Licensing is tenant-level. Creating or modifying these policies needs Workload ID Premium; Microsoft's FAQ states that one licence in the tenant unlocks the features for all workload identities.
Start in report-only and use the service principal sign-in log. Each sign-in's Conditional Access tab shows what a policy would have done, which is how you find the pipeline egress addresses you forgot.

Why workload identities need their own policies

Microsoft's documentation describes three reasons workload identities are harder to secure than users: they cannot perform multifactor authentication, they often have no formal lifecycle process, and they need to store their credentials or secrets somewhere. A client secret copied from a pipeline variable, a certificate exported from a build agent, or a credential added to an app registration by an attacker (ATT&CK T1098.001 Additional Cloud Credentials) can be used from any network to request tokens for Microsoft Graph, Azure Resource Manager or your own APIs. User Conditional Access policies do not evaluate these sign-ins.

Most service principals run from a small set of places: a CI/CD runner pool, an on-premises integration server, a set of Azure subnets with fixed NAT egress. That predictability is what makes network-based policy effective for workloads, often more so than for people, who travel and change networks.

What the feature covers

Workload identity type	Conditional Access for workload identities	ID Protection risk detections	Use instead or as well
Single-tenant app registration's service principal in your tenant	Yes	Yes	Federated credentials instead of secrets
Multitenant app (yours or a vendor's) consented into your tenant	No	Yes	Permission review, consent policy, app management policies
Microsoft first-party apps	No	No	Permission and consent governance
Managed identities	No	No	Least-privilege role assignments and access reviews for privileged roles

Conditions: Locations and Service principal risk. Authentication contexts can also be combined.
Grant: Block access only.
Licensing: Workload ID Premium is a standalone product, not part of other premium plans. Microsoft's FAQ lists it at USD 3 per workload identity per month, offers a 90-day trial (30 days in the Modern channel, not in Azure Government), and states that licence assignment is not required. Without the licence, existing workload identity policies keep working but cannot be modified. Prices change, so confirm on Microsoft's current pages.
Role: at least Conditional Access Administrator to create policies.

For managed identities, see the Azure Managed Identities Security Guide; for multitenant app exposure, see How to find multi-tenant Azure app registrations.

Designing location policies

Build the named locations

Named locations live under Entra ID, Conditional Access, Named locations and hold IPv4 ranges, IPv6 ranges or countries. Microsoft documents limits of 195 named locations per tenant and 2,000 IP ranges per named location, with only CIDR masks greater than /8 allowed. The address that matters is the public egress address, not the private address of the host.

Workload source	What to put in the named location	Watch out for
Self-hosted CI/CD runners	The NAT gateway or firewall egress addresses of the runner network	Runners added in a new region or subnet with different egress
Vendor-hosted CI/CD runners	The provider's published ranges only if you accept every tenant of that provider; better, move to self-hosted runners with fixed egress	Shared ranges admit other customers' jobs
Azure workloads	NAT gateway public IPs or firewall egress for the subnets	Default outbound access changing addresses; fix egress with a NAT gateway
On-premises integration servers	Data centre internet egress ranges	Failover to a secondary ISP
Partner-run integration using your app	The partner's documented egress, agreed in the contract	Partner changes provider without notice

One named location per workload family: "CI runners egress", "Integration servers egress". Avoid one large "trusted" location for everything, because a service principal should be allowed only where it actually runs.
Do not reuse user trusted locations blindly: an office range marked trusted for users may contain laptops that should never present a production service principal's secret.
Countries are a weak control for workloads: a cloud region in an allowed country still serves any attacker who rents a VM there. Prefer IP ranges.

Policy patterns

Pattern	Include	Exclude	Condition	When to use
Per-workload lock	Select service principals: one app's service principal	None	Locations: Any location, exclude that workload's named location	High-privilege service principals such as deployment identities with Owner or Graph application permissions
Tier lock	Select service principals: a list of production pipeline identities	None	Locations: Any location, exclude CI runner egress	Many identities sharing one runner pool
Tenant-wide baseline	All owned service principals (`ServicePrincipalsInMyTenant`)	Named exceptions under review	Locations: Any location, exclude all approved egress locations	Mature tenants with a complete egress inventory
Risk block	All owned service principals	Break-glass automation, if any	Service principal risk: High (and Medium once tuned)	Every tenant with the licence

In every pattern the target resource is All resources and the grant is Block access. The service principal is identified by its Object ID from Enterprise apps; Microsoft warns that the Object ID shown in App registrations is the application object, not the service principal, and will not work.

Microsoft Graph definition

For policy as code, Microsoft's documentation shows the policy using conditions.clientApplications.includeServicePrincipals (an Object ID or ServicePrincipalsInMyTenant) and excludeServicePrincipals, conditions.locations.excludeLocations (a named location ID or AllTrusted), includeApplications: ["All"], and grantControls.builtInControls: ["block"]. Its sample uses the beta endpoint. Set state to enabledForReportingButNotEnforced for report-only. Manage these definitions in source control so a change to an allowed range goes through review. See How to find service accounts excluded from MFA and Conditional Access for auditing exclusions afterwards.

Risk-based policies and ID Protection

Entra ID Protection evaluates service principals offline and lists them under ID Protection, Risky workload identities. Detections documented for workload identities include:

Detection	What it indicates	Typical response
Leaked Credentials	A valid credential found, for example in public code	Add a new credential, remove the leaked one, review recent sign-ins
Suspicious Sign-ins	Unusual IP, ASN, resource, user agent, country or credential type against a 2 to 60 day baseline	Check against the egress inventory; confirm or dismiss
Anomalous service principal activity	Unusual administrative behaviour such as suspicious directory changes	Review audit logs for role, credential and permission changes
Suspicious API Traffic	Abnormal Graph traffic or directory enumeration	Treat as possible reconnaissance or exfiltration
Microsoft Entra threat intelligence	Activity matching known attack patterns	Investigate as an incident
Malicious application and Suspicious application	Microsoft disabled, or may disable, the app for terms of service violations	Remove consent and investigate the owner
Admin confirmed service principal compromised	An administrator selected Confirm compromised	Feeds the risk policy and remediation

A risk policy uses Conditions, Service principal risk, Configure Yes, and the levels that should trigger a block. Start with High, review Medium detections for a month, then decide. Without Workload ID Premium, tenants still receive detections but with limited detail and cannot use risk-based access controls. Microsoft's documented remediation is to inventory the identity's credentials, add a new one (it recommends X.509 certificates), remove the compromised ones (all of them if in doubt), and rotate any Key Vault secrets the service principal can read. See the Microsoft Entra ID Protection guide.

Continuous access evaluation for workload identities

A normal access token stays valid until it expires, so a blocked service principal may keep working for a while. Continuous access evaluation (CAE) for workload identities closes that window for Microsoft Graph:

Revocation events: service principal disabled, service principal deleted, and high service principal risk.
Policies enforced in real time: location and risk.
Opt-in: the application declares the cp1 client capability in the token request's claims parameter and must handle a 401 claims challenge by requesting a new token. Without cp1 it receives neither challenges nor CAE tokens.
Token lifetime: CAE tokens for workload identities can last up to 24 hours. If the IP seen by Entra ID and by Graph differ, for example behind a split tunnel or proxy, Entra ID issues a one-hour CAE token and does not enforce location changes during it.
Scope: Microsoft Graph only, single-tenant service principals only, no managed identities.

Ask application teams to enable cp1 in the authentication library for high-privilege Graph clients; it turns a disable or a location policy into near-immediate enforcement.

Rolling it out

Clean up first: remove unused service principals and credentials so you are not writing policy for identities nobody owns. Move pipelines from secrets to federated credentials where possible; see How to replace Azure app secrets with federated credentials.
Collect egress evidence: export 30 days of service principal sign-ins (Entra ID, Monitoring and health, Sign-in logs, Service principal sign-ins) and group by service principal and IP address. Agree each range with the owning team.
Create named locations per workload family from that evidence.
Pilot in report-only: create a per-workload policy for two or three high-privilege service principals with state Report-only, then check the Report-only tab in the sign-in report or the Conditional Access Insights and Reporting workbook for sign-ins that would have been blocked.
Enforce the pilot after at least one full release cycle with no unexpected report-only blocks, then add the risk policy at High.
Expand by tier, then consider the tenant-wide baseline with exclusions tracked as exceptions with expiry dates.
Roll back by disabling the policy or returning it to report-only. Microsoft documents deleting or disabling the policies as the way to roll back. Keep a runbook entry so on-call engineers can do it when a pipeline breaks at night.

A blocked service principal fails with "Access has been blocked due to Conditional Access policies" in the sign-in log; the Entra Service Principal Sign-In Errors Guide covers how to read related errors.

Decision guidance

Location policy or federated credentials: they solve different problems. Federated credentials remove the stored secret; location policy limits where any credential can be used. Do both for high-privilege identities; if you can only do one, federation removes more risk for pipelines, and location policy is the quicker win for legacy apps that must keep a secret.
Per-workload or tenant-wide: per-workload policies are precise but grow in number; a tenant-wide baseline with exclusions scales better once the egress inventory is complete. Most tenants run both: tight per-workload locks for the top identities and a broad baseline.
Small tenants: lock the handful of deployment and Graph-privileged service principals to known egress and add the High risk block. That alone covers the most damaging cases.
Large tenants: manage policies as code, require an egress declaration when an app registration is created, and review exclusions quarterly.

Detection and measurement

Send service principal sign-ins and workload identity risk to your SIEM through Entra diagnostic settings. Risk data uses the categories RiskyServicePrincipals and ServicePrincipalRiskEvents, queried in Log Analytics as AADRiskyServicePrincipals and AADServicePrincipalRiskEvents; service principal sign-ins land in AADServicePrincipalSignInLogs. Log Analytics only holds events streamed after export is turned on, so enable it before you need it. See the Entra ID Sign-In and Audit Log Detection Guide.

Signal	Why it matters	ATT&CK
Service principal sign-in blocked by Conditional Access	A credential used from an unapproved network: misconfiguration or theft	T1078.004 Cloud Accounts
Credential added to an application or service principal	Attackers add secrets to existing apps to persist	T1098.001 Additional Cloud Credentials
Conditional Access policy or named location modified	Widening a range can silently undo the control	T1078.004 Cloud Accounts
Leaked Credentials detection	Secret exposed in code or files	T1552.001 Credentials In Files
Graph token used from an unexpected IP after a successful sign-in	Possible token theft and replay	T1550.001 Application Access Token

Credential additions are covered step by step in How to detect new credentials added to an app registration.

Metrics

Coverage: percentage of high-privilege single-tenant service principals under an enforced location policy.
Blocked attempts: service principal sign-ins blocked by Conditional Access per month, each triaged as misconfiguration or suspected theft.
Exception age: number of service principals excluded from the baseline for more than 90 days.
Risk response time: hours from a High workload identity risk detection to credential rotation.
CAE adoption: percentage of Graph-privileged clients requesting tokens with cp1.

Common failure patterns

Targeting a group: the policy shows the service principal in a group but never enforces. Assign the service principal directly.
Using the App registration Object ID: the policy targets the application object and does nothing. Use the Enterprise apps Object ID.
Allowing a cloud provider's whole range: anyone who rents compute there passes. Use your own NAT egress.
Assuming managed identities are covered: they are not; govern their role assignments directly.
Enforcing without report-only: a forgotten disaster recovery runner or a second region breaks deployments at the worst time.
Location policy instead of hygiene: an attacker who compromises a runner inside the allowed range still passes. Combine location policy with federation, least privilege and credential monitoring.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	CIS Controls v8.1
Location-based block for service principals	AC-3 Access Enforcement, IA-9 Service Identification and Authentication	PR.AA-05	Control 6 Access Control Management
Risk-based block and remediation	SI-4 System Monitoring	DE.AE-02	Control 13 Network Monitoring and Defense
Workload identity inventory and ownership	AC-2 Account Management	PR.AA-01	Control 5 Account Management
Sign-in and risk log export	AU-6 Audit Record Review, Analysis, and Reporting	DE.CM-03	Control 8 Audit Log Management

Practitioner checklist

Confirm Workload ID Premium is active in the tenant before designing policies.
List single-tenant service principals by privilege and pick the top ones for the pilot.
Build named locations from 30 days of service principal sign-in evidence, one per workload family.
Assign service principals directly by Enterprise apps Object ID, never through groups.
Run each policy in report-only for at least one release cycle, then enforce.
Add a High service principal risk block for all owned service principals.
Ask Graph-privileged applications to declare cp1 for continuous access evaluation.
Export service principal sign-ins and workload identity risk to the SIEM and alert on blocks and credential additions.
Govern managed identities and multitenant apps with role reviews and consent controls, since policies do not reach them.
Document the rollback (disable or report-only) in the on-call runbook.

Conditional Access for Workload Identities: Locking Service Principals to Known Networks and Risk