Conditional Access for Workload Identities: How to Protect Service Principals in Microsoft Entra ID

The Gap Most Identity Programs Miss

Security teams usually get serious about protecting users long before they get serious about protecting workloads.

Human identities get MFA, sign-in risk policies, device compliance checks, and Privileged Identity Management. Service principals often get none of that. They are created for automation, granted broad permissions, and then left alone for months or years.

That is a problem because modern cloud attacks do not only target users. They target non-human identities too. A compromised service principal can read mailboxes, provision infrastructure, access Microsoft Graph, or move laterally across subscriptions without ever triggering the same friction a user would face.

If your tenant relies on app registrations, automation accounts, CI/CD service principals, or line-of-business applications, you need controls at the workload identity layer. Conditional Access for workload identities is one of the most useful controls Microsoft has added for that purpose.

This guide explains what it is, when it helps, where it does not help, and how to deploy it without breaking production automation.

If you are newer to Conditional Access in general, start with the broader [Microsoft Entra ID Conditional Access setup guide](/blog/microsoft-entra-id-conditional-access-setup). This article focuses only on service principals and workload identities.

What Conditional Access for Workload Identities Actually Does

Conditional Access for workload identities extends Conditional Access beyond users and applies policy decisions to service principals owned by your tenant.

In practical terms, it lets you block token requests from selected workload identities based on:

• Location
• Service principal risk

This is not the same thing as traditional user Conditional Access. Workload identities cannot do MFA, cannot satisfy an authentication strength, and do not have a device posture in the same way a user session does. So the policy surface is narrower, but still useful.

Think of it as a control for answering questions like:

• Should this automation account be allowed to request tokens from any IP on the internet?
• Should this service principal continue working if Microsoft flags it as risky?
• Can I create a safety boundary around a high-privilege app registration without rewriting the app?

For many organizations, the answer should be no, no, and yes.

What Counts as a Workload Identity Here

In Microsoft Entra, workload identities include applications, service principals, and managed identities. But Conditional Access for workload identities does not cover all of them equally.

Supported

• Single-tenant service principals registered in your tenant
• Line-of-business application service principals

Not supported or limited

• Managed identities are not covered by Conditional Access for workload identities
• Third-party SaaS and multitenant apps are out of scope
• Group assignment does not enforce policy for service principals, even if the service principal is in the group

That last point matters a lot. For user policies, teams often rely on group-based targeting. For workload identities, you need to assign the service principal directly.

Why This Matters in Real Environments

Here are the common patterns where this capability creates real value.

1. High-Privilege Automation Accounts

A service principal that manages Azure resources, reads Microsoft Graph, or handles tenant-wide automation can be a high-impact target. If its credentials leak, the attacker gets the privileges of the app, not the privileges of a human user. Blocking token requests from unapproved IP ranges can reduce the blast radius significantly.

2. Legacy Apps with Broad Graph Permissions

Many older enterprise apps have accumulated permissions over time. They may still be important to the business, but nobody wants to re-architect them this quarter. Conditional Access for workload identities gives you a compensating control while you clean up the design.

3. Service Principal Risk Response

If Microsoft Entra ID Protection flags a workload identity as risky, you want a policy path that can respond quickly. Risk-based blocking gives you that.

4. Non-Human Identity Governance

This also fits naturally into a broader non-human identity program. If you already care about secret sprawl, stale service principals, and excessive permissions, this is one more layer in the stack. Our [non-human identities guide](/blog/non-human-identities-nhi-ai-agent-security-2026) goes deeper into the strategic side.

Licensing and Prerequisites

Before you spend time designing the policy, check the basics.

Required licensing

You need Microsoft Entra Workload Identities Premium to create or modify Conditional Access policies scoped to service principals.

Administrative permissions

At minimum, use an account with a role such as:

• Conditional Access Administrator

Operational prerequisites

• The service principal must be owned by your tenant
• You should know exactly what the application does and from where it normally requests tokens
• You should have sign-in log visibility before rollout

If you do not already monitor service principal sign-ins, set that up first. Creating blocking policies without a visibility baseline is a good way to surprise yourself.

Before You Touch Policy: Baseline the App

The biggest mistake teams make is treating workload identities like users and applying policy based on assumption instead of evidence.

