CA-12: Conditional Access for Workload Identities

Overview

This guide walks you through creating a Conditional Access policy that targets workload identities (service principals) rather than users. Service principals sign in machine-to-machine, without MFA, and frequently hold broad permissions. A standard user-focused Conditional Access estate does nothing for them. This control adds location-based and risk-based guardrails to non-human identities so a compromised service principal cannot authenticate freely from anywhere.

Control ID: CA-12 Category: Conditional Access Baseline Level: Level 2 (Enhanced Security) Severity: High License Required: Microsoft Entra ID P1, plus the Microsoft Entra Workload ID Premium add-on (required to target workload identities in Conditional Access)

Why This Matters

Service principals authenticate without user interaction and often have broad permissions. Without CA policies, a compromised service principal has unrestricted access. Workload identity CA policies enable location-based and risk-based controls for non-human identities.

Conditional Access for workload identities lets you say, in effect, "this service principal may only authenticate from these known locations" or "block this service principal if its risk is elevated." That turns a compromised secret from an open door into a blocked or geo-fenced attempt.

Expected State

• A Conditional Access policy targets service principal authentication
• High-risk workload identities are covered by risk-based policies
• Policy is in enforced (not report-only) state

Prerequisites

Before You Start

1. Confirm the Workload ID Premium add-on is provisioned. Without it, you cannot select service principals in a Conditional Access policy.
2. Identify which service principals are single-tenant apps you own; Conditional Access for workload identities applies to service principals in your tenant, not to Microsoft first-party or multi-tenant SaaS identities.
3. Map the known-good IP ranges each critical service principal uses (CI/CD runners, on-prem connectors, cloud egress IPs). Named locations built from these are the basis of location-based control.

Time Estimate

TrueConfig Remediation

This control supports one-click enablement. TrueConfig can create the Conditional Access policy targeting workload identities in report-only mode for you, so you can validate impact before enforcing. Workload identity Conditional Access requires the Microsoft Entra Workload ID Premium add-on. After you confirm the report-only results look right, switch the policy to On to reach the enforced expected state. You can also build it manually with the steps below.

Step-by-Step Instructions

Step 1: Build Named Locations for Trusted Workload IPs

1. Sign in to the Microsoft Entra admin center.
2. Go to Protection > Conditional Access > Named locations.
3. Click + IP ranges location.
4. Name it, for example, Workload Trusted IPs, and add the egress IP ranges your service principals legitimately use.
5. Mark as trusted if appropriate. Click Create.

Step 2: Create the Workload Identity Conditional Access Policy

1. Go to Protection > Conditional Access > Policies and click + New policy.
2. Name it, for example, Workload Identities - Restrict to Trusted Locations.
3. Under Assignments, open Users and switch the target to Workload identities:
   • Select Service principals.
   • Under Include, choose the specific service principals you own and want to protect. Start with your highest-permission apps.
   • Under Exclude, add any principal that must authenticate from variable locations and cannot be constrained yet (document why).
4. Under Target resources, this policy type applies to the cloud resources the service principal accesses; leave at the default for workload identity policies.

Step 3: Configure the Location Condition

1. Under Conditions > Locations, set Configure to Yes.
2. Include: Any location.
3. Exclude: your Workload Trusted IPs named location.
4. Combined with a block grant, this blocks sign-ins from anywhere except the trusted ranges.

Step 4: Set the Access Control

1. Under Access controls > Grant, select Block access.
2. Click Select.

This means: block the selected service principals unless they authenticate from a trusted location.

Step 5: Add Risk-Based Coverage (Recommended)

For high-risk workload identities, pair this with a risk condition:

1. Create a second policy targeting the same service principals.
2. Under Conditions, configure Service principal risk and include High (and optionally Medium).
3. Set the grant to Block access.
4. This blocks a service principal whenever Identity Protection rates it high-risk (see PA-08). Risk-based workload identity policies require Workload ID Premium.

Step 6: Validate in Report-Only, Then Enforce

1. Set Enable policy to Report-only and click Create.
2. Go to Conditional Access > Insights and reporting and review what would have been blocked over a representative period.
3. Adjust named locations for any legitimate source you missed.
4. Once clean, edit the policy and set Enable policy to On. The expected state for this control is enforced, not report-only.

Verification Checklist

• Workload ID Premium is provisioned
• Named location(s) capture the legitimate source IPs of protected service principals
• A Conditional Access policy targets service principals (workload identities)
• Location-based control blocks sign-ins from untrusted locations
• A risk-based policy covers high-risk workload identities
• The policy was validated in report-only with no unexpected blocks
• The policy is enabled (On), not left in report-only
• Break-glass / critical automation exclusions are documented

Troubleshooting

"I cannot select service principals in the policy"

Targeting workload identities requires the Microsoft Entra Workload ID Premium add-on. Confirm it is provisioned and licensed.

"A legitimate integration is being blocked"

Its source IP is not in your trusted named location. Capture the real egress range from the sign-in logs (filter to the service principal), add it to the named location, and re-test. CI/CD services often rotate IPs; use the provider's published ranges.

"This does not apply to a SaaS app we use"

Workload identity Conditional Access applies to single-tenant service principals in your tenant. It does not govern Microsoft first-party identities or multi-tenant SaaS provider identities.

"Should this be block or grant with conditions?"

For location control, the common pattern is include Any location, exclude Trusted, grant Block. That blocks everything except the trusted ranges. Validate in report-only so you do not lock out a legitimate source.

"Risk condition shows nothing"

Service principal risk requires Identity Protection workload identity risk (Workload ID Premium) and only populates when a detection fires. See PA-08 to review the risky workload identities report.

Cost Considerations

Note: If you cannot license every service principal, prioritize the ones with the broadest Graph/API permissions and directory roles, since those are the most damaging if abused.

Related Controls

• PA-08: Risky Service Principal Detection - Detect the risk that this policy blocks on
• CA-08: Block Access from High-Risk Countries - Location-based control for users
• APP-10: Workload Identity Federation Adoption - Remove long-lived secrets from workloads
• APP-05: Service Principal Credential Hygiene - Keep workload credentials clean

Additional Resources

• Microsoft Learn: Conditional Access for workload identities
• Microsoft Learn: Microsoft Entra Workload ID
• Microsoft Learn: Named locations in Conditional Access