In most of the tenants I support, service principals have been multiplying quietly next to the user accounts. They run automations, internal tools and integrations, yet hardly anyone thinks of them when planning Conditional Access. With the Microsoft Entra Workload ID Premium licence, we can now apply Conditional Access to these workload identities and actually reduce risk. If service principals in your organisation hold broad permissions, this step is overdue.

Service principals need the same layered controls as user accounts

For a long time, admins pointed Conditional Access almost exclusively at user accounts, with MFA, named locations and risk policies. Several high-profile breaches involving compromised app registrations and stolen client secrets have made it obvious that service principals need layered controls too. Conditional Access for workload identities gives you two useful policies. You can block sign-ins from outside trusted IP ranges, and you can block based on service principal risk as evaluated by the workload identity risk detection in Entra ID Protection (Microsoft's documentation). These controls only work for single-tenant service principals, meaning the app is registered in your home tenant only and is not a managed identity. Multi-tenant apps and managed identities aren't supported at this time (workload identities overview). If you want a refresher on the identity types, have a look at my primer on workload identities.

The new controls cover two scenarios and leave some gaps

You can now build Conditional Access policies that target service principals directly. In my projects, two scenarios turn out to be the most useful:

  • Restricting access to known IP ranges: Named locations let you block sign-ins from anywhere except your approved datacenters or Azure subnets. This works especially well for automation that runs from predictable environments.
  • Blocking risky service principals: When Entra ID Protection flags a service principal as risky, you can block access, or run the policy in report-only mode first to see the impact.

Keep in mind that these protections do not apply to managed identities or to multi-tenant apps registered in more than one tenant, which makes some integrations harder to protect. If you still depend on client secrets, this is a good moment to switch to something safer such as workload identity federation (my how-to article).

Practical tip: Pilot every new Conditional Access policy for workload identities in report-only mode. Blocking legitimate automation by accident is easy, and the errors don't always make the cause obvious. A denied sign-in can look exactly like a failed secret.

The sign-in logs show which service principals to target first

Before I roll out Conditional Access policies for workload identities, I check the service principal sign-in logs in the Microsoft Entra admin center (Sign-in logs → Service principal sign-ins). They tell you where your service principals authenticate from, which apps are the busiest and whether any failed sign-ins deserve a closer look. That information helps you tune your named locations and decide which sensitive identities to cover with Conditional Access first. In a crowded tenant, filtering by ApplicationId or app name saves a lot of time.

For a quick look at recent sign-ins, PowerShell 7 with the Microsoft Graph module (version 2.8 or later) does the job:

# PowerShell 7, Module: Microsoft.Graph (at least v2.8)
# List last 50 service principal sign-ins
Get-MgAuditLogSignIn -Filter "servicePrincipalId ne null" -Top 50 | Select-Object AppDisplayName, IPAddress

Prerequisites: Microsoft Graph PowerShell, AuditLog.Read.All permission, Entra Workload ID Premium licence

Each service principal sign-in passes an IP check and a risk check

The flowchart below shows how Conditional Access policies for workload identities handle a service principal sign-in, from the sign-in itself through the IP check to the risk evaluation:

flowchart TD
    A["Service Principal sign-in"] --> B["Evaluate CA policies"]
    B --> C["Check IP location"]
    C --> D["Trusted IP?"]
    D -- "No" --> X["Blocked"]
    D -- "Yes" --> E["Check risk state"]
    E --> F["Not risky?"]
    F -- "No" --> X
    F -- "Yes" --> G["Access granted"]

Figure: Conditional Access flow for service principals with IP and risk checks.

Agent identities will extend these controls but gaps remain for now

Agent identities (Entra Agent ID) are set to bring a standardised lifecycle and governance to workload identities, along with more granular access controls that include Conditional Access. As of late 2025, though, the current capabilities only cover classic service principals from app registrations ([more on Agent ID: /blog/microsoft-entra-agent-id-build-2025-identities]). Managed identities and multi-tenant apps remain outside the scope of Conditional Access policies for workload identities. If you're working on a governance roadmap for machine identities, factor this limitation into your planning.

I see real progress here but the rollout needs careful planning

For anyone who is tired of service principals being a blind spot, Conditional Access for workload identities is a big step forward. It isn't a matter of ticking a few boxes, though. You need good visibility into your sign-ins, clearly defined IP ranges and a careful report-only pilot, otherwise you risk breaking production automation. The single-tenant restriction and the missing support for managed identities make things more complicated. Still, being able to enforce named location and risk policies on service principals is a significant gain. If you start now, you'll end up with a control framework for the machine identities in your tenant that you can actually defend.