Event ID 4722 is logged in the Security log whenever a user or computer account is enabled. For computer accounts, it is logged only on domain controllers. It records the target and the actor, so defenders can spot reactivated accounts that may have been disabled during response or by mistake. Enable Audit User Account Management.
What Event ID 4722 tells you in the Security log
Event ID 4722 is an account-management signal, not an authentication failure or logon event. It tells you that an account was enabled, which means the directory state changed from disabled to active. That matters because enabled accounts can immediately regain access if their group membership, privileges, or credentials are still valid. For computer accounts, this event appears only on domain controllers, so collection coverage matters.
In practice, 4722 is most useful when you correlate it with the target account, the actor that performed the change, and the surrounding account-management events. A single enable action may be routine administration, but it can also mark the end of an incident containment action, a recovery mistake, or an unauthorized reactivation of an account that should have stayed disabled.
Because the event is tied to account state change, it belongs in the same monitoring workflow as other directory and logon activity. The Windows Event Log Guide is a useful companion when you need to place 4722 beside the broader set of account, logon, and audit events that show whether access was actually usable after the enable action.
Why 4722 matters for detection and investigation
Event 4722 becomes meaningful when you treat it as a possible re-entry point. A disabled account is often disabled because it was compromised, dormant, or administratively removed from service. When it is re-enabled, the important question is whether that change was expected, who approved it, and whether the account still has any standing access that could be abused right away.
For defenders, the event is most valuable when matched to change tickets, incident timelines, and subsequent use of the account. If the same account logs on soon after being enabled, or if a privileged account is reactivated outside a normal maintenance window, that is a strong reason to review scope, attribution, and whether additional controls need to be tightened before the account is left active.
Directory and endpoint telemetry should support that review. If you are already collecting richer host telemetry, the Sysmon Guide helps with the adjacent process and network visibility that can confirm whether an enabled account was used for real activity after the Security log recorded the state change.
How to handle 4722 without missing the real risk
The key operational question is not whether the event exists, but whether the enable action was authorised and safe. If the account was intentionally reactivated, you still need to confirm that the reason for disabling it no longer applies. If it was enabled unexpectedly, treat it as a possible access-restoration event and verify whether the actor had legitimate authority to do so.
For incident response, 4722 should trigger a quick blast-radius check. Determine whether the account is user or computer based, whether it has elevated group membership, whether it can authenticate to sensitive systems, and whether any sessions, tokens, or cached access could now be reused. The event alone does not prove compromise, but it does prove that the access path was reopened.
On Windows environments, the event is only useful if auditing is actually enabled and the logs are retained long enough to support review. If you need a stronger baseline for Windows account activity and related audit coverage, the PowerShell Security Guide is relevant where administrative enablement work overlaps with scripting, logging, and reviewability.
Risk and Threat Considerations
An enabled account can instantly restore access that defenders assumed was gone. The main risk is not the audit record itself, but the possibility that a disabled account, especially one with privileged access, is brought back to life without full review of its current permissions, trust relationships, or prior compromise status.
Failure mechanism: A user or computer account is re-enabled while its privileges, group memberships, or prior compromise exposure remain unchanged, allowing immediate reuse for legitimate or malicious access.
Impact: Attackers or mistaken operators can regain access to systems, re-establish persistence, or bypass containment by reactivating an account that should have stayed disabled.
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, 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-12 — Audit Record Generation | 4722 depends on account-change auditing being generated in the Security log. |
| AC-2 — Account Management | The event is about account enablement, a core account lifecycle action. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Defenders must review 4722 with actor and target context to spot suspicious reactivation. | |
| Recommendation — Enable audit generation for account-management events so reactivations are recorded. Review and authorise account reactivation before restoring access. Correlate 4722 with change records and follow-on logons to validate the enable action. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account enablement is an account-management event that needs controlled lifecycle handling. |
| Recommendation — Keep account enable and disable actions under controlled, reviewed lifecycle processes. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication and Access Control | Re-enabling an account directly affects identity state and access authority. |
| Recommendation — Validate that restored accounts still have only the access they need. | ||
Practitioner Guidance
What to verify: Confirm who enabled the account, why it was disabled in the first place, and whether the enable action aligns with a ticket, break-glass procedure, or incident recovery plan. For computer accounts, verify the event came from a domain controller and that the reactivation is intentional.
What to measure: Track enabled accounts that remain unused, privileged accounts re-enabled outside change windows, and the time between enablement and first subsequent logon. Those are the signals that tell you whether account reactivation is controlled or just reverting to risk.
Practitioner takeaway: Treat 4722 as a control point for access restoration, not just a log entry. The critical decision is whether the re-enabled account is still safe to trust at its previous privilege level.