Your Conditional Access does not cover service principals
Conditional Access scoped to users never evaluates for a service principal. With a stolen secret, a workload signs in from anywhere with no MFA, no location control.
You wrote Conditional Access policies to enforce MFA and location. They target users, and a service principal is not a user.
How the attack works
An attacker steals a service principal’s client secret or certificate from a leaked pipeline variable or a config file and uses it to authenticate to the tenant. Because the Conditional Access policies are scoped to users, none of them evaluate for a workload identity, so the service principal signs in from an unfamiliar location with no MFA and no location control, reads data within its app permissions, and tries to add a second credential to the principal for persistence. The service-principal sign-in logs record the anomalous sign-in, and the audit log records the credential addition. In ATT&CK terms this is T1078.004, Valid Accounts: Cloud Accounts.
Why it works
User-targeted Conditional Access simply does not apply to workload identities, so a service principal sails past the controls teams assume protect everything. Combined with long-lived stealable secrets, that gap leaves automations completely ungated. The root cause is unmanaged, ungated, long-lived workload credentials.
How to fix it
The non-obvious move is that there is no user MFA to tighten and no host firewall that stops Entra token use. Rotate the service principal’s secret or certificate to kill the stolen credential, remove any credential the attacker added, and apply a Conditional Access policy for workload identities that constrains the principal by allowed location and risk. Scope what it accessed from the service-principal sign-in and Graph activity logs filtered to the principal and window. Then apply workload-identity Conditional Access broadly, prefer managed identities or certificates over long-lived secrets, shorten credential lifetimes, and alert on credentials being added to service principals.
Practice it
We built this as a GraphLattice Range scenario so security teams learn that user Conditional Access never covers a workload, and practice rotating the secret and applying workload-identity policy.