Event ID 1102 is a Windows Security audit event that records when the Security audit log is cleared. It is a high-signal tampering event because clearing logs can hide other activity. Investigate the subject account and logon ID immediately to determine whether the clear was authorised and what occurred beforehand.
What Event ID 1102 Means in Windows Security Logging
Event ID 1102 is not a routine audit record, it is a signal that the Security log itself was cleared. Because this action can remove evidence of prior activity, it should be treated as a tampering indicator until the explanation is verified.
Its value comes from context: a cleared Security log may be legitimate during maintenance, but it is also a common way to reduce visibility after suspicious access, privilege abuse, or attempted persistence. The event is therefore less about the act of clearing alone and more about the loss of forensic continuity.
Why Log Clearing Is Operationally Significant
Security logs preserve the sequence needed to understand authentication, privilege use, object access, and process activity. When those records disappear, defenders lose the timeline that often answers the first question in an investigation: what happened immediately before the tampering?
That is why Event ID 1102 is treated as high signal, not because every clear is malicious, but because it changes the reliability of the evidence base. A cleared log can hide failed logons, lateral movement, PowerShell abuse, service creation, or other precursor activity that would otherwise support containment and attribution.
For Windows-centric monitoring, the Windows Event Log Guide is the most direct reference for the audit policy and event-ID context around log clearing and related administrative activity.
How Analysts Investigate Event ID 1102
The first investigation step is to identify the subject account and the associated logon ID, then correlate them with nearby authentication, privilege, and process events. That correlation helps separate authorised housekeeping from a compromised admin session or misuse of legitimate access.
Analysts usually pivot to adjacent telemetry, including logon and logoff records, process creation, service changes, scheduled task activity, remote access traces, and any available forwarded logs from the same host or collector. If the local Security log was cleared, other sources may still preserve enough context to rebuild the sequence.
Where Windows telemetry is enriched with endpoint monitoring, tamper-aware tooling can provide an independent trail. The Sysmon Guide is useful here because Sysmon can preserve process, network, and registry evidence that may survive or complement Security log loss.
Detection, Hardening, and Evidence Preservation
Event ID 1102 should drive both alerting and resilience planning. Logging pipelines, forwarding, and retention matter because local logs are fragile by design, and the most important evidence is often the shortest-lived.
Operationally, organisations should keep audit policy tight enough to capture meaningful activity, forward logs off-host where possible, and monitor for any sign that logging is being reduced, disabled, or overwritten. That includes surrounding signals such as audit policy changes, service tampering, and unusual administrative sessions.
For broader detection coverage around command-line abuse, script logging, and administrative tooling, the PowerShell Security Guide helps connect log clearing to the kinds of post-access activity that defenders often need to reconstruct.
When the question is whether the clearing was part of an intrusion, threat-hunting frameworks also help structure the review. The Kerberos Security Guide is especially relevant when the investigation needs to test for identity compromise, ticket abuse, or other authentication-layer activity that may precede log tampering.
Risk and Threat Considerations
Clearing the Windows Security log is dangerous because it removes one of the most trusted sources of post-event visibility. That creates immediate investigation risk, and when the action is unauthorised it can also signal an attempt to conceal compromise, privilege abuse, or lateral movement.
Failure mechanism: An attacker or rogue administrator clears local audit evidence after gaining access, which breaks the timeline needed to reconstruct preceding authentication, process, and privilege events.
Impact: Defenders may miss the initial access path, misjudge dwell time, or lose the ability to prove what happened before containment, which can delay response and weaken forensic confidence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1070 — Indicator Removal on Host | Log clearing is a classic host-based evidence removal tactic. |
| Recommendation — Map 1102 to T1070 and hunt for evidence of log tampering before and after the clear. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | 1102 is an audit event that depends on review and analysis of security logs. |
| AU-9 — Protection of Audit Information | Clearing the Security log directly challenges protection of audit information. | |
| AU-11 — Audit Record Retention | Investigation of 1102 depends on retaining logs long enough to reconstruct events. | |
| Recommendation — Review audit records quickly and correlate 1102 with adjacent host and identity activity. Protect audit data so clearing a local log does not erase your only evidence source. Retain and forward logs so pre-clear activity remains available after tampering. | ||
| CIS Controls v8 | 8 — Audit Log Management | Event 1102 is directly about audit-log tampering and preservation. |
| 13 — Network Monitoring and Defense | Correlated network evidence can help reconstruct activity after a local log clear. | |
| Recommendation — Centralise and protect audit logs so clearing the local Security log does not destroy evidence. Use out-of-band monitoring to retain visibility when a host log is cleared. | ||
| NIST CSF 2.0 | DE.CM-03 — Monitor Personnel and External Service Provider Activity | 1102 is a monitorable event that can indicate suspicious user or admin activity. |
| PR.DS-04 — Store Data in a Manner that Protects Its Confidentiality, Integrity, and Availability | Audit logs are security data whose integrity and availability must be preserved. | |
| DE.AE-02 — Analyze Events to Understand Attack Targets and Methods | A cleared Security log requires analysis of surrounding events to infer method and intent. | |
| Recommendation — Correlate cleared-log events with monitored activity to identify suspicious sessions. Store logs centrally and protect their integrity so evidence survives local tampering. Analyze the surrounding event sequence to determine whether the clear was authorised or malicious. | ||
Practitioner Guidance
What to watch for: Treat Event ID 1102 as a triage trigger, not a standalone verdict. The key question is whether the clear aligns with a known maintenance window and a known account, or whether it appears during an active investigation gap, a privileged session, or an unexpected host interaction.
Practitioner takeaway: The value of this event is proportional to the rest of your telemetry, if the local log is gone but forwarded or endpoint data remains, you still have a chance to recover the story.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org