Unexpected production lockouts often come from overlapping Conditional Access rules. The strictest rule wins and blocks access. Capture evidence fast to restore access and satisfy auditors.
When Conditional Access policies conflict, Azure AD evaluates all matching policies. The system enforces the strictest outcome: Deny overrides Grant. Resolve conflicts by checking assignments, precedence, evaluation details, and logs.
Key variables that determine outcome
The effective access result depends on three core variables: policy assignments, policy actions, and evaluation data. Each variable narrows possible outcomes for a sign-in event. Engineers must collect these three data points first.
Assignments and scope
Policy assignments name subjects and targets. They list users, groups, service principals, and applications. Overlapping assignments often start conflicts.
Actions and controls
A policy action is either Grant with controls or Deny. Grants may require MFA, device compliance, or session controls. Any present Deny produces an effective Deny.
Sign-in conditions and evaluation data
Conditions include device state, location, client app, and risk level. The Conditional Access evaluation details show which conditions matched. Pull these details from SigninLogs for each incident.
Collect the sign-in event ID, conditionalAccessStatus, and conditionalAccessPolicies fields. Those three fields prove why a decision occurred. Store the JSON output for audit evidence.
Confirm logs and evidence before changing any policy.
Start with safe, reversible actions to restore access while you collect evidence. Use break-glass accounts and report-only toggles before changing production policies. This approach limits operational impact.
Identify one break-glass account that is exempt from Conditional Access. The account must not be used for regular tasks. Use it to regain admin control if access is widely blocked.
Capture sign-in evidence
Query the SigninLogs for the affected timestamp and user. The KQL below returns the necessary fields and correlation IDs.
KQL
SigninLogs
| where TimeGenerated between (datetime(2024-01-01) .. Now())
| where UserPrincipalName == "[email protected]"
| project TimeGenerated, UserPrincipalName, AppDisplayName, ConditionalAccessStatus, ConditionalAccessPolicies, ResultType, CorrelationId
Move an offending policy to Report-only or disable its assignment scope. Do not delete policies during triage. Document each change with timestamp and approver for compliance.
Step-by-step incident triage playbook
- Capture the sign-in identifier and immediate evidence: signInEventId, conditionalAccessStatus, conditionalAccessPolicies array, ResultType and CorrelationId from SigninLogs.
- Run a focused KQL against SigninLogs to retrieve the event and the conditionalAccessPolicies JSON and deviceDetail/clientAppUsed fields.
- From the conditionalAccessPolicies entries, note policy IDs that produced Deny and any policy IDs listed as applying Grants.
- Export those policy definitions via Microsoft Graph or Microsoft.Graph PowerShell (Get-MgIdentityConditionalAccessPolicy) to inspect assignments, exclusions, enabled/report-only state, and conditions.
Confirm logs and evidence before changing any policy.
- Expand group memberships for targeted groups using Graph calls or Get-MgGroupMember to map affected users.
- If immediate access restoration is required, prefer temporary report-only toggles or targeted exclusions for the impacted user(s) or app scope. Do not delete policies. Record timestamp and approver.
- After restoration, run a post‑incident review. Compute pairwise intersections, add targeted exclusions, refine named locations, test in report-only mode, and use the What If tool and regression KQL to validate before re-enabling enforcement.
Which users and resources are affected
Conflicts affect users and resources where policy scopes intersect. Detect intersections of users, groups, and apps to find affected sets. Automation removes guesswork at scale.
User and group intersection
A user inherits all policies that target their user object, groups they belong to, and directory roles they hold. Group-expansion often explains why a single user sees multiple policies.
Application and service principal scope
Conditional Access can target specific enterprise applications or all cloud apps. App-scoped policies combine with user-scoped policies when both match the same sign-in. Map apps to policy IDs for traceability.
Device and location coverage
Device compliance, device state, and named locations change policy applicability. Named location denies often collide with broader Grant policies and cause unexpected blocks.
Confirm logs and evidence before changing any policy.
Common real-world conflict scenarios and outcomes
Examples expose how Deny-over-Allow appears in production and how to fix it. The scenarios below are reproducible. They map directly to remediation steps.
Scenario: MFA requirement vs device deny
Symptom: User completes MFA but still receives access denied. Root cause: a Deny policy targets non-compliant devices while a Grant requires MFA. Result: Deny wins and blocks access.
Fix: Adjust the Deny scope or enroll devices via Intune. Test the fix in report-only before reenabling enforcement.
Scenario: location-based deny vs app
Symptom: Remote contractor cannot access a privileged app. Root cause: a location Deny for anonymous IPs intersects an app-specific Grant. Result: Deny blocked the contractor despite the Grant.
Fix: Add targeted exclusions, define trusted IP ranges, or use named locations and conditional access conditions to refine scope.
A typical case
An anonymized incident: a finance user belonged to an admin group and a temporary contractor group. The admin group had a strict Deny for legacy protocols. The contractor group had a Grant requiring device compliance.
The user was denied due to overlapping Deny. The most common error is assuming the Grant will override the Deny; Grants do not override Deny.
Confirm logs and evidence before changing any policy.
How policy evaluation order decides access
Azure AD evaluates all applicable policies and computes a deterministic outcome from their results. The system does not use creation time or explicit priority fields to pick one policy.
Evaluation steps
Step 1: Identify applicable policies by matching assignments and conditions. Step 2: Evaluate each policy to produce Grant or Deny and list required controls. Step 3: Compute effective result: any Deny leads to Deny; otherwise all Grants must have satisfied controls.
Role of session controls
Session controls and CASB actions apply after an initial Grant decision. They can restrict session behavior but cannot convert a Deny into Allow. Continuous access evaluation may re-evaluate during a session.
Policy decision point and enforcement
The evaluation happens at a Policy Decision Point (PDP) inside Azure AD. Enforcement occurs at the Service Provider acting as a Policy Enforcement Point (PEP). Logs capture PDP outputs as conditionalAccessPolicies entries.
The evaluation result is deterministic: capture the conditionalAccessPolicies JSON for each blocked sign-in to show which policy produced Deny and why.
Conflict matrix
| Policy A |
Policy B |
Expected effective result |
Notes |
| Grant (MFA) |
Grant (device compliant) |
Allow if both controls satisfied |
Grants combine required controls |
| Grant (MFA) |
Deny |
Deny |
Deny-over-Allow applies |
| Grant (requireHybridJoin) |
Grant (device compliant) |
Allow if device meets both requirements |
Combine device signals from Intune/AD |
| Grant (session control) |
Grant (no session) |
Allow with session restrictions |
Session rules applied post-grant |
| Block by location |
Grant (risk-based) |
Deny if location block applies |
Named locations can refine outcome |
Confirm logs and evidence before changing any policy.
Explicit precedence
There is no explicit precedence field: policies are co-evaluated and the effective result is determined by matched actions (Deny overrides Grant).
Detection scripts and automation patterns
Automated overlap detection prevents surprise outages at scale. Pull all policy definitions, normalize scopes, and compute pairwise intersections. Flag pairs where actions differ.
PowerShell sample to list policies
Run Microsoft Graph PowerShell to export policies. The command below lists key fields.
PowerShell
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy | Select-Object id,displayName,conditions,grantControls,state,applications,users
Overlap detection pseudocode
Normalize user and app sets, then compute intersections for each policy pair. If intersection non-empty and actions conflict, mark for review. Batch and paginate to scale with tenant size.
Graph API checks for sign-in evidence
Use the sign-ins API to fetch conditionalAccess details for an event.
GET /auditLogs/signIns?$filter=userPrincipalName eq '[email protected]'&$orderby=createdDateTime desc
Capture the conditionalAccessStatus field and conditionalAccessPolicies array. Those fields show which policy produced Deny for the event.
Scalable detection script pattern and considerations
A repeatable detection routine must export enabled and report-only Conditional Access policies. It must normalize assignments into explicit user and app sets. Compute intersections pairwise and mark action conflicts.
Confirm logs and evidence before changing any policy.
The following minimal PowerShell snippet shows core collection and export stage. Expand it for tenant size, paging, and caching of group expansions.
PowerShell
Connect-MgGraph -Scopes "Policy.Read.All"
$policies = Get-MgIdentityConditionalAccessPolicy | Where-Object {$_.State -ne 'disabled'}
$results = @()
foreach ($p in $policies) {
$assignedUsers = Expand-Assignment-To-Users -Assignment $p.Conditions.Users # placeholder function: expand groups to users
foreach ($u in $assignedUsers) {
$results += [PSCustomObject]@{PolicyId=$p.Id;PolicyName=$p.DisplayName;UserPrincipalName=$u;Effect=$p.GrantControls -or $p.State}
}
}
$results | Export-Csv -Path ./ca_assignments.csv -NoTypeInformation
The key is producing a CSV that maps policy→user→app→effect. Script pairwise joins to flag rows where two policies apply to the same user/app with conflicting effects. For scale, run group-expansion with caching, handle Azure AD pagination, and emit policy IDs. Those IDs let you correlate back to SigninLogs conditionalAccessPolicies entries during forensic review.
Fail-open vs fail-secure trade-offs and hidden costs
Design choices between fail-open and fail-secure influence availability and risk profiles. A strict fail-secure posture can increase triage time and operational cost. Security teams must quantify those costs for leadership.
Operational cost signals
Unexpected Deny events add toil to helpdesks and security teams. Many organizations have seen incident counts rise after broad Deny policies. Use incident counts and mean time to restore to measure impact.
Compliance and audit implications
Documented policy decisions support audits under NIST SP 800-207 (2020) and similar standards. Map policy rationale to HIPAA, PCI DSS, or GDPR controls to defend posture during review. See NIST guidance for Zero Trust design: NIST SP 800-207 (2020).
Hidden operational traps
A common trap is testing only in the GUI and not capturing conditionalAccess evaluation details; the GUI preview does not show full evaluation, so logs are the source of truth.
Do not apply the remediation steps in this guide if the environment does not use Azure AD Conditional Access. Environments that rely solely on external CASBs or fully on-premise IAM without Azure AD integration require different procedures.
For operational assistance during an active outage, request a scoped policy review using the supplied scripts and playbook as part of the incident runbook.
Confirm logs and evidence before changing any policy.
Frequently asked questions
What happens if multiple conditional access policies apply?
All applicable policies are evaluated and an effective Deny occurs if any policy yields Deny. Grants only succeed when all required controls are met. Evidence must include conditionalAccessPolicies from the sign-in record.
How to prove a conditional access deny for a sign-in?
The sign-in record contains conditionalAccessStatus and conditionalAccessPolicies that show which policy produced Deny. Save that JSON for audit evidence. Run KQL against SigninLogs and export the conditionalAccessPolicies array.
Can report-only mode safely validate a policy?
Report-only mode simulates enforcement and logs simulated results without blocking access. It is safe for validating changes before enforcement. Combine report-only with targeted pilot groups and break-glass accounts.
Why did a grant with MFA still fail for a user?
A Deny policy that matched the same sign-in scope caused the failure. Deny-over-Allow prevents Grants from succeeding despite MFA completion. Check conditionalAccessPolicies in the sign-in event to find the Deny source.
How to detect conflicting policies at scale?
Export all CA policies via Graph, normalize assignments, and compute pairwise intersections. Flag pairs where actions differ and assignments overlap. Automate the detection script on a nightly cadence and produce a review report for policy owners.
Does a newer policy override an older one?
No. Azure AD does not use creation time for precedence; outcomes derive from evaluation results and actions. Deny always overrides Grant. Treat every policy as co-equal in evaluation.
Confirm logs and evidence before changing any policy.
The actionable plan
Restore access and prevent recurrence with a small set of repeatable steps. First, use a break-glass account to regain admin access if needed. Second, gather sign-in evidence and run the overlap detection script to find conflicting policies.
Third, move offending policies to Report-only and deploy refined assignments or exclusions. Re-enable enforcement in staged groups after validation using the What If tool and KQL regression queries. This approach minimizes downtime and produces auditable artifacts for compliance reviews.
Align remediation records to NIST SP 800-207 and CISA operational guidance to satisfy auditors and leadership.
Which users and resources can a conflict affect?
Conflicts affect any user or resource where policy scopes intersect. That includes direct users, group members, service principals, and targeted applications. Map group memberships and app assignments to identify intersections.
Automation that computes pairwise intersections of assignments finds affected sets reliably.
