What this check looks at
Checks whether Conditional Access covers workload identities (service principals), so an application credential used from an unexpected place, or flagged as risky, can be blocked.
Applications that call Microsoft Graph or other APIs on their own (integrations, backup and reporting tools, scripts) sign in as a service principal with a client secret or certificate, not as a person. They do no MFA, and by default Conditional Access does not apply to them, so a stolen secret works from any IP address in the world. Conditional Access for workload identities, licensed with Microsoft Entra Workload ID, can block a service principal’s sign-ins from outside known locations, or when Entra ID Protection rates it high risk.
The check passes when an enabled Conditional Access policy (report-only does not count) includes at least one service principal. It also passes when no application holds a high-privilege application permission, such as Directory.ReadWrite.All, Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, Sites.FullControl.All, User.ReadWrite.All or Group.ReadWrite.All, and reports not checked when the app permissions could not be read. It warns when high-privilege apps exist and no policy covers workload identities, listing them.
Secrets leak: committed to a code repository, left in a script on a file share, pasted into a support ticket or taken from a developer’s laptop. An app with Mail.ReadWrite or Files.ReadWrite.All can read every mailbox or every file in the tenant, which is why attackers who reach administrator rights often add their own secret to an existing app as a quiet back door. Without a location policy, that back door works from anywhere.
Why it matters
Application secrets and certificates do not do MFA. When one leaks, it works from anywhere until someone notices. Conditional Access for workload identities limits where high-privilege apps can sign in from and blocks them when Entra ID sees them as compromised.
A typical case: a small software company’s CRM uses an app registration with Mail.Send and Mail.ReadWrite to send quotes. A developer commits the client secret to a public GitHub repository by mistake; automated scanners find it within hours. The attacker reads the finance mailbox and sends a "change of bank details" email from it to every customer, all without a single interactive sign-in.
An incident like that is a business email compromise with no user account to reset and no MFA prompt that might have warned anyone. A location policy would have refused the token to the attacker’s IP address.
This supports ISO 27001 A.5.15 (access control), PCI DSS 7.2.5 on managing application and system accounts, and the NCSC Cyber Assessment Framework’s B2.d. Conditional Access applies only to single-tenant service principals registered in your own tenant; third-party multi-tenant apps and managed identities cannot be covered, so for those, reduce their permissions instead.
How to fix it
Where: Entra admin centre → Protection → Conditional Access
Before you start
- Confirm the tenant has Workload Identities Premium licences; Conditional Access for service principals needs them.
- Find the IP ranges the listed apps sign in from, in the service principal sign-in logs.
Step by step
- Check the licence. Conditional Access for workload identities needs a Microsoft Entra Workload ID licence for each service principal it covers. Check in the Microsoft 365 admin centre under Billing > Your products, or buy it under Billing > Purchase services.
- Pick the apps to cover. From the apps in the evidence, choose the single-tenant ones registered in your own tenant (in the Entra admin centre, Entra ID > App registrations, supported account types "this organisational directory only"). Third-party multi-tenant apps cannot be targeted; review their permissions instead.
- Find where they sign in from. In the Microsoft Entra admin centre, go to Entra ID > Monitoring & health > Sign-in logs and open the Service principal sign-ins tab. Filter on each app over the last 30 days and note the IP addresses it uses.
- Create a named location for those addresses. Go to Entra ID > Conditional Access > Named locations, select IP ranges location, name it (for example "App servers"), add the ranges in CIDR form and select Create.
- Create the policy in report-only mode. Go to Entra ID > Conditional Access > Policies > New policy and name it "Block workload identities outside known locations". Under "What does this policy apply to?", choose Workload identities and include the selected service principals. Under Target resources, choose All resources. Under Conditions > Locations, include Any location and exclude your named location. Under Grant, choose Block access. Set Enable policy to Report-only and select Create.
- Add a risk-based policy too. Create a second policy the same way for the same service principals with Conditions > Service principal risk set to High and Grant set to Block access, also in report-only, so a service principal Entra ID Protection flags as compromised is stopped wherever it signs in from.
- Review the report-only results. After a few days, open Service principal sign-ins, select sign-ins for the covered apps and look at the Report-only tab. Any "Report-only: Failure" from an address the app genuinely uses means the named location is missing a range; add it before going on.
- Turn the policies on and confirm. Set Enable policy to On for each policy and select Save. The policies list shows them On, the service principal sign-in logs show them applied with no unexpected failures, and a test sign-in with the app’s credentials from another network is refused.
What users will notice
None for people. Apps signing in from outside the allowed locations are blocked.
How to confirm it worked
Service principal sign-in logs show the policy applied and no unexpected failures.
Frameworks and controls
This check maps to controls in 13 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | B2.d Identity and access management (IdAM) |
| DSPT | Standard 4: Managing data access |
| DORA | Art. 9(4)(c) Limiting logical access to what is required |
| NIS2 | Art. 21(2)(i) Access control and asset management |
| Microsoft Cloud Security Benchmark | IM-3 Manage application identities securely and automaticallyIM-7 Restrict resource access based on conditions |
| Zero Trust | Applications |
| SOC 2 | CC6.1 Logical access security software, infrastructure and architectures |
| PCI DSS 4.0.1 | 7.2.5 Application and system accounts are managed with least privilege |
| NIST SP 800-171 | 3.1.1 Limit system access to authorised users, processes and devices |
| CMMC Level 2 | AC.L2-3.1.1 Authorized Access Control |
| ISO 27001:2022 | A.5.15 Access control |
| NIST CSF 2.0 | PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of dutiesPR.AA-03: Users, services, and hardware are authenticated |
| NCSC 10 Steps | Identity and access management |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Conditional Access for workload identities (Microsoft Learn)