Before rollout, answer these questions for each candidate service principal:

1. What business function does it support?
2. What Azure resources or Microsoft Graph permissions does it have?
3. From which IPs or environments does it usually request tokens?
4. Does it run in one region, one datacenter, one build agent pool, or from multiple sources?
5. Who owns it operationally?
6. What breaks if it stops working for 30 minutes?

If you cannot answer those questions, do not start with block mode.

The Two Main Policy Types

Microsoft currently gives you two practical policy models for workload identities.

1. Location-Based Policies

This is the most immediately useful one for many teams.

You define where the service principal is allowed to request tokens from and block everything else.

This works well for:

• Self-hosted automation runners with stable public IPs
• Internal data center apps
• Known egress NAT gateways
• Highly predictable app-to-app integrations

This works poorly for:

• Workloads running from constantly changing public IP ranges
• Distributed automation across many environments
• Teams that do not own stable network egress

Example use case

A Terraform deployment service principal should only authenticate from your CI/CD egress IPs. If someone copies its credentials and tries to use them from a laptop or unknown cloud host, token acquisition gets blocked.

2. Risk-Based Policies

This policy blocks the service principal if Microsoft Entra ID Protection detects workload identity risk.

This is useful because it gives you an identity-driven kill switch when Microsoft sees evidence that the service principal may be compromised.

It is not a replacement for least privilege, but it is a meaningful backstop.

Step-by-Step: Create a Location-Based Policy

Use this pattern for your first production rollout because it is easy to reason about and easy to validate.

Step 1: Pick one low-risk pilot app

Do not start with the service principal that deploys your entire production platform. Pick an app that matters, but will not create a major incident if you need to roll back.

Step 2: Identify approved source IP ranges

Document the real outbound IPs for the workload. Do not guess. Pull them from:

• Existing firewall logs
• Service principal sign-in logs
• NAT gateway or proxy configuration
• CI/CD runner documentation

Step 3: Create named locations if needed

In Entra, define the approved IP ranges as named locations if they are not already configured.

Step 4: Create the Conditional Access policy

At a high level:

1. Go to Entra ID > Conditional Access > Policies
2. Select New policy
3. Under Users or workload identities, choose Workload identities
4. Include the specific service principal directly
5. Under Target resources, include All resources
6. Under Conditions > Locations, include Any location
7. Exclude the named locations you trust
8. Under Grant, choose Block access
9. Start in Report-only

What this policy does

It blocks token requests for that service principal from anywhere except the locations you have explicitly allowed.

That is a clean and understandable control. It is also one of the easiest to audit later.

Step-by-Step: Create a Risk-Based Policy

Use this on service principals where identity risk would justify immediate containment.

High-level flow

1. Create a new Conditional Access policy
2. Scope it to Workload identities
3. Include the selected service principal directly
4. Target All resources
5. Under Conditions > Service principal risk, enable the policy condition
6. Select the risk levels you want to act on
7. Set Grant to Block access
8. Start in Report-only if possible

This type of policy is especially valuable for apps with broad permissions, such as Graph write access, Exchange automation, or infrastructure control paths.

Report-Only Mode Is Not Optional

For user Conditional Access, many teams already know that report-only mode is the safe starting point. For workload identities, it is even more important.

A blocked user usually opens a ticket.

A blocked workload identity may silently stop:

• Provisioning resources
• Syncing data
• Creating users
• Sending mail
• Rotating secrets
• Running nightly jobs

That means your first rollout should almost always be:

1. Report-only
2. Observe for several days
3. Validate expected behavior with the application owner
4. Move to enforcement

Do not rush that sequence.

How to Validate the Policy

After the policy is in report-only mode, use Service principal sign-in logs to confirm how it behaves.

Look for:

• Whether the policy evaluated for the correct service principal
• Whether the location condition would have blocked legitimate traffic
• Whether the traffic pattern is broader than you expected
• Whether the app is using the right identity at all

This step often uncovers forgotten dependencies. Sometimes the service principal you thought was used only by one job is actually used by three unrelated workflows.

Continuous Access Evaluation for Workload Identities

This is where things get more interesting.

