Conditional Access (CA) policies are the primary enforcement layer for MFA, device compliance, and location-based access controls in Entra ID. An attacker who gains Conditional Access Administrator, Security Administrator, or Global Administrator access will often modify or delete CA policies as the first step — removing the requirement for MFA so they can sign in cleanly from any IP without triggering prompts.
Microsoft Sentinel surfaces these events via AuditLogs operations Delete conditional access policy, Update conditional access policy, and Add conditional access policy. A policy state change from enabled to disabled or a grant control change removing mfa is equally dangerous as outright deletion.
◈ Table of Contents
01
Background
CONTEXTB1CA Policy Tamper Techniques & MITRE Mapping
| Technique | MITRE | AuditLogs OperationName |
|---|---|---|
| Delete CA policy entirely | T1562.001 | Delete conditional access policy |
| Disable CA policy (state: disabled) | T1562.001 | Update conditional access policy — state field changed to disabled |
| Remove MFA from grant controls | T1562.001 | Update conditional access policy — grantControls.builtInControls no longer contains mfa |
| Exclude attacker account from policy | T1562.001 | Update conditional access policy — excludedUsers or excludedGroups modified |
| Add trusted IP location to bypass MFA | T1562.001 | Update named location — attacker IP added to trusted network list |
| Create new CA policy with permissive rules | T1562.001 | Add conditional access policy — all-users, all-apps, no controls |
02
Identification
INVESTIGATECA Policy Tampering — Investigation Workflow
I1Detect CA Policy ChangesKQL + SPL
KQL — Sentinel: All CA policy modifications (last 7 days)
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName in (
"Delete conditional access policy",
"Update conditional access policy",
"Add conditional access policy",
"Update named location"
)
| extend PolicyName = tostring(TargetResources[0].displayName)
| extend Initiator = tostring(InitiatedBy.user.userPrincipalName)
| extend InitiatorIP = tostring(InitiatedBy.user.ipAddress)
| extend OldValue = tostring(TargetResources[0].modifiedProperties[0].oldValue)
| extend NewValue = tostring(TargetResources[0].modifiedProperties[0].newValue)
| project TimeGenerated, OperationName, PolicyName, Initiator, InitiatorIP, OldValue, NewValue
| order by TimeGenerated desc
KQL — Identify sign-ins that succeeded without MFA after policy weakened
// Find successful logins with no MFA after the policy change timestamp
let tamper_time = datetime(2026-06-21T00:00:00Z); // replace with actual tamper time
SigninLogs
| where TimeGenerated > tamper_time
| where TimeGenerated < tamper_time + 4h // window for attacker to exploit
| where ResultType == 0
| where AuthenticationRequirement == "singleFactorAuthentication"
or not(AuthenticationDetails has "Multi-factor authentication")
| project TimeGenerated, UserPrincipalName, IPAddress, Location,
AppDisplayName, AuthenticationRequirement
| order by TimeGenerated asc
SPL — Splunk: CA policy tamper detection
index=azure sourcetype=azure:aad:audit
OperationName IN (
"Delete conditional access policy",
"Update conditional access policy"
)
| spath InitiatedBy.user.userPrincipalName OUTPUT Initiator
| spath TargetResources{}.displayName OUTPUT PolicyName
| table _time, OperationName, PolicyName, Initiator
| sort -_time
If a CA policy enforcing MFA for all users is deleted or disabled, ALL sign-ins immediately become single-factor until the policy is restored. An attacker can chain this with any credential they already hold — no token theft required. Check for new sign-ins from unknown IPs within the tamper window immediately.
I2Compare Policy Before & After TamperKQL
KQL — Extract old vs new value for the modified policy
// Diff the specific fields changed — focus on state, grantControls, conditions
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName == "Update conditional access policy"
| extend PolicyName = tostring(TargetResources[0].displayName)
| mv-expand ModProp = TargetResources[0].modifiedProperties
| extend FieldName = tostring(ModProp.displayName)
| extend OldValue = tostring(ModProp.oldValue)
| extend NewValue = tostring(ModProp.newValue)
| where FieldName in ("State","GrantControls","Conditions.Users","IncludedUsers","ExcludedUsers")
| project TimeGenerated, PolicyName, FieldName, OldValue, NewValue
| order by TimeGenerated desc
After restoring the CA policy, check the Named Locations list: Entra ID → Security → Named locations. Attackers frequently add their IP as a "trusted" named location and then configure CA to skip MFA for trusted locations — a subtle bypass that persists even after the policy is restored unless the location is also removed.
03
Containment
STOP ITC1Restore CA Policy & Block InitiatorImmediate
- 1Re-enable or recreate the deleted/disabled CA policy immediately: Entra ID → Security → Conditional Access → Policies. For deleted policies — recreate from the OldValue captured in AuditLogs, or restore from a documented baseline (Entra ID does not have native policy rollback).
- 2Block initiator account and revoke sessions (see SOP-18 containment steps). If the initiator is an admin account, contain both the initiator and any accounts it interacted with.
- 3Review and clean Named Locations: Entra ID → Named locations — remove any IP ranges added by the attacker.
- 4Force MFA re-registration for all users who signed in during the unprotected window using single-factor authentication. Issue TAPs.
04
Eradication
CLEAN UPE1Full CA Posture Audit & Hardening
- 1Audit all CA policies against your documented baseline: state, grant controls, included/excluded users, and named locations. Confirm every policy matches the expected configuration.
- 2Export current CA policy set as JSON for future comparison: Entra ID → Conditional Access → Policies → Export. Store in a versioned configuration repository.
- 3Enable the Sentinel analytic rule for CA policy changes — configure to alert immediately on any delete or state change without waiting for the 5-minute alert aggregation window.
- 4Restrict Conditional Access Administrator role to break-glass accounts only. Use PIM with approval gates for any CA policy modifications.
- 5Audit sign-ins that occurred without MFA during the unprotected window — treat each one as potentially malicious. Revoke sessions for all such sign-ins.
Eradication Complete When
- All CA policies restored and verified against baseline
- No untrusted named locations in the Named Locations list
- All single-factor sign-ins during tamper window audited and sessions revoked
- Initiator account contained and credentials rotated
- Sentinel alert for CA policy changes set to near-real-time
05
Escalation
TIERSESC1Escalation Tiers
| Tier | Trigger | Action |
|---|---|---|
| L1 → L2 | Single non-critical CA policy modified; no sign-ins without MFA detected; change ticket missing but no confirmed attacker activity | Restore policy, document initiator, escalate for admin account review |
| L2 → IR + CISO | MFA-enforcing policy deleted/disabled; subsequent single-factor sign-ins confirmed; initiator account compromised via AiTM or brute force | Full incident. Audit all accounts that signed in without MFA during window. CISO notification. |
| IR → Security Engineering | Multiple CA policies wiped; no backup/baseline available; entire CA posture destroyed; break-glass accounts compromised | Full tenant recovery. Engage Microsoft DART. Consider emergency tenant-wide CA redeployment from DR baseline. |
Authorized security research & penetration testing only. Unauthorized use is illegal. Authored by Rudra Verma | Senior Security Architect | CyberHawk Consultancy.