Azure Conditional Access Misses Service Principal Sign-Ins

Symptom

A Conditional Access policy assigned to “All users” with a strict grant control, such as blocking access or requiring multifactor authentication, continues to permit sign-ins from an application service principal or managed identity that the policy owner believed was already covered.

The gap usually surfaces during a security review or after an incident, when sign-in logs show a service principal authenticating from an unexpected location or at an unexpected time, with no Conditional Access enforcement recorded against that specific sign-in event.

False Assumption

The people who configured the policy assumed that the “All users” assignment target in Microsoft Entra Conditional Access means every identity in the tenant, including workload identities such as service principals, enterprise applications and managed identities.

That assumption is reasonable given the plain-English label, and it is incorrect. Conditional Access policies built on the standard “Users and groups” assignment evaluate sign-ins performed by human user principals. Sign-ins performed by non-human identities are evaluated through a separate workload identity scope that must be configured on its own.

Root Cause

Microsoft Entra Conditional Access separates the conditions used to evaluate user sign-ins from the conditions used to evaluate workload identity sign-ins. A policy built through the standard user assignment target does not automatically extend its grant controls to service principals, even when the policy is set to “All users” and the service principal belongs to the same tenant.

Coverage for workload identities depends on creating a policy, or a policy condition, that explicitly names the service principals in scope, and enforcing that coverage depends on appropriate workload identity licensing. Where that dedicated policy has not been created, or exists only in report-only state, service principal sign-ins are not enforced by the organisation’s user-facing Conditional Access baseline, regardless of how comprehensive that baseline appears in the portal.

Impact

The practical impact is a silent gap in identity governance: credentials belonging to applications, automation accounts and managed identities can authenticate and obtain tokens without being subject to the same location, device or risk-based restrictions applied to human sign-ins.

Because the “All users” policy continues to show as active and enforcing in the Conditional Access overview, the gap is invisible from policy configuration alone. It only becomes visible in sign-in log evidence, so it can persist for the lifetime of an affected application credential unless someone deliberately reviews service principal sign-in events against policy results.

Diagnosis

Confirm the gap using sign-in log evidence rather than policy configuration alone, because policy status will not reveal whether workload identities are actually excluded.

• Export the definitions of every Conditional Access policy assigned to “All users” and confirm the assignment target is limited to the “Users and groups” condition rather than a distinct workload identity condition.
• Filter the Microsoft Entra sign-in log for sign-in event type “servicePrincipal” and inspect the Conditional Access result field recorded against each event.
• Cross-reference any service principal whose sign-ins show “Not applied” against the list of applications and managed identities assumed to already be covered by the “All users” policy.

Correction

Close the gap by creating a dedicated Conditional Access policy that explicitly targets the workload identities you intend to govern, rather than assuming the existing user-scoped policy already covers them.

1. Identify the specific service principals that should be restricted, based on the sign-in log evidence gathered during diagnosis.
2. Create a new Conditional Access policy scoped to those named service principals under the workload identity condition, with the grant control you intend to enforce.
3. Deploy the new policy in report-only enforcement mode first, so it records what it would have done without changing live access.
4. Confirm the tenant’s current licence assignment covers enforced workload identity Conditional Access controls before planning enforcement, since this requirement is plan-sensitive and should be checked directly rather than assumed.

Validation

Validate the fix by confirming the new policy is actually being evaluated against the affected service principals before moving it out of report-only mode.

• Review report-only sign-in results for the targeted service principals over a representative period, typically at least one full business cycle.
• Confirm that sign-ins which should be restricted appear with a report-only “would have applied” result rather than “Not applied”.
• Only move the policy from report-only to enforced once reported results match the intended restriction with no unexpected legitimate automation caught by the new condition.

Rollback

Roll back by disabling or deleting only the new workload identity policy; do not touch the pre-existing “All users” policy, since it was never the cause of the gap.

• If report-only results show unexpected blocking of legitimate automation, switch the new policy’s state to disabled immediately; this does not affect the original user-facing policy.
• Record the full policy definition and object ID before enforcement so it can be recreated precisely if it is deleted rather than disabled.
• Re-run the diagnosis steps after rollback to confirm the tenant has returned to its prior, documented sign-in behaviour for the affected service principals.

Prevention

Treat “All users” Conditional Access coverage and workload identity Conditional Access coverage as two separate governance programmes that must each be reviewed on their own schedule.

• Add a recurring review step that filters sign-in logs for service principal events and checks the Conditional Access result field, rather than relying on policy assignment labels alone.
• Document, for every application and managed identity with production access, which Conditional Access policy, if any, is expected to govern its sign-ins.
• Re-verify workload identity licensing and policy state whenever a new automation identity is provisioned, since coverage does not extend automatically from existing user-facing policies.