Event ID 4720 is logged in the Security log each time a new user account object is created. It applies on domain controllers, member servers, and workstations, and records details such as the SAM account name, primary group, SID history, and delegation settings. Enable Audit User Account Management.
What Event ID 4720 tells you
Event ID 4720 is the account-creation audit record, so its main value is proving that a new user object was created and showing the identity attributes attached at creation time. In practice, this is one of the clearest signals that account population changed, which matters for access review, joiner activity, and unexpected account creation on systems that should stay tightly controlled.
Because the event is logged in the Security log, the first question is not just “did it happen?” but “did it happen where it should have happened?” A 4720 on a domain controller, member server, or workstation may be routine in some environments, but the same event can also mark unauthorized local account creation, failed segregation of duties, or administrative misuse if it appears outside the expected provisioning path.
When you read the record, the useful details are the account name, SID history, primary group, and delegation-related fields. Those fields help you decide whether the new account is a normal employee or service identity, whether it was created with unusual inheritance, and whether it may already have a broader trust footprint than the request implied.
How to interpret it in context
A single 4720 event is rarely the whole story. It should be reviewed alongside adjacent account-management events, authentication activity, and the change record that should have authorized the account. If the account appeared without a ticket, approval trail, or provisioning workflow, the event is less a housekeeping record and more an indicator that identity governance failed somewhere upstream.
For defenders, the value is in correlation. A new account followed quickly by privileged group membership, remote logon, or unusual delegation settings can indicate a staged access path rather than ordinary onboarding. For that reason, 4720 is best treated as a lifecycle signal, not just a bookkeeping event, especially where local accounts, service accounts, or admin-created fallback accounts are allowed to exist.
It is also important to distinguish creation from activation. An account can be created long before it is used, so the creation event alone does not prove compromise, but it does establish when the object entered the environment. That timestamp becomes useful if you later need to determine whether the account existed before a suspicious logon, privilege assignment, or lateral movement sequence.
For practitioners who want a broader Windows event-log reference, the Windows Event Log Guide maps 4720 to related account-change events and helps place it in the wider audit trail. If your environment also relies on endpoint telemetry, the Sysmon Guide is useful for pairing account creation with process and network activity around the same time window.
What to check before you trust the event
Before treating 4720 as benign, verify who created the account, from which host, under which administrative context, and whether the account aligns with an approved provisioning request. If the creator is unexpected, the workstation is unusual, or the account name does not match naming standards, the event deserves follow-up rather than passive logging.
Also check whether the new account was immediately placed into groups, granted delegation, or used to sign in soon after creation. Account creation is often the first step in a larger access path, so a clean-looking 4720 can still sit at the start of an abuse chain if the follow-on events show privilege inflation or remote use.
In Windows environments, the broader audit posture matters as much as the individual event. The PowerShell Security Guide is relevant when account changes are executed through administrative scripts, because script-based provisioning can be legitimate but also makes unauthorized creation harder to spot without strong logging and review discipline.
Risk and Threat Considerations
Account-creation events are attractive to attackers because they can mark the beginning of persistent access, privilege staging, or backup access paths that survive password resets on other accounts. A 4720 event becomes more concerning when it appears outside business hours, comes from a system that should not provision users, or is followed by delegation or privileged group changes.
Failure mechanism: An attacker or insider creates a new account to preserve access, avoid using an existing monitored identity, or prepare a quieter path to privileges. If account creation is not tightly approved and correlated with downstream activity, the new identity can blend into routine administration.
Impact: The organization may gain an unauthorized foothold that is harder to detect than a direct password reset or credential theft event, and that foothold can support privilege escalation, lateral movement, or long-lived access until the account is discovered and removed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | 4720 is a Security log audit record for account creation. |
| AC-2 — Account Management | The event marks creation of a new user account and supports lifecycle control. | |
| AU-6 — Audit Review, Analysis, and Reporting | 4720 is most valuable when correlated with surrounding identity activity. | |
| Recommendation — Ensure account creation events are generated and retained for review. Require approved provisioning and periodic review for every new account. Correlate account-creation logs with group changes and subsequent logons. | ||
| NIST CSF 2.0 | DE.CM-03 — Detect Unusual Activity | Unexpected account creation is a detectable anomalous identity event. |
| Recommendation — Monitor for account creation outside expected provisioning patterns. | ||
| CIS Controls v8 | CIS-5 — Account Management | Event 4720 supports monitoring of account lifecycle and ownership. |
| Recommendation — Track, approve, and review every new user account lifecycle event. | ||
Practitioner Guidance
What to verify: Confirm the account was created through an approved workflow, by an expected admin principal, and on an expected host. If any of those three are missing, treat the event as an exception and inspect adjacent logon, group membership, and delegation records before closing it.
What good looks like: Account creation events are sparse, attributable, and tied to documented joiner, mover, or service-account workflows. The moment a 4720 cannot be matched to an owned process, it stops being routine telemetry and becomes a control test for your identity governance and audit coverage.
Practitioner takeaway: Event ID 4720 is most useful when you treat it as the start of an access story, not the end of one, and validate the approval, creator, and immediate post-creation activity before assuming the account is legitimate.