Continuous Access Evaluation, or CAE, for workload identities improves how quickly access decisions are enforced after conditions change. Instead of relying only on standard token lifetime behavior, CAE can react faster to events like:

• Service principal disable
• Service principal delete
• High service principal risk

There are important limits to understand:

• CAE for workload identities currently supports service principals
• It does not currently support managed identities
• It currently applies to access requests sent to Microsoft Graph as a supported resource provider

That means CAE is powerful, but not universal. You should treat it as an enhancement to your control model, not as a blanket replacement for other security design decisions.

Why CAE matters

Without CAE, a compromised app may keep working until its current access token expires. With CAE-capable scenarios, revocation can take effect much faster.

If your app talks heavily to Microsoft Graph, this is worth understanding and enabling correctly.

Common Mistakes That Cause Pain

Assuming group targeting works

It does not for enforcement in this scenario. Assign the service principal directly.

Blocking without baselining

If you do not know the workload's normal IP ranges, your first enforced policy is guesswork.

Forgetting ownership

Every service principal should have a clear human owner. If something breaks, you need to know who can validate expected behavior quickly.

Applying policy to the wrong object ID

Use the service principal object ID from Enterprise Applications, not the app registration object ID.

Treating managed identities the same way

Managed identities are important, but this specific policy capability does not cover them. Do not design around support that is not there.

Starting with mission-critical automation

Pilot first. Production outage stories are made from identity changes applied too broadly and too early.

How This Fits with PIM, Break Glass, and Federation

Conditional Access for workload identities is not a standalone solution. It is one layer.

Pair it with PIM for humans

Your human admins should still use just-in-time elevation. Workload identity policies protect apps. [PIM](/blog/microsoft-entra-id-pim-privileged-identity-management-guide) protects privileged humans.

Pair it with break glass planning

If a workload identity policy causes unexpected admin impact, you still need resilient recovery paths. Your [break glass accounts](/blog/entra-id-break-glass-account-setup-monitoring) are part of that resilience model.

Pair it with workload identity federation

Conditional Access for workload identities helps protect token requests. It does not eliminate the need to reduce credential risk in the first place. For CI/CD and external workloads, use federation where possible instead of long-lived secrets.

A Practical Rollout Plan

If you want to introduce this capability without creating chaos, use this sequence:

1. Inventory high-privilege service principals
2. Rank them by permission level and business criticality
3. Pick one pilot with stable source IPs
4. Create a report-only location policy
5. Review service principal sign-in logs for at least several days
6. Validate with the app owner
7. Move to enforcement
8. Add a risk-based policy for the most sensitive apps
9. Document owners, source ranges, and rollback steps
10. Review quarterly

This is not glamorous work, but it is exactly the sort of identity hygiene that prevents ugly cloud incidents.

Final Checklist

Use this before enforcing any policy:

• [ ] The app is single-tenant and owned by your tenant
• [ ] You have the correct service principal object ID
• [ ] You know the app owner
• [ ] You know the normal source IP ranges
• [ ] You tested in report-only mode
• [ ] You reviewed service principal sign-in logs
• [ ] You documented rollback steps
• [ ] You confirmed the app is not using a managed identity for the targeted flow

Frequently Asked Questions

Can Conditional Access be applied to service principals?

Yes. Microsoft Entra supports Conditional Access for workload identities, which applies policy to service principals owned by your tenant.

Does this work for managed identities?

No. Managed identities are not currently covered by Conditional Access for workload identities.

Can I target a group that contains service principals?

Do not rely on that. Policies for workload identities must be assigned directly to the service principal for enforcement.

What conditions are most useful?

For most teams, location-based policies are the easiest and safest starting point. Risk-based policies are also useful for sensitive apps.

What is the difference between Conditional Access for workload identities and CAE?

Conditional Access defines the policy decision. Continuous Access Evaluation helps enforce certain access changes faster, especially for supported Microsoft Graph scenarios.

Closing Thought

Most identity programs still spend too little time on workload identities. That gap gets more dangerous every year as automation grows, app permissions expand, and attackers increasingly look for the quietest path through the tenant.

Protecting service principals is not as visible as rolling out MFA to users, but it matters just as much. If you already have strong human identity controls, this is one of the highest-value next steps you can take in Microsoft Entra ID.