Event ID 4722 records a user or computer account being enabled in the Security log. For attackers, re-enabling a dormant account can restore access without creating a new identity. Check Target Account Security ID, Target Account Name, Subject Security ID and Subject Logon ID, and confirm the change was authorised, especially for privileged or disabled service accounts.
What Event ID 4722 tells you about account state changes
Event ID 4722 is useful because it marks an account becoming enabled again, which can be more operationally significant than a brand-new account creation. That can happen during normal administration, but it also creates a quiet way for an attacker to restore access on an existing identity, especially when the account already has group membership, history, or trust relationships.
The event becomes more valuable when you treat it as a state-change signal, not just an audit record. A re-enabled account may immediately inherit prior access paths, saved sessions, mapped resources, or delegated permissions that were previously dormant. That is why the event matters most when it involves privileged users, service accounts, or accounts that were disabled as part of an incident response or offboarding action.
If you are triaging it, the key question is not simply whether the account was enabled, but whether that enablement fits the normal approval path. Correlate the event with change tickets, administrative maintenance windows, and any nearby logon or privilege events so you can distinguish legitimate restoration from a stealthy access recovery.
Why re-enablement is a meaningful attacker move
Account re-enablement is attractive because it preserves identity continuity. An attacker does not need to create a new object, wait for approvals, or trigger the same anomaly profile that a new account might create. In practice, that means the action can blend into ordinary administration while still reopening a path into systems that already recognize the account.
That risk is amplified when the account was disabled for security reasons rather than routine HR or support work. If the account was previously privileged, linked to automation, or tied to a legacy dependency, re-enablement can reintroduce access faster than defenders expect. The security team should therefore treat Event ID 4722 as a potential indicator of privilege restoration, not merely a directory update.
Microsoft’s Windows Event Log Guide is the most direct companion for understanding how 4722 fits alongside other account and logon events, while the NIST Privacy Framework is useful where account state changes intersect with governance over sensitive user data and access records.
What to verify before you trust the enablement
Event ID 4722 should be validated against identity ownership, administrative intent, and current access scope. Check which account was enabled, who performed the action, and whether the subject account belongs to a user, a computer object, or a service identity. That distinction matters because a re-enabled service account can restore application access in a way that is easy to overlook.
Look for corroborating evidence in adjacent logs. A legitimate enablement is usually accompanied by a change record, a support workflow, or a known recovery procedure. A suspicious one is often followed by rapid logon attempts, new group memberships, remote access activity, or lateral movement from the same subject context. If the account was disabled during an incident, you should also confirm that the original containment objective has been reversed for a documented reason rather than by mistake.
The NIST SP 800-53 Rev 5 Security and Privacy Controls helps anchor the review in auditability and access-control discipline, and NIST Cybersecurity Framework 2.0 is a useful way to frame the governance and monitoring expectations around such account changes.
Risk and Threat Considerations
Re-enabling an account can re-open a path that defenders assumed was closed, especially when the account still has standing privilege or can reach production systems. The main risk is not the enablement event itself, but the access it restores, which can let an attacker or careless administrator reactivate a trusted identity without creating a fresh detection opportunity.
Failure mechanism: The attacker abuses account state recovery, then uses the restored identity to log in, inherit old permissions, or resume access to systems that still trust the account.
Impact: This can lead to unauthorized access, privilege reuse, service disruption if a dormant service account is reactivated incorrectly, or delayed detection because the action looks like normal administration.
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 | AU-2 — Event Logging | Event ID 4722 is a security log record that must be captured and reviewed. |
| AC-2 — Account Management | The topic is about enabling accounts and validating whether that access should exist. | |
| IA-5 — Authenticator Management | Re-enabled accounts can restore use of credentials and sessions that were previously dormant. | |
| Recommendation — Log and review account-enable events with supporting subject and actor context. Enforce approval, review, and timely disabling for account lifecycle changes. Rotate or invalidate credentials when account reactivation changes exposure. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account enablement is an account-lifecycle control that can reintroduce access. |
| Recommendation — Review and restrict dormant-account reactivation to authorised workflows. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Re-enabling an existing account preserves trusted access and can be abused for persistence. |
| Recommendation — Hunt for suspicious use of restored accounts and correlate with privilege changes. | ||
Practitioner Guidance
What to verify: Confirm whether the enabled object is a human account, computer account, or service account, and check whether its prior role still matches current business need. For privileged identities, validation should include current group membership, recent logon activity, and whether the account was disabled as a containment step.
Escalation / exception: Treat unexplained re-enablement as higher priority when the account has administrative rights, production access, or no obvious owner. If the action cannot be tied to an approved workflow quickly, investigate it as a potential access-recovery event rather than a routine directory change.
Practitioner takeaway: Event ID 4722 matters because it can silently restore effective access, so the real control question is whether the enablement was both authorised and consistent with the account’s current blast radius.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org