Event ID 4726 records the deletion of a user account in the Security log on domain controllers, member servers and workstations. Deleting accounts can hide evidence, remove access or disrupt operations. Check Target Account Security ID, Subject Security ID, Subject Account Name and Target Account Domain, and confirm the deletion against approved change records.
What Event ID 4726 tells you about account deletion
Security teams should treat Event ID 4726 as a high-signal account-management event because it marks the removal of a user from an authentication boundary. That can be benign, but it can also be the first visible sign that an attacker is reducing the chance of recovery, removing a monitored account, or interfering with normal access paths.
The practical value is not the alert by itself, it is the context around it. A deletion on a domain controller can have different meaning from the same event on a member server or workstation, so the surrounding asset role, timing, and related activity determine whether the event is routine administration or a security problem that needs immediate follow-up.
For teams that want a broader Windows logging baseline, the Windows Event Log Guide is the most direct companion resource because it places 4726 alongside the other account-change and log-clearing events that help explain whether this deletion fits a normal change pattern.
How to read the event without overreacting
Event ID 4726 becomes actionable when it lines up with identity and change data that should already exist elsewhere. The Target Account Security ID and Target Account Domain tell you exactly which account disappeared, while the Subject Security ID and Subject Account Name tell you who or what initiated the deletion. That attribution matters because a legitimate admin action should usually map to a known operator, ticket, or automation path.
Investigation should also look for nearby signals that strengthen or weaken the case for abuse. A deletion shortly after failed logons, privilege changes, remote administration, or unusual PowerShell activity is more concerning than a deletion that cleanly matches a scheduled deprovisioning task. A useful baseline is to compare the event to other Windows log sources, since account deletion is often one step in a wider sequence rather than a standalone action.
If your telemetry stack is built around Windows event collection and enrichment, the SIEM Guide helps frame how this event should be correlated rather than viewed in isolation.
What good investigation and response look like
Teams should confirm whether the deletion was approved, whether the account had privileged or service access, and whether the same subject deleted other accounts or altered group memberships around the same time. If the account belonged to an admin, service process, or investigation workflow, the deletion may have broader impact than simple account loss because it can interrupt operations and obscure accountability.
When the event is unexpected, response should focus on containing the account lifecycle change before assuming it is harmless. That means validating the change record, checking for concurrent control-plane activity, and reviewing whether any adjacent accounts or sessions were also touched. If the deletion was malicious, you may need to restore or recreate the account, review dependent services, and check for evidence of persistence or follow-on privilege changes.
Where Windows telemetry is already under active review, the Sysmon Guide is useful as a complementary reference for building the kind of endpoint visibility that makes event correlation and tamper spotting more reliable.
Risk and Threat Considerations
Account deletion can be used to reduce visibility, interrupt recovery, or remove access that defenders depend on during an incident. It is especially risky when the deleted account is tied to privileged administration, monitoring, or automation, because one event can remove both access and accountability at the same time.
Failure mechanism: An attacker or rogue administrator uses a legitimate deletion action to erase an account that would otherwise reveal activity, preserve access, or help investigators trace the intrusion. In more advanced cases, the deletion is paired with log tampering, privilege reassignment, or staged changes to delay detection and complicate restoration.
Impact: The immediate impact can be loss of access for a legitimate user, disruption of scheduled operations, and a weaker forensic trail. In a compromise scenario, the event may also indicate that the attacker is shaping the environment for persistence or making incident response slower and less reliable.
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 |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Account deletion events need correlation and review to detect misuse. |
| AC-2 — Account Management | The event is an account lifecycle control point affecting creation, deletion, and revocation. | |
| Recommendation — Correlate 4726 with adjacent logs and review suspicious deletions promptly. Tie 4726 handling to authoritative account lifecycle records and approvals. | ||
| CIS Controls v8 | CIS-5 — Account Management | User deletion is an account-management safeguard and change-control concern. |
| Recommendation — Verify deleted accounts against approved account-management processes and recertification. | ||
| MITRE ATT&CK | T1531 — Account Access Removal | Deleting accounts is a known technique used to remove access and complicate recovery. |
| Recommendation — Map suspicious deletions to account-access-removal activity and hunt for follow-on abuse. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | The event is useful only when monitored and correlated as an anomalous change. |
| Recommendation — Monitor account-deletion events and investigate deviations from expected change patterns. | ||
Practitioner Guidance
What to verify: Confirm the deletion against an approved change, then validate the subject account, target account, host role, and timestamp against adjacent authentication and administration activity. If the target had elevated rights or supported a business-critical process, treat the event as higher priority even if the deletion itself appears routine.
Decision rule: If the deletion cannot be tied to a known workflow, escalate it as a potential security incident and review surrounding account, privilege, and log activity before closing it as administrative noise. If the deletion was approved, still confirm that no dependent service, delegated access path, or investigation account was unintentionally removed.
Practitioner takeaway: Event ID 4726 is most valuable when you treat it as a lifecycle control point, not just an audit record, because the key question is whether the deletion fits a trusted change process or is part of a broader attempt to hide or disrupt access.