AN0802: Analytic 0802
Disabling or modifying sign-in or audit log collection for user activities. Defender view: policy or configuration updates removing logging coverage for critical accounts.
Analyst context for executives and security teams
This analytic is about detecting when an identity provider’s sign-in or audit logging is disabled or changed in a way that removes visibility into user activity, especially for critical accounts. For leaders, the business issue is not the configuration change itself; it is the loss of evidence needed to investigate account misuse, prove control operation, and make timely incident decisions.
Executive priority
Treat identity-provider logging coverage as a resilience and governance control. If sign-in or audit logs can be modified without prompt review, the organization may lose the ability to reconstruct identity incidents, support compliance evidence, or validate activity for privileged and critical users. Security leaders should ask who can change identity logging policies, how those changes are approved, and whether the SOC is alerted when logging coverage is reduced.
Technical view
The supplied ATT&CK object applies to Identity Provider platforms and describes policy or configuration updates that remove logging coverage for critical accounts. SOC and detection teams should validate that identity-provider administrative configuration changes are captured independently from the logs being modified, and that changes affecting sign-in or audit log collection are reviewable. Because no official detection logic is provided, local implementation should focus on change events for logging policies, audit settings, sign-in log settings, and account or group scopes excluded from collection.
Likely telemetry
- Identity provider administrative audit logs
- Configuration change events for sign-in logging and audit logging policies
- Policy update records showing enabled, disabled, or scope-change values
- Privileged administrator activity records
- Change-management or ticketing records for approved logging changes
Detection direction
- Alert or review when sign-in or audit log collection is disabled, weakened, or scoped away from critical accounts.
- Correlate identity-provider logging configuration changes with privileged administrator activity and approved change records.
- Prioritize changes affecting high-value users, privileged roles, service accounts, and administrative groups.
- Validate that detection does not depend solely on the same log stream that could be disabled or modified.
- Tune for legitimate maintenance, migrations, or policy redesigns, but require evidence of approval and compensating visibility.
Mitigation priorities
- Restrict who can modify identity-provider logging and audit configuration.
- Require approval and documented change control for logging coverage changes.
- Monitor privileged changes to logging policies through an independent or protected telemetry path where possible.
- Regularly verify that sign-in and audit logging remains enabled for critical accounts.
- Include identity logging coverage checks in incident response readiness, compliance evidence collection, and control validation exercises.
Analyst notes and limits
This is a detection analytic object, not a technique description. The ATT&CK data provides the behavior, platform, and defender view, but no official detection procedure and no relationship context. The most useful local work is to map the organization’s identity-provider audit settings, critical account inventory, privileged administrators, and change-control evidence to this analytic.
No tactics, relationships, aliases, labels, or official detection logic were supplied. The object supports only Identity Provider platform coverage. Any specific product fields, event IDs, exploit claims, adversary attribution, or confirmed detection effectiveness would require local telemetry or additional sources not provided here.
Analytic 0802
Disabling or modifying sign-in or audit log collection for user activities. Defender view: policy or configuration updates removing logging coverage for critical accounts.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 2f9d9ed10a57… |
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 AN0802Open 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.