Event ID 4738 is the Windows Security log entry that means a user account was changed. Windows writes it whenever someone modifies a user account object, and it records who made the change, which account was affected, and which attributes changed. It sits in the Audit User Account Management subcategory and appears on domain controllers, member servers, and workstations. For security teams, 4738 is one of the clearest signals that an account was altered, whether by a routine admin task or by an attacker. This guide explains what the event records, how to read each field, where it falls short, and which changes are worth alerting on.
Key takeaways
- Event ID 4738 means A user account was changed, and Windows logs one event per change in the Security log.
- It has three parts: Subject (who), Target Account (which account), and Changed Attributes (what changed, showing new values).
- It lives in the Audit User Account Management subcategory and appears on domain controllers, member servers, and workstations.
- The most security-relevant fields are the UAC flags, delegation (AllowedToDelegateTo), Primary Group ID, and SID History.
- It usually shows only new values, and can appear empty (all "-") when an unlisted attribute changed, so it isn't a full change diff.
Quick explanation
In simple terms
Event 4738 is Windows' way of saying "someone changed a user account." It's a security log entry noting who made the change, which account, and what was altered.
Technical definition
Event ID 4738 (A user account was changed) is a Windows Security audit event emitted by the Microsoft-Windows-Security-Auditing provider under the Audit User Account Management subcategory. It records Subject, Target Account, and Changed Attributes (new values), including SAM account-control flags (Old/New UAC Value and a human-readable User Account Control list).
Analogy
Think of it as a building's visitor log for one office: it notes that someone entered and edited a file, who they were, and which file, but it usually shows the new contents, not what was there before.
Definition
Event ID 4738 is a Windows Security audit event, with the message A user account was changed, that Windows records whenever a user account object is modified. It logs under the Audit User Account Management subcategory on domain controllers, member servers, and workstations.
Event ID 4738, with the message "A user account was changed," is a Windows Security audit event that fires every time a user account object is modified. Windows writes it through the Microsoft-Windows-Security-Auditing provider into the Security event log, and it generates one separate 4738 for each change.
The event belongs to the Audit User Account Management subcategory, under the Account Management category of the advanced audit policy. It records on domain controllers for domain accounts and on the local machine for local accounts, so you'll see it on servers and workstations too. Its legacy event ID, from pre-Vista Windows, is 642.
A 4738 has three parts. Subject is who made the change. Target Account is the account that was changed. Changed Attributes lists the affected properties, showing the new value, with a "-" for anything that wasn't changed. There's also an Additional Information section for any privileges used.
One quirk matters up front. You can see a 4738 where every Changed Attribute is "-". Per Microsoft's documentation, this happens when a change hits an attribute the event doesn't list, such as the account's DACL, and there's no way to tell which attribute changed. Some changes don't generate a 4738 at all.
Why it matters
Core concepts
When a 4738 fires
Windows logs a 4738 each time a user account object is changed, one event per change.
A 4738 is generated every time a user object is modified, and each change produces its own event. It records on the machine that's authoritative for the account: a domain controller for domain accounts, the local computer for local accounts.
Two behaviors surprise people. First, you can get a 4738 with every Changed Attribute set to "-". Microsoft explains this happens when the change hits an attribute the event doesn't list, such as the DACL, so you can't tell what changed. Second, some changes don't fire a 4738 at all, so absence of an event isn't proof nothing changed.
Example
Editing a user's profile path or flipping a UAC flag each generates its own 4738 event.
Why it matters — Knowing when the event does and doesn't fire keeps you from over-trusting it as a complete record.
The Subject: who made the change
The Subject block identifies the account that performed the change.
The Subject section names the account that requested the change. It includes a Security ID (SID), Account Name, Account Domain, and a Logon ID. The SID uniquely identifies the principal, and Event Viewer tries to resolve it to a readable name.
The Logon ID is the useful part for investigation. It's a hex value you can match against the same Logon ID in a recent logon event like 4624, which links the change back to a specific sign-on session and, often, a source host. That correlation is how you turn who into how they got there.
Example
Subject Account Name 'dadmin' with Logon ID 0x30dc2, matched to a 4624 logon from a specific workstation.
Why it matters — Attribution starts here. Without a trustworthy Subject, a change is just an anonymous edit.
The Target Account: which account changed
The Target Account block identifies the user account that was modified.
The Target Account section names the account that was changed: its Security ID, Account Name, and Account Domain. For a domain account the domain appears as a NETBIOS or full DNS name; for a local account, this field holds the computer name instead.
This is the field most detections key on. Monitoring 4738 for a Target Account that matches a domain admin, a break-glass account, or a service account lets you flag changes to your most sensitive identities while ignoring routine edits elsewhere.
Example
Target Account Name 'ksmith' in domain CONTOSO, flagged because it's on the critical-accounts watchlist.
Why it matters — The value of a change alert depends on whose account changed. Critical accounts deserve tight monitoring.
Changed Attributes and their values
Changed Attributes lists the modified properties, showing new values, with "-" for unchanged ones.
The Changed Attributes section covers properties like SAM Account Name, Display Name, User Principal Name, home directory and drive, script and profile paths, User Workstations, Password Last Set, Account Expires, Primary Group ID, AllowedToDelegateTo, SID History, and Logon Hours. A changed field shows its new value; an unchanged field shows "-".
Local accounts behave differently. Microsoft notes that for local accounts most fields show current values rather than only changes, so it's harder to tell what actually changed. In general, 4738 shows the new state, not a before-and-after diff, which is a key limit to remember.
Example
A populated 'AllowedToDelegateTo' field signals the account's Kerberos delegation list was changed.
Why it matters — Reading these values correctly is the difference between spotting a real change and chasing noise.
UAC flags: the security-critical part
The UAC fields show account-control flag changes that often carry the most security weight.
Three fields cover account-control flags. Old UAC Value and New UAC Value are the SAM account-control flags in hex, before and after. The User Account Control field then lists the changes in readable text, one line per change, such as "'Password Not Required' - Enabled."
These flags matter because they control password, delegation, and authentication behavior. Microsoft recommends watching for risky changes like enabling Password Not Required, Don't Expire Password, or Trusted For Delegation, and for Don't Require Preauth, which weakens Kerberos. A benign-looking account edit can quietly lower an account's security here.
Example
New UAC Value 0x211 with User Account Control text showing 'Password Not Required' - Enabled.
Why it matters — UAC flag changes are a common, quiet path to privilege abuse. This is where alerting pays off most.
Where it's logged and how it's collected
4738 is written to the Security log and usually forwarded to a SIEM for monitoring.
The event lands in the Windows Security log on the authoritative machine. On its own it just sits there, so teams collect it centrally, often through Windows Event Forwarding or an agent, and send it to a SIEM or a service like Microsoft Sentinel.
Central collection is what makes 4738 actionable. It lets you correlate a change on a domain controller with logons and other events, apply detection rules, and keep an audit trail for the retention period compliance requires. Event volume is low, which keeps this practical even at scale.
Example
A domain controller forwards 4738 events to Microsoft Sentinel, where a rule flags changes to admin accounts.
Why it matters — A log nobody reads catches nothing. Collection and correlation turn 4738 into detection.
How it works
Auditing is enabled
An admin turns on the Audit User Account Management subcategory, under Account Management in the advanced audit policy. Microsoft's baselines recommend auditing both Success and Failure. Without this, no 4738 is written.
Audit on
Example — Group Policy sets Account Management > Audit User Account Management to Success and Failure.
Someone changes a user account
A user account is modified through a tool or script: Active Directory Users and Computers, PowerShell, an API, or the local user manager. The change can be an attribute edit, a UAC flag, delegation, or group and profile settings.
Change
Example — An admin enables 'Password never expires' on a service account in ADUC.
Windows writes a 4738 event
The Security-Auditing provider records a 4738 in the Security log on the authoritative machine: a domain controller for domain accounts, the local computer for local accounts. Each change produces its own event.
Log 4738
Example — A domain controller logs event 4738 the moment the account is saved.
The event captures who, what, and which account
The event fills in Subject (who), Target Account (which account), and Changed Attributes (what changed, with new values). If the change hit an unlisted attribute, the attributes may all read "-".
Populate
Example — Subject 'dadmin', Target 'svc-backup', and a New UAC Value reflecting the flag change.
The event is collected centrally
Windows Event Forwarding or an agent ships the 4738 to a central store or SIEM, such as Microsoft Sentinel. Central collection lets you correlate it with logons and other events across the environment.
Collect
Example — The 4738 is forwarded to Sentinel and joined to the matching 4624 logon by Logon ID.
Detections and analysts evaluate the change
Rules and analysts judge whether the change is expected. Was it a critical account? A risky UAC flag? A delegation change? If it looks wrong, it becomes an incident; if routine, it stays an audit record.
Detect
Example — A rule fires when 'Password Not Required' is enabled on any account and raises an alert.
Use cases
Detecting risky security-flag changes
SOC, security analystsAlert when a change enables a dangerous UAC flag on an account.
Password Not Required or Don't Require Preauth is enabled on a user account, and the 4738 UAC field triggers a high-severity alert.
Benefit — Catches quiet privilege and authentication weakening that has no separate event.
Monitoring changes to critical accounts
Security, IT adminsWatch 4738 for a Target Account that matches a domain admin, break-glass, or service account.
Any 4738 where the Target Account is on the tier-0 admin watchlist raises an alert.
Benefit — Focuses attention on the identities that matter most, cutting noise.
Spotting delegation changes
Security, AD adminsFlag changes to an account's Kerberos delegation via the AllowedToDelegateTo field.
AllowedToDelegateTo becomes populated on a service account that shouldn't have delegation.
Benefit — Delegation changes can enable lateral movement, so they deserve review.
Compliance audit trail
Compliance officers, businessKeep a record of account modifications to satisfy CIS, STIG, and other audit requirements.
Retained 4738 events answer an auditor's request for who changed which accounts last quarter.
Benefit — Provides evidence that account changes are tracked and reviewable.
Incident investigation and forensics
Incident responders, DFIRReconstruct account tampering during an incident by reading 4738 and correlating by Logon ID.
Matching a 4738 Subject Logon ID to a 4624 logon reveals the workstation used to make the change.
Benefit — Ties an account change back to a specific session and, often, a source host.
Benefits
Native, no extra agent
4738 is built into Windows auditing, so you get it by enabling a policy, not by deploying software.
Turning on Audit User Account Management starts the events flowing.
Clear attribution
The Subject block plus the Logon ID lets you trace a change to an account and a session.
Correlating Logon ID with a 4624 logon shows who changed the account and from where.
Visibility into risky flag changes
The UAC fields surface security-flag changes that often have no dedicated event of their own.
Enabling Password Not Required shows up in the User Account Control field.
Broad coverage
It records for both domain and local accounts, across domain controllers, servers, and workstations.
A local Administrator change on a workstation logs a 4738 on that machine.
Compliance support
It gives an audit trail of account changes that maps to CIS and STIG monitoring requirements.
4738 collection helps meet CIS control 17.2.6 for auditing user account management.
Limitations
Shows new values, rarely old ones
MediumFor most attributes, 4738 shows only the new value, not the previous one. Except for the Old and New UAC fields, you can't see the before state from the event alone.
Workaround — For full before-and-after values on AD objects, use Directory Service Changes auditing (event 5136).
Empty change events
MediumYou can get a 4738 with every Changed Attribute set to "-". Microsoft says this happens when an unlisted attribute, like the DACL, changes, and there's no way to tell which.
Workaround — Correlate with directory-change auditing or other events; don't blanket-ignore these.
Local accounts read differently
MediumFor local accounts, most fields show current values rather than only what changed, and the UAC field is filled only when it changed, making the real change harder to pin down.
Workaround — Baseline normal local-account values and focus on the UAC field and known-sensitive attributes.
Not every change fires a 4738
MediumMicrosoft notes some changes don't invoke a 4738 at all, so a missing event isn't proof nothing changed.
Workaround — Combine 4738 with directory-change auditing and other account events for fuller coverage.
It's a log, not an alarm
LowOn its own, 4738 just sits in the Security log. It doesn't alert, block, or prevent anything, and it needs collection and detection rules to be useful.
Workaround — Forward events to a SIEM and write rules for risky changes and critical accounts.
Architecture
A 4738 event is a structured record, not a system. Its architecture is the layout of the event itself: a System header with metadata, then EventData holding the Subject, Target Account, Changed Attributes, UAC fields, and any privileges used. Understanding that layout is how you read the event quickly and build reliable detections.
System header
Metadata about the event: provider, Event ID 4738, the computer, and the time it was created.
Provider Microsoft-Windows-Security-Auditing, EventID 4738, Computer DC01, Channel Security.
Subject
Identifies who made the change: Security ID, Account Name, Account Domain, and Logon ID.
Subject Account Name 'dadmin', Logon ID 0x30dc2.
Target Account
Identifies the account that was changed: Security ID, Account Name, and Account Domain.
Target Account Name 'ksmith', Domain CONTOSO.
Changed Attributes
Lists modified properties with their new values; unchanged fields show "-".
AllowedToDelegateTo populated; all other attributes '-'.
UAC fields
Old UAC Value and New UAC Value (hex SAM flags) plus a readable User Account Control change list.
OldUacValue 0x15, NewUacValue 0x211, User Account Control 'Password Not Required' - Enabled.
Additional Information
The Privileges field lists any user privileges used during the operation, or "-".
PrivilegeList: SeBackupPrivilege, or '-' when none were captured.
Data flow
The flow is short. A change to a user account is processed by the SAM or Active Directory. The Security-Auditing provider writes a 4738 into the local Security log, filling in Subject, Target, and Changed Attributes. From there, forwarding or an agent moves the event to a SIEM, where correlation and detection rules act on it. The event itself takes no action; everything downstream is monitoring you add.
Integrations: SIEM platforms and Microsoft Sentinel, Windows Event Forwarding (WEF) and collectors, Microsoft Defender for Identity, Group Policy and Advanced Audit Policy Configuration, Active Directory and the SAM database
Architecture limitations
Examples
An account is quietly weakened (UAC change)
An attacker with admin rights enables 'Password Not Required' on a user account to ease reuse.
The 4738 shows an Old UAC Value and a New UAC Value, and the User Account Control field lists 'Password Not Required' - Enabled. Most other Changed Attributes read "-". This is a security-relevant change with no separate event, so the UAC field is the tell.
A service account gains delegation rights
Someone adds SPNs to a service account's Delegation tab, changing where it can present credentials.
The event's AllowedToDelegateTo field becomes populated with the new services list. Microsoft notes you see the full new list, not just the delta. Because delegation can enable lateral movement, this change deserves review even when it looks routine.
A routine attribute edit and an empty event
An admin updates a user's profile path, and separately a change hits the account's DACL.
The profile-path edit shows the new value in the Profile Path field. The DACL change produces a second 4738 where every Changed Attribute is "-", because the DACL isn't a listed attribute. Both are normal, but the empty one can't tell you what changed.
Comparisons
4738 vs 4720 and 4726 vs 4720 (created) and 4726 (deleted)
4738 covers changes to an existing account. 4720 marks creation and 4726 marks deletion. All three live in the same Audit User Account Management subcategory and together track an account's lifecycle.
| Criterion | 4738 vs 4720 and 4726 | 4720 (created) and 4726 (deleted) |
|---|---|---|
| Trigger | An existing account is modified | An account is created (4720) or deleted (4726) |
| Use | Detect tampering and risky edits | Detect account creation or removal |
| Subcategory | Audit User Account Management | Audit User Account Management |
When to choose — Monitor all three together to see the full create, change, and delete story for accounts.
4738 vs 4781 vs 4781 (name changed)
A general attribute change fires 4738. Renaming an account fires the dedicated event 4781, "The name of an account was changed." If you're tracking renames specifically, 4781 is the precise signal.
| Criterion | 4738 vs 4781 | 4781 (name changed) |
|---|---|---|
| Trigger | Any listed attribute change | The account name (SAM name) is changed |
| Precision | Broad, many attributes | Specific to renames |
When to choose — Use 4781 to catch renames cleanly; use 4738 for the wider set of attribute changes.
4738 vs 5136 vs 5136 (Directory Service Changes)
4738 reports a user-account change with mostly new values. Event 5136, under DS Access auditing, logs Active Directory object changes with both old and new attribute values. For full before-and-after detail on AD attributes, 5136 is stronger, but it needs directory auditing and object SACLs configured.
| Criterion | 4738 vs 5136 | 5136 (Directory Service Changes) |
|---|---|---|
| Values shown | New values, rarely old | Both old and new values |
| Scope | User account changes (SAM level) | AD object attribute changes |
| Setup | Enable one audit subcategory | Enable DS Changes auditing and object SACLs |
When to choose — Pair them: 4738 for a quick account-change signal, 5136 when you need exact old and new values.
Myths, corrected
Myth
4738 tells you exactly what changed.
Correction
Often it doesn't. It mainly shows new values, not old ones, and it can appear with every attribute set to "-" when an unlisted attribute changes. It's a signal that something changed, not always a full diff.
Why it happens: People expect a change event to be a complete before-and-after record, which it isn't.
Myth
A 4738 means the password was changed.
Correction
Password changes and resets have their own events, 4723 and 4724. A 4738 might show an updated Password Last Set value, but the dedicated password events are the ones to watch for that.
Why it happens: The Password Last Set field appears in 4738, so it's easy to conflate with a password change.
Myth
An empty 4738 with all dashes is noise to ignore.
Correction
It's a real change to an attribute the event doesn't list, such as the DACL. You can't tell what changed from the event, but that doesn't make it meaningless, especially on sensitive accounts.
Why it happens: An event with no visible changes looks like a glitch, so teams filter it out.
Myth
Turning on auditing catches every account change.
Correction
Some changes don't fire a 4738 at all, local accounts report differently, and the event only helps once it's collected and monitored. Auditing is necessary, but it isn't a guarantee of complete coverage.
Why it happens: Enabling a single policy feels like flipping on total visibility, which oversells it.
Practical implications
For admins
Enable Audit User Account Management under Account Management in the advanced audit policy, and follow Microsoft's baselines by auditing Success and Failure. Volume is low, so this is safe to turn on broadly. Learn the local-account quirk so you read those events correctly.
For MSPs
Standardize the audit policy across client environments and ship a common set of detections. Watching 4738 for risky UAC flags and critical-account changes is a strong, low-noise managed detection you can offer.
For business
4738 supports compliance and risk reduction. CIS and STIG benchmarks expect user account management auditing, so it often exists to meet an audit control as well as to catch attacks. The cost is mostly in collection and review, not the event itself.
For security
Treat the UAC fields, delegation, Primary Group ID, and SID History as the high-value signals. Alert on risky flag changes and changes to tier-0 accounts, and correlate the Subject Logon ID with logon events to find the source of a change.
For end users
Invisible. End users never see 4738; it's an administrative and security record only.
Cost impact
The event is native and low volume, so the cost is SIEM ingestion, storage for the retention period, and the time to tune rules and review alerts, not licensing for the event itself.
Operational impact
To get value, you must enable the policy, collect the events centrally, and write detections. Left in the local log, 4738 catches nothing; the operational work is in collection and tuning.
Decision guide
Use when
- You need to detect changes to critical accounts like domain admins and service accounts
- You want to catch risky security-flag changes that have no separate event
- You must keep an audit trail of account modifications for compliance
- You're investigating an incident and need to see who changed an account
Avoid when
- You need the previous value of most attributes, not just the new one
- You require a guarantee that every possible change is captured
- You're specifically tracking password changes or resets (use 4723 and 4724)
- You expect the event to alert on its own without a SIEM or rules
Requirements
- Audit User Account Management enabled (Success and Failure recommended)
- Central log collection, such as Windows Event Forwarding or an agent
- A SIEM or monitoring tool with detection rules
- A baseline of normal account changes to reduce noise
Alternatives
- Directory Service Changes auditing (event 5136) for old-and-new attribute values
- Microsoft Defender for Identity for AD-focused detection
- Third-party Active Directory auditing tools for richer change reporting
Related terms
Audit User Account Management
The audit subcategory, under Account Management, that generates 4738 and related account events.
userAccountControl (UAC)
The account-control flags that govern password, delegation, and authentication behavior; changes appear in the 4738 UAC fields.
Security Identifier (SID)
A unique, unchangeable value that identifies an account or group; used in the Subject and Target sections.
Logon ID
A hex value that links a change to a specific logon session, letting you correlate 4738 with events like 4624.
Advanced Audit Policy Configuration
The Windows policy area where you enable granular audit subcategories such as User Account Management.
Directory Service Changes (5136)
A DS Access audit event that logs old and new values for Active Directory object attribute changes.
Frequently asked questions
What is Event ID 4738?
Event ID 4738, "A user account was changed," is a Windows Security audit event logged whenever a user account object is modified. It records who made the change, which account was changed, and which attributes changed.
Where is Event ID 4738 logged?
In the Windows Security event log, on the machine authoritative for the account. That's a domain controller for domain accounts and the local computer for local accounts, so it appears on servers and workstations too.
What does a 4738 with all dashes ("-") mean?
It means an attribute changed that the event doesn't list, such as the account's DACL. Microsoft notes there's no way to tell which attribute changed in that case, so treat it as a real but undetailed change, not an error.
How do I enable Event ID 4738 logging?
Enable the Audit User Account Management subcategory, under Account Management, in the Advanced Audit Policy Configuration. Microsoft's baselines recommend auditing both Success and Failure.
Does 4738 show the old value of an attribute?
Usually not. For most attributes it shows only the new value. The exception is the UAC flags, where both Old UAC Value and New UAC Value appear. For full old-and-new detail on AD attributes, use Directory Service Changes auditing (event 5136).
Is a 4738 event a sign of an attack?
Not by itself. Most 4738 events are routine admin changes. It becomes worth investigating when it touches a critical account or enables a risky flag, like Password Not Required or a delegation change.
What's the difference between 4738 and 4781?
4738 covers general attribute changes to an account. 4781, "The name of an account was changed," is the dedicated event for renames. Use 4781 to track renames precisely.
What is the legacy event ID for 4738?
On pre-Vista Windows, the equivalent event ID was 642. Microsoft classes the change event as low criticality on its own, though specific changes can matter a lot.
Conclusion
Event ID 4738 fires whenever a user account object is changed, and Windows logs one event per change in the Security log. It records the Subject who made the change, the Target account that changed, and the Changed Attributes, showing new values. The UAC fields, delegation, Primary Group ID, and SID History carry the most security weight.
Its limits are real. It shows new values more than old ones, can appear empty when an unlisted attribute changes, and reads differently for local accounts. Treat it as a strong signal, pair it with directory-change auditing when you need full detail, and collect it into a SIEM so it can actually drive detection.
Main takeaway
If you want exact before-and-after values, look at Directory Service Changes auditing (event 5136) next. To act on 4738 automatically, a tutorial on writing SIEM detection rules for account changes is the logical follow-up.
