When is Event ID 4723 logged?

What Event ID 4723 Captures in the Security Log

Event ID 4723 is an account-management audit event, so the useful question is not just whether it appears, but what user action caused it. It records a password-change attempt against a specific target account, along with the subject account that initiated the change. In practice, it is one of the clearer signals that someone is trying to alter credentials rather than merely log on.

A 4723 event gives you the account pair involved in the action, which is important for understanding whether the change was self-service, helpdesk-assisted, or potentially suspicious. Because password changes affect access continuity, this event often becomes a pivot point when investigating access problems, lockouts, or unexpected account activity.

If you want a broader view of how Windows records password-related and other account events, the Windows Event Log Guide is the best anchor point for correlating 4723 with neighbouring security events such as account changes, logons, and policy-related failures.

When 4723 Appears, and What the Failure Signals Mean

4723 is logged when the system processes a password-change request, not only when the password is successfully changed. That means the event can show both routine administrative activity and unsuccessful attempts. The failure detail matters: a policy rejection suggests the new password did not meet the password rules, while a local-account failure can indicate the old password was entered incorrectly.

That distinction helps with triage. A policy failure usually points to a control issue, a user mistake, or a weak password choice. An old-password failure on a local account is more likely to be an authentication problem at the point of change, which may be legitimate, or may indicate someone is probing credentials without already having valid knowledge of the existing password.

For teams monitoring Windows telemetry at scale, the practical value is correlation. A single 4723 event is rarely enough on its own; it becomes meaningful when paired with surrounding account-management events, repeated failures, or an unusual timing pattern. If you are using endpoint telemetry to confirm whether the system itself is recording related activity, Sysmon Guide is useful for understanding where process, configuration, and tamper signals may complement native Windows logs.

How to Validate, Monitor, and Respond to 4723 Activity

To use 4723 correctly, first confirm that audit policy is enabled for user account management, otherwise the event may not be present when you expect it. Then decide whether the event matches an expected workflow, such as a helpdesk reset, a scheduled admin action, or a user-initiated password update. The target account and subject account fields are the key data points for that check.

If the event is unexpected, focus on the context around it rather than the event alone. Repeated password-change failures, especially across multiple accounts or at unusual hours, deserve closer review because they can indicate credential probing, operational confusion, or attempts to disrupt account access. In environments where administrators or helpdesk staff script changes, review the process used to perform the action so that legitimate automation does not mask risky behaviour. For teams that rely heavily on administrative scripting, the PowerShell Security Guide helps connect account-management telemetry to script logging and administrative visibility.

Practitioner Guidance

What to verify: Confirm that 4723 is being generated for the account classes you care about, and that your logging pipeline preserves both subject and target account values. Without those fields, the event is much less useful for distinguishing self-service changes from administrative intervention.

Decision rule: If the password change was expected and succeeds, treat 4723 as routine audit evidence; if it fails repeatedly, or the subject account does not fit the normal change path, escalate to identity and access review rather than treating it as a simple helpdesk issue.

Practitioner takeaway: Event ID 4723 is most valuable when you use it as a context event, not a standalone alert, because the investigative value comes from who initiated the change, which account was targeted, and whether the failure pattern matches policy, user error, or suspicious activity.

Related resources from NHI Mgmt Group

• When is Event ID 4624 logged?
• When is Event ID 4648 logged?
• When is Event ID 4625 logged?
• When is Event ID 4663 logged?