Event ID 4723 records an attempt to change an account password in the Security log. Failed attempts can show policy violations or, for local accounts, an incorrect old password. Review Target Account Security ID, Subject Security ID and Subject Account Name, and investigate repeated failures or password changes on sensitive accounts.
Why Event ID 4723 matters to detection and investigation
Event ID 4723 is useful because password-change attempts often sit close to account takeover activity, policy violations, and help desk abuse. A single failure may be benign, but repeated failures or changes on privileged or sensitive accounts can signal attempted unauthorized access, misuse of credentials, or an attacker testing whether an account can be altered without immediate resistance.
The event is most valuable when you treat it as a pivot, not a verdict. Windows Event Log Guide helps you place the event in the broader sequence of account change, logon, and audit activity so you can tell whether the password change was expected, enforced by policy, or part of a larger pattern.
In practice, the event becomes more important when the account is administrative, service-related, shared, or otherwise high impact. Those accounts have more downstream reach, so even a failed change attempt can justify a faster look at who initiated it, from where, and whether the account is protected by stronger controls than an ordinary user account.
What to inspect in the record and surrounding context
The three fields already called out in the alert are the right starting point. Target Account Security ID identifies the account that was being changed, Subject Security ID identifies the actor behind the attempt, and Subject Account Name tells you which identity initiated the action. Together, they answer the key triage question: was this the right person, on the right account, at the right time?
Context matters as much as the event itself. A failed attempt can simply mean the old password was mistyped for a local account, but it can also reflect policy friction, poor reset workflow, or an adversary probing an account they can already access. If the subject account is unusual, such as a service account or a privileged operator account, the failure should be correlated with nearby logon events, administrative actions, and any account lockout or reset activity.
For defenders who collect endpoint telemetry, Sysmon Guide is useful for tying password-change attempts to process creation, remote execution, and other host activity that may explain how the action was performed. That extra context helps distinguish a normal administrative workflow from an interactive intrusion path.
How security teams should respond when failures repeat
Repeated failures are the point where this event shifts from informational to actionable. One-off noise is common, but a cluster of failures against the same target account, especially from an unfamiliar subject account or an unexpected workstation, should trigger a closer look at source address, logon type, timing, and whether the account is protected by a privileged workflow.
If the attempt involves a sensitive account, verify whether the password change was authorized through a known process and whether the account has any linked sessions, scheduled tasks, automation, or integrations that could be disrupted. Password changes on operational accounts can create service outages, but leaving them unchecked can preserve attacker access or conceal misuse of standing credentials.
For correlation and alerting, SIEM Guide supports the operational side of this work: onboard the event, correlate it with failed logons and account changes, and tune alerts so repeated failures on privileged or business-critical accounts rise above background noise.
Risk and Threat Considerations
Event ID 4723 can expose both operational weakness and malicious intent. The main risk is not the event itself, but the possibility that a password-change attempt is being used to test control boundaries, disrupt access, or prepare for account compromise on an identity that has meaningful reach.
Failure mechanism: An attacker, or even an internal user working outside policy, can trigger password-change attempts against accounts they should not be touching, and repeated failures can hide in noisy administrative activity unless teams correlate the target, subject, and timing with other log evidence.
Impact: If the account is privileged, shared, or tied to automation, a successful or partially successful change can lead to lockouts, loss of service, privilege retention through alternate access paths, or a broader investigation into whether the account was already compromised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0, 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 CSF 2.0 | DE.CM-01 — Monitoring for Unauthorized Events | Repeated password-change failures are a monitorable security event. |
| Recommendation — Correlate account-change failures with adjacent identity and host events. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Event 4723 is an audit record that requires review and correlation. |
| AC-2 — Account Management | The event concerns account lifecycle and account change activity. | |
| Recommendation — Review password-change failures and escalate suspicious patterns. Validate account ownership and administrative approval for sensitive changes. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Sensitive accounts and service identities make unauthorized changes more impactful. |
| Recommendation — Restrict high-impact accounts and reduce standing privilege. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Password-change attempts are access-control events tied to account governance. |
| Recommendation — Tighten account-change authorization and review repeated failures. | ||
Practitioner Guidance
What to verify: Confirm whether the target account is human, service, or administrative, and whether the password-change attempt aligns with an approved workflow. For local accounts, verify whether the failure is consistent with a mistyped old password or whether the timing suggests probing.
What to prioritise: Escalate repeated failures on privileged, shared, or high-value accounts before ordinary user noise. The account class matters more than the raw count, because the blast radius of a compromise or unauthorized change is much larger.
Practitioner takeaway: Treat Event ID 4723 as an identity-control signal, not just a password-change log entry. Its value comes from confirming who tried to change which account, whether the attempt was legitimate, and whether the pattern suggests abuse, policy failure, or early compromise.