Event ID 4722 records that a user account was enabled in the Windows Security log. It is logged when a user or computer object is enabled, with computer accounts only on domain controllers. Defenders review Target Account Security ID, Target Account Name, Subject Security ID, and Subject Logon ID for unexpected reactivation of accounts.
What Event ID 4722 Tells You
Event ID 4722 is a Windows Security log signal that an account was enabled again. In practice, that means a previously disabled user or computer object has been reactivated, so defenders treat it as a change in account state rather than a login event.
This matters because re-enabling an account restores the ability to authenticate and access systems, often with whatever permissions and group memberships the account already held. When the change is unexpected, it can indicate an administrative mistake, an account recovery workflow that was not validated, or an attacker reviving a dormant account for reuse.
For deeper Windows logging context, the Windows Event Log Guide is the most direct companion reference for understanding how account-change events fit into the wider audit trail.
How to Interpret the Event Details
The useful fields are the Target Account Security ID, Target Account Name, Subject Security ID, and Subject Logon ID. Together they tell you which account was enabled and which security principal performed the action, which is essential for separating routine administration from suspicious reactivation.
Context also matters. A single enable event can be benign if it follows an approved help desk or IAM process, but it becomes more important when it affects a privileged account, a service account, or an account that has been disabled for security reasons. In those cases, the event should be read alongside related account-change events, group membership changes, and subsequent logons.
Because the event is part of the Windows Security log, it should be correlated with other authentication and account-management telemetry rather than treated as a standalone alert. The same account may also appear in later logon activity, which helps confirm whether the enablement was used immediately or remained unused.
For a broader view of adjacent Windows telemetry, the Sysmon Guide helps place host activity and log correlation around the account-change signal, while the PowerShell Security Guide is useful when account reactivation is followed by scripted administration or suspicious remote management.
Why Event ID 4722 Matters for Detection
Unexpected account enablement is important because disabled accounts are often assumed to be inactive, retired, or intentionally blocked. Re-enabling them can restore access to systems, data, and administrative functions without creating a brand-new account that would stand out in review.
That makes Event ID 4722 a useful hunting point for account resurrection, abuse of dormant credentials, and unauthorized recovery of access. In environments with weak disablement hygiene, old accounts may be re-enabled and used before monitoring catches the change.
When the account is tied to Kerberos-based access paths, the Kerberos Security Guide helps explain why reactivated accounts can quickly become authentication anchors for broader access if they are not reviewed promptly.
How Analysts Should Use It in Investigation Work
Analysts should treat the event as a starting point for account-state validation. The key question is not only whether the account was enabled, but whether that action matches the normal owner, process, and timing for the environment.
Investigation usually focuses on whether the Subject Security ID is an expected administrator or service principal, whether the Target Account Name is a privileged or sensitive account, and whether the reactivation lines up with a ticket, approved change, or known recovery request. If no legitimate reason exists, the event deserves follow-up as a potential precursor to misuse.
In mature monitoring programs, the event is most valuable when paired with account lifecycle controls, alerting on high-risk principals, and review of subsequent logon and privilege activity. On its own, it is a state-change record; in context, it can become a strong indicator of access restoration that should have been controlled and observed.
Risk and Threat Considerations
Re-enabling an account can quietly restore access that defenders believe is unavailable, especially when the account was disabled for security, personnel, or privilege reasons. That creates exposure if the reactivation is unauthorized, poorly reviewed, or followed immediately by logon activity.
Failure mechanism: An attacker or insider who can trigger account enablement, or abuse a legitimate enablement workflow, may revive dormant access and reuse existing permissions without creating a new identity trail.
Impact: The account can regain access to systems, data, and administrative functions, increasing the chance of unauthorized access, privilege abuse, or persistence through a previously disabled principal.
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 4722 records account enablement, a core account lifecycle control point. |
| AU-6 — Audit Review, Analysis, and Reporting | Security logs must be reviewed to detect unexpected account reactivation. | |
| IA-5 — Authenticator Management | Re-enabled accounts may require credential reassessment if the account was disabled due to compromise or dormancy. | |
| Recommendation — Review enablement events under AC-2 and require documented approval before reactivating disabled accounts. Correlate 4722 with related audit events and investigate unusual account enablement promptly. Revalidate credentials and reset secrets when a disabled account is reactivated after risk-related suspension. | ||
| CIS Controls v8 | 5 — Account Management | Event 4722 is directly about restoring account state and should be governed through account management. |
| Recommendation — Track and approve account reactivation events as part of account lifecycle governance. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Enablement of an account is a form of account manipulation that can support persistence or access restoration. |
| Recommendation — Map suspicious 4722 activity to account-manipulation detection and hunt for follow-on access. | ||
Practitioner Guidance
What to watch for: Prioritise enable events for privileged accounts, dormant accounts, and accounts that were disabled for a specific risk reason. Those are the cases where the event is most likely to represent an access control failure rather than routine maintenance.
Governance implication: Re-enablement should be tied to a clear owner and a reviewable reason, because the event restores effective access rather than merely changing a directory attribute. If your monitoring cannot quickly explain who enabled the account and why, the control is incomplete.