· Yair Knijn
Conditional Access for workload identities: what it can and cannot do
Most Conditional Access programmes stop at people. Users get MFA, device compliance, and named locations; the service principals running the actual integrations — the nightly export job, the CI pipeline, the connector a vendor asked you to consent to in 2023 — authenticate with a secret from anywhere on the internet, at any hour, forever. Workload identities cannot perform MFA, often have no lifecycle owner, and hold long-lived credentials, which is precisely why attackers like them.
Conditional Access for workload identities extends the policy engine to service principals. It is genuinely useful, and it is much narrower than the name suggests. Both halves matter when you plan around it.
What it actually gives you
A policy scoped to workload identities evaluates when a service principal requests a token, and it can block that request in two situations: when the request comes from outside named network locations you trust, and when Microsoft Entra ID Protection has flagged the service principal with elevated risk. Policies combine with authentication contexts, and both policy types support report-only mode, so you can measure the blast radius before enforcing. Evaluation results land in the service principal sign-in logs, which gives you an audit trail for token requests that most estates have never looked at.
A location policy on a deployment service principal turns a leaked client secret from a global credential into one that only works from your build network. That single control removes the most common abuse path for stolen application secrets.
The limits that catch people
First, scope: policies apply only to single-tenant service principals registered in your tenant. Multi-tenant applications — including the third-party SaaS integrations that worry most security teams — are not covered, and neither are managed identities. Second, the grant control: block is the only available option. There is no "require this, then allow" for a service principal; the policy language is allow-from-here or nothing. Third, targeting: service principals can sit in groups, but a Conditional Access policy assigned to that group is not enforced for them — each service principal must be assigned to the policy directly, which makes policy hygiene a real inventory exercise. Fourth, licensing: creating or modifying these policies requires Microsoft Entra Workload ID Premium licenses.
None of these is a reason to skip the feature. They are reasons to be precise about what your control actually covers when someone — an auditor, a customer, your own architecture review — asks whether "all identities are subject to Conditional Access". The honest answer today is: interactive users comprehensively; your own single-tenant service principals by location and risk; multi-tenant apps and managed identities not at all, so those need compensating controls such as access reviews, credential rotation, and least-privilege permission audits.
Where this fits in a multi-tenant estate
For operators responsible for many tenants, workload identity policies inherit the same management problem as every other Conditional Access policy: no cross-tenant sync, per-tenant assignment, and quiet drift — with the added twist that direct service-principal assignment makes drift even easier, because a new automation identity created in one tenant is unprotected until someone remembers to add it to the policy. We covered the cross-tenant operating model in Managing Conditional Access across multiple tenants and the user-side policy design in Conditional Access policies in multi-tenant regulated SaaS environments. Workload identities are the third leg: inventory them, protect the ones the platform can protect, and document the compensating controls for the ones it cannot.
The Spot Suite identity and access modules track Entra configuration — including Conditional Access policy state — across tenants, so gaps like an unassigned service principal show up as drift instead of as an incident.