DET0030: Detect Conditional Access Policy Modification in Identity and Cloud Platforms
This detection strategy matters because changes to conditional access policy can directly weaken the rules that decide who is allowed into cloud and identi...
Analyst context for executives and security teams
This detection strategy matters because changes to conditional access policy can directly weaken the rules that decide who is allowed into cloud and identity-managed resources. Even without detailed MITRE detection logic supplied, the relationship to T1556.009 makes the business issue clear: unauthorized or poorly governed policy modification can support persistence, credential access, and defense impairment in identity-provider and IaaS environments.
Executive priority
Treat conditional access policy integrity as a high-value control area for identity and cloud resilience. Leaders should ask whether policy changes are logged, reviewed, approved, and rapidly investigated, because these policies often enforce MFA, device posture, location, and application access decisions. The priority is not just alerting; it is proving governance and incident readiness around changes to access enforcement.
Technical view
SOC, detection engineering, and IR teams should validate monitoring for creation, deletion, disablement, or modification of conditional access policies in identity-provider and cloud administrative planes. Because the ATT&CK detection strategy has no official detection text or platform list, implementation should be mapped locally to the related technique T1556.009 and to the organization’s actual identity/IaaS providers. Focus on privileged administrative actions, policy state changes, changes affecting MFA or access conditions, and correlation with account compromise indicators or unusual admin activity.
Likely telemetry
- Identity provider audit logs for conditional access policy create, update, disable, delete, or assignment changes
- Cloud/IaaS control-plane audit logs where access policy enforcement is managed
- Administrative activity logs for privileged users, service principals, or automation accounts
- Change-management or ticketing evidence for approved policy modifications
- Authentication logs showing access outcomes before and after policy changes
Detection direction
- Confirm that conditional access policy changes are collected from the authoritative identity/cloud control plane, not only from endpoint or network tools.
- Tune detections to distinguish planned administrative changes from suspicious changes made by unusual accounts, at unusual times, or without change approval.
- Prioritize changes that disable policies, weaken MFA or device/location requirements, broaden exclusions, or affect high-value applications and privileged roles.
- Correlate policy modifications with related T1556.009 context: persistence, credential access, and defense impairment.
- Validate blind spots around API-driven changes, service principals, automation, break-glass accounts, and log retention gaps.
Mitigation priorities
- Maintain strict role-based access control for administrators who can modify conditional access policies.
- Require change approval and review for policy modifications, especially changes affecting MFA, device posture, location, exclusions, or privileged access.
- Preserve audit logs long enough to support incident response and compliance evidence.
- Review conditional access policy configuration regularly against business-critical applications and privileged identities.
- Test incident response procedures for suspected unauthorized policy modification, including containment of the modifying account and restoration of known-good policy state.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy named DET0030 and is related to technique T1556.009, Conditional Access Policies. The practical value is in validating whether identity and cloud administrative-plane changes are visible, governed, and investigated. Glexia would treat this as an identity/cloud control-assurance and SOC detection-engineering priority rather than a standalone signature.
MITRE supplied no official description, no official detection text, no tactics, and no platform list for the detection strategy itself. Platform and tactic context comes only from the related technique: IaaS and Identity Provider, with defense-impairment, persistence, and credential-access tactics. Local provider capabilities, log schemas, and policy models must be verified before implementing detections.
Detect Conditional Access Policy Modification in Identity and Cloud Platforms
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1556.009 | Conditional Access Policies Sub-technique | This object detects Conditional Access Policies. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 02cd26b652c6… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0030Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.