Conditional access is the primary preventive control in the Microsoft identity stack. Understanding how it evaluated during a sign-in — which policies applied, which conditions were met, which grant controls were enforced — is essential for both investigation and hardening.
Parsing conditional access results
The ConditionalAccessPolicies field in SigninLogs contains a JSON array with every policy that evaluated. Each element has: displayName (policy name), result (success, failure, notApplied, reportOnly), enforcedGrantControls (what was required — MFA, compliant device, etc.), and conditionsNotSatisfied.
This shows every conditional access policy that evaluated for this user, with its result and what it required. You can see exactly which policies protected them and which did not apply.
Identifying conditional access gaps
The gap you are looking for
A compromised sign-in where ConditionalAccessStatus = "success" and no policy required a compliant device means your conditional access had a gap. The attacker's stolen token was accepted because no policy checked whether the device was managed. Finding these gaps and closing them is how you prevent the next attack.
These sign-ins had no conditional access protection — no MFA required, no device compliance check, no location restriction. If an attacker signs in to one of these applications, nothing prevents access beyond the stolen credentials.
Find report-only policies that would have blocked attacks:
Report-only policies evaluate but do not enforce. This query shows how many sign-ins would have been blocked if the policies were enforced — critical data for deciding when to move a policy from report-only to enforced.
Try it yourself
Run the "no CA policy applied" query in your environment. Are there applications where successful sign-ins have no conditional access coverage? These are your highest-priority gaps.
Common gaps include: third-party SaaS apps that were not included in your CA policy scope, legacy applications using protocols that CA does not evaluate, and service accounts that were excluded from CA policies for operational reasons. Each gap is a potential entry point for an attacker with stolen credentials.
Check your understanding
1. A successful sign-in shows ConditionalAccessStatus = "notApplied". What does this mean for your security posture?
The sign-in was safe because no policy was needed
The sign-in was blocked
No conditional access policy evaluated — this sign-in had no protection beyond credentials. If the credentials are compromised, nothing prevents access.
"notApplied" means none of your CA policies matched the conditions of this sign-in (user, app, location, device). The sign-in was allowed based on credentials alone. These are your conditional access gaps — the applications and scenarios where an attacker with stolen credentials faces no additional barriers.
2. A report-only policy shows it would have blocked 340 sign-ins this week. What should you do?
Leave it in report-only mode indefinitely
Analyse the 340 sign-ins — if they are predominantly risky or anomalous (not legitimate business activity), move the policy to enforced mode
Delete the policy
Report-only mode is for testing before enforcement. Analyse the sign-ins it would have blocked: are they legitimate users who would be disrupted, or anomalous activity that should be blocked? If the policy would not disrupt legitimate operations, switch to enforced. If it would, adjust the policy scope before enforcing.
