Event ID 4722 shows a disabled account was enabled, which can be normal administration or a sign that an attacker reactivated an account for access. Pay attention to who enabled it, which account was changed, and whether the account is a user or computer object. Unexpected re-enablement of dormant privileged accounts deserves immediate review.
What Event ID 4722 is really telling you
Event ID 4722 is about an account moving from disabled to enabled. That is not automatically malicious, because administrators do reactivate accounts during normal operations. The security question is whether the enablement was expected, who performed it, and whether the target was a routine user account or something with inherited access that changes the risk profile.
To judge the event, treat the change as an access-state transition rather than a standalone alarm. A benign helpdesk or HR-driven reactivation looks different from a dormant privileged account coming back to life, especially if the account had been inactive for a long time or appears outside the normal ownership path. The Windows Event Log Guide is useful here because it groups 4722 with the surrounding account-management events that help reconstruct the full sequence.
The account type also matters. A re-enabled user account may simply restore ordinary access, but a re-enabled computer object or an account tied to automation can indicate something more operationally sensitive. That is why this event should be read alongside the identity, the system it belongs to, and any recent changes to group membership, delegated rights, or login behaviour. Pairing the 4722 event with other telemetry from Sysmon Guide helps confirm whether the account was merely changed or was also used immediately after reactivation.
In practice, the event becomes more interesting when it breaks an expected lifecycle pattern. If an account was disabled for a reason such as departure, cleanup, or incident response, re-enablement can indicate administrative drift, process failure, or an attacker attempting to restore a foothold. The key judgment is not “was it enabled?” but “does this enablement fit the normal lifecycle of this identity?”
Attackers who gain access to privileged admin pathways may prefer re-enabling an old account over creating a fresh one, because it can look routine and preserve existing trust, group membership, or application linkage. That makes the event useful for finding both abuse of legitimate admin rights and post-compromise persistence that tries to blend into ordinary account maintenance. The same pattern is consistent with broader account abuse trends discussed in The State of NHI & AI Agent Breach Report 2026, where stolen access and reused identities are part of the attacker playbook.
What evidence separates normal administration from suspicious reactivation?
Start with the actor who enabled the account, then compare that actor to the approved workflow for account restoration. If the enabling principal is unexpected, overprivileged, or acting outside change control, the event deserves closer review. The next question is whether the account was a human user, a service identity, or a computer object, because each one has a different blast radius and different normal ownership.
Timing is another strong indicator. A re-enable that occurs shortly before a login, privilege grant, task creation, or remote access event is far more concerning than one followed by no activity at all. If the disabled period was long, or if the account had previously been retired, the probability of abuse rises because the account may have been selected specifically for its low visibility.
Look for linked event patterns rather than a single record. A suspicious sequence can include re-enablement, group membership changes, logon attempts, and then lateral movement or service creation. Even when the enable action itself is legitimate, adjacent events can reveal whether the account was restored for business reasons or used as an initial access bridge.
The account’s privileges are central to the interpretation. Re-enabling a standard user may be low risk, while re-enabling an account that can administer servers, access backup systems, or run scheduled tasks can materially change the exposure. That is why dormant privileged accounts deserve faster triage than ordinary accounts, even when the event is technically identical.
How to investigate and respond without overreacting
First verify whether the enablement was requested, approved, and attributable to a known administrator or system process. If that evidence is missing, treat the event as potentially suspicious until you can confirm the business reason. The investigation should then test whether the account could still authenticate, what resources it touched after reactivation, and whether any privilege escalation followed.
When the account is high-value, prioritize containment around credentials and access paths before spending time on narrative reconstruction. If the enablement exposed a dormant privileged account that may have been known to an attacker, rotate dependent secrets, review recent sessions, and confirm that no persistence was established through group changes, scheduled tasks, or delegated access. For defenders who want a broader logging baseline around this kind of account activity, the PowerShell Security Guide is relevant when administrative reactivation is paired with script-based follow-on action.
What to verify: Confirm who enabled the account, whether the change was approved, and whether the account has any inherited access that makes reactivation materially risky.
Decision rule: If the re-enabled account is privileged, long-dormant, or immediately active after change, treat the event as a potential access-restoration incident, not routine housekeeping.
Practitioner takeaway: Event ID 4722 is most useful when you anchor it to identity ownership, privilege, and follow-on activity, because the account-enable action is only the start of the question.
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 |
|---|---|---|
| MITRE ATT&CK | T1098 — Account Manipulation | Re-enabling disabled accounts can restore access or persistence for an attacker. |
| Recommendation — Hunt for account reactivation alongside other account-manipulation activity and suspicious privilege changes. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | 4722 becomes actionable when audit review ties the event to who changed access and why. |
| AC-2 — Account Management | The event is an account lifecycle change that should be governed and reviewed under account management. | |
| IA-5 — Authenticator Management | Re-enabled accounts may expose dormant credentials that should be validated or rotated. | |
| Recommendation — Review account-management logs and correlate 4722 with adjacent authentication and privilege events. Require approval, ownership, and periodic review for account reactivation. Validate or rotate credentials for reactivated accounts before trusting renewed access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account enablement is an account management control point that affects exposure and lifecycle risk. |
| CIS-8 — Audit Log Management | This event must be correlated with surrounding logs to distinguish administration from abuse. | |
| Recommendation — Track disabled and re-enabled accounts and investigate unexpected lifecycle reversals. Centralize and review account-change logs to spot suspicious reactivation patterns. | ||