Event ID 4720 records that a user account was created in the Windows Security log. It is written when a new user object is created on domain controllers, member servers, and workstations. Defenders check SAM Account Name, Primary Group ID, SID History, and Allowed To Delegate To for suspicious account creation and privilege setup.
What Event ID 4720 Signifies in Windows Security Logging
Event ID 4720 is one of the core account-management records defenders use to spot new user creation on Windows systems. It matters because account creation is often the first step in persistence, privilege staging, or unauthorized access after an initial foothold.
On domain controllers, member servers, and workstations, the event confirms that a user object was created, but it does not by itself explain intent. Security teams therefore treat it as a starting point for correlation, checking whether the account name, group placement, delegation settings, and identifier history align with expected administration.
What Defenders Look For in a 4720 Event
The most useful fields are the ones that reveal whether the new account is ordinary administration or a setup for abuse. Suspicious patterns include unusual SAM Account Name choices, unexpected primary group membership, SID History values that preserve earlier privileges, and Allowed To Delegate To settings that broaden where the account can be used.
Those details matter because account creation can be benign while the surrounding attributes are not. A newly created account with delegation capability or inherited security context can be used to reach resources the creator should not normally access, especially if the change occurs outside approved provisioning workflows.
Event 4720 also becomes more valuable when read alongside adjacent account and logon activity. Creation followed by immediate group changes, unusual logons, or changes to nearby security settings can turn a routine administrative event into a stronger indicator of compromise.
How 4720 Fits into Windows Detection and Investigation
Defenders use Event 4720 as part of account-lifecycle monitoring rather than as a standalone alert. The event helps establish when a new principal appeared, which account performed the creation, and whether the creation aligns with ticketed change activity, onboarding, or emergency access procedures.
Windows Event Log Guide is the natural reference point for understanding how 4720 sits alongside related Windows audit records, log retention, and forwarding patterns. That broader context is what makes the event useful for triage instead of just historical recordkeeping.
In practice, the investigation usually asks whether the account is expected, whether it was created from a trusted administrative path, and whether the surrounding audit trail shows later privilege assignment or lateral movement. Without that context, 4720 is informative but incomplete.
Why 4720 Matters for Access Governance and Response
Event ID 4720 is not just an audit artifact, it is an access-governance signal. A created account can become a durable foothold if it is overlooked, overprivileged, or left active after the work that justified it has ended.
For that reason, defenders treat unexpected account creation as a trigger to validate ownership, purpose, and downstream permissions. When the account is legitimate, it should still be reviewed for least privilege and timely removal once no longer needed. When it is not legitimate, the event can be the first visible sign that account hygiene or administrative control has already failed.
Sysmon Guide can help teams extend visibility beyond the native audit event when they want better process, network, or tamper context around suspicious account activity. Kerberos Security Guide is also useful when a newly created account is later used for ticket-based authentication or delegation abuse.
Risk and Threat Considerations
New account creation is attractive to attackers because it can create persistence that looks like normal administration. A maliciously created account may be used immediately, delegated wider access than expected, or hidden among legitimate provisioning noise if monitoring is weak.
Failure mechanism: The defender sees an account creation event but does not validate whether the account was approved, whether its attributes are safe, or whether it later received access that exceeds its intended role.
Impact: An attacker can preserve access, expand privileges, or establish a reusable identity for later logon, delegation abuse, or follow-on movement.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Event 4720 records account creation and supports account lifecycle control. |
| IA-5 — Authenticator Management | New accounts require managed credentials and lifecycle handling after creation. | |
| AU-12 — Audit Record Generation | The event is an audit record used to detect and investigate account creation activity. | |
| Recommendation — Review new accounts under AC-2 and remove or disable those that are not justified. Apply IA-5 to issue, rotate, and revoke credentials tied to newly created accounts. Ensure AU-12 coverage captures account creation events for monitoring and review. | ||
| CIS Controls v8 | CIS-5 — Account Management | CIS controls emphasize managing accounts throughout their lifecycle, including creation and review. |
| Recommendation — Use CIS-5 to govern account creation, approval, and removal. | ||
| MITRE ATT&CK | T1136.001 — Create Account: Local Account | Adversaries create accounts to establish persistence on Windows systems. |
| Recommendation — Map suspicious 4720 activity to T1136.001 and hunt for persistence using the new account. | ||
Practitioner Guidance
What to watch for: Treat 4720 as a workflow checkpoint, not a box-tick event. The key judgement is whether the new account belongs to a known provisioning path and whether its attributes match the access it actually needs.
Governance implication: Make sure account-creation review includes ownership, purpose, and expected lifecycle so that new accounts do not become long-lived access paths by default. When the account is unexpected, investigate the creator, the surrounding audit trail, and any immediate permission changes before assuming the event is benign.