Detecting Conditional Access and Security Policy Tampering

Once an attacker holds a privileged role, one of the quietest moves is weakening the controls that would stop their next sign-in: disabling an MFA or compliant-device policy, adding an exclusion for a compromised account or marking a hostile IP range as a trusted named location. All of these are audited, and all are rare in a stable tenant, which makes them strong detections.

Signals at a Glance

Policy State and Exclusions

Entra logs Update conditional access policy, Delete conditional access policy and Add conditional access policy with before and after values. Parse the modified properties to learn what changed, not just that something did:

// Microsoft Sentinel (KQL) - Conditional Access policy changes with state and exclusion deltas
AuditLogs
| where OperationName in ("Update conditional access policy", "Delete conditional access policy", "Add conditional access policy")
| where Result =~ "success"
| extend Policy = tostring(TargetResources[0].displayName),
         Actor = coalesce(tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)),
         ActorIp = tostring(InitiatedBy.user.ipAddress),
         OldValue = tostring(TargetResources[0].modifiedProperties[0].oldValue),
         NewValue = tostring(TargetResources[0].modifiedProperties[0].newValue)
| extend Disabled = NewValue has '"state":"disabled"' or NewValue has '"state":"enabledForReportingButNotEnforced"',
         ExclusionsChanged = NewValue has "excludeUsers" and OldValue != NewValue
| where OperationName == "Delete conditional access policy" or Disabled or ExclusionsChanged
| project TimeGenerated, OperationName, Policy, Actor, ActorIp, Disabled, ExclusionsChanged, OldValue, NewValue
// tune/validate: property layout differs by event; check a sample and diff old versus new JSON before alerting

• Send every change to a Conditional Access policy to the SOC, since the volume in a healthy tenant is a handful per month.
• Treat a disable followed by a sign-in from a previously blocked location, or a change followed by a new admin sign-in, as a single incident.
• Manage policies as code with review so the audit log can be reconciled to an approved change.

Trusted Locations and Defaults

Expanding a named location that Conditional Access trusts is a way to bypass MFA without touching any policy. The same Sigma logic covers location, policy and authentication method changes:

title: Entra ID Conditional Access And Named Location Changes
logsource:
  product: azure
  service: auditlogs
detection:
  ca_policy:
    properties.message:
      - 'Update conditional access policy'
      - 'Delete conditional access policy'
  named_location:
    properties.message:
      - 'Add named location'
      - 'Update named location'
      - 'Delete named location'
  auth_methods:
    properties.message|contains: 'authentication method'
  condition: ca_policy or named_location or auth_methods
level: high
# tune/validate: scope by actor allowlist (identity engineering), and confirm message strings against your log source

• Alert when the actor of a policy change is a service principal or a user who has never edited policies.
• Use break-glass account exclusions deliberately and monitor those accounts for any sign-in at all.