Conditional Access policies are the primary enforcement layer for MFA, compliant-device requirements, and location-based access controls in Entra ID. An attacker who gains Conditional Access Administrator or Global Administrator privileges can delete or disable a CA policy, add their compromised account to an exclusion list, or create a new named location covering an attacker-controlled IP to permanently bypass MFA for subsequent sign-ins.
CA policy changes are logged in Entra ID Audit Logs under the Policy category. Any CA policy modification not initiated via an approved change management ticket requires immediate investigation.
☰ Table of Contents
01 — BACKGROUND
TECHNIQUE OVERVIEWConditional Access policy tampering is an authentication bypass technique (T1556 — Modify Authentication Process). After gaining an admin account, attackers modify CA policies to create a persistent backdoor: they can sign in without MFA, from any location, using any device. The most common patterns are: (1) adding their compromised account or a new backdoor account to a CA exclusion group; (2) deleting the "Require MFA for all users" policy; (3) creating a new named location for an attacker IP and marking it as trusted.
| Field | Value |
|---|---|
| MITRE Technique | T1556 — Modify Authentication Process, T1548.004 — Elevated Execution with Prompt |
| Log Source | AuditLogs (Category == "Policy"), SigninLogs |
| Key Operations | Update conditional access policy, Delete conditional access policy, Add named location |
| Required Roles | Conditional Access Administrator, Security Administrator, Global Administrator |
| Detection Priority | CRITICAL — any CA policy deletion or exclusion addition triggers immediate response |
02 — IDENTIFICATION
2 INDICATORSEntra ID Audit Logs record every CA policy creation, update, and deletion with the initiating admin's UPN, the policy name, and the specific properties that changed. A deletion or a modification that adds accounts to the exclusions list is the most dangerous CA change pattern and must be cross-checked against an approved change management ticket immediately.
- 1Navigate to Entra ID → Monitoring → Audit logs. Set Category: Policy and filter Activity: Update conditional access policy / Delete conditional access policy.
- 2For each change event, expand the Modified Properties tab. Compare the "old value" and "new value" JSON to identify exactly what was changed. Exclusion additions appear as new entries in
conditions.users.excludeUsersorexcludeGroups. - 3Check the Initiated by field for the acting admin. Cross-reference with your CA admin allowlist and verify against open change tickets in your ITSM tool.
- 4If a policy was deleted, use the audit log to recover the policy definition from the "old value" JSON — this is the data needed to recreate it.
- 5Run the KQL below to query all CA policy changes and named location additions in the last 7 days.
| Change Type | Meaning | Action |
|---|---|---|
| Policy deleted | MFA or compliance control removed for all users in scope | ESCALATE IMMEDIATELY — recreate policy |
| excludeUsers / excludeGroups modified | Specific accounts added to bypass MFA enforcement | Remove exclusion NOW, audit excluded accounts |
| State changed to disabled | Policy put in report-only or off state — controls no longer enforced | Re-enable policy immediately |
| New named location added | Attacker-controlled IP added as trusted location bypassing location controls | Review IP, remove if not authorized |
After modifying a CA policy, an attacker signs in from their attacker-controlled IP without completing MFA. This sign-in is visible in SigninLogs with authenticationRequirement: singleFactorAuthentication or conditionalAccessStatus: notApplied. Sign-ins matching this pattern within hours of a CA policy modification strongly confirm the modification was intentional backdoor creation.
- 1Filter sign-in logs by the actor who made the CA modification. Look for sign-ins in the 30 minutes after the policy change timestamp.
- 2Check the Conditional Access column — look for entries showing Not Applied or Success (No controls required). These indicate the policy change took effect and was immediately exploited.
- 3Review the sign-in IP and country. Does it match the actor's normal location? If not, this is a confirmed compromised account being used from an attacker-controlled host.
- 4Check what the actor did after signing in: Audit logs filtered by initiating user and time window will show all admin operations performed in the elevated session.
- 5Run the KQL below to find sign-ins without MFA from the actor account in the window immediately after the CA policy change.
If the attacker deleted a CA policy (rather than modifying it), all users covered by that policy are immediately unprotected — not just the attacker's account. Recreating the deleted policy is the highest-priority containment action.
03 — CONTAINMENT
IMMEDIATE ACTION- 1If a policy was deleted: use the old-value JSON from the audit log to recreate it immediately at Entra ID → Security → Conditional Access → New policy.
- 2If a policy was modified: revert the change by restoring the old exclusions list or re-enabling the policy. Use Conditional Access → [Policy] → Edit → remove unauthorized exclusion.
- 3Disable the acting admin account: Entra ID → Users → [User] → Block sign-in: Yes and revoke all active sessions.
- 4Delete any unauthorized named locations added by the attacker: Conditional Access → Named locations → [Location] → Delete.
- 5Force all users to re-authenticate by revoking all refresh tokens: use the Revoke sign-in sessions option in Entra ID for all affected admin accounts.
04 — ERADICATION
CLEANUP- 1Implement CA policy change approval: require that all CA policy modifications go through Entra ID PIM for Conditional Access Administrator role, with manager approval required.
- 2Export and baseline all CA policies as JSON using the What If tool and Microsoft Graph API. Store in a version-controlled repository. Diff against baseline weekly.
- 3Create a Sentinel analytics rule alerting on every CA policy deletion or modification not initiated by an approved CA admin service account.
- 4Implement CA policy protection: lock critical policies using a dedicated emergency-access-only admin account and remove Conditional Access Administrator from all general admin accounts.
- 5Review and reduce the CA exclusions list: any account in a CA exclusion must have a compensating control (hardware token, named location tied to a corporate CIDR, compliant device requirement).
- All deleted or modified CA policies restored to authorized configuration
- Unauthorized named locations removed
- Actor account disabled and all sessions revoked
- CA policy change approval workflow enforced via PIM
- CA policy baseline exported and version-controlled
- Sentinel alert rule for CA policy changes created
05 — ESCALATION
ESCALATION PATHS| Condition | Severity | Action | Notify |
|---|---|---|---|
| Policy deleted, MFA bypass sign-in confirmed | SEV1 | Full IR, restore policy, disable account, audit all admin sessions | CISO → IAM team → Legal |
| Exclusion added for backdoor account, bypass imminent | SEV1 | Remove exclusion, disable both accounts, full audit | SOC Lead → CISO |
| Policy modified without ticket, no bypass observed yet | SEV2 | Revert change, disable actor pending investigation | SOC Lead → IAM team |
| Authorized emergency change, ticket verified | INFO | Document, update baseline, close | None |
Stay Threat-Ready
Follow CyberHawk Threat Intel for daily SOC analyst playbooks, detection engineering guides, and threat intelligence.