Windows 11 / Windows Server Local Account Password Reset via WinRE (utilman Method)

Procedure for resetting a forgotten local account password on Windows 11 and Windows Server using the Windows Recovery Environment (WinRE). Works by temporarily replacing the accessibility binary (utilman.exe) with cmd.exe to obtain a SYSTEM-level command prompt at the login screen. Verified on a personal Windows 11 device where the OS volume mounted as E: under WinRE; the same technique applies to Windows Server (Desktop Experience) editions with the deltas noted below.

Table of Contents

1. Overview
2. Applicability and Limitations
3. Windows Server Applicability
4. Prerequisites
5. Procedure
   1. Step 1: Boot into WinRE
   2. Step 2: Identify the Windows Volume
   3. Step 3: Verify BitLocker Status
   4. Step 4: Swap utilman.exe with cmd.exe
   5. Step 5: Reset the Password
   6. Step 6: Restore utilman.exe
6. Critical Notes
7. Troubleshooting
8. Command Reference
9. References

Overview

The utilman.exe swap is a physical-access recovery technique. At the Windows login screen, the Accessibility (Ease of Access) button launches utilman.exe with SYSTEM privileges. Replacing that binary with cmd.exe yields an elevated command prompt before authentication, from which net user can reset any local account password.

The technique requires the ability to boot the machine into WinRE (physical or console access) and an unencrypted system volume, or the BitLocker recovery key if the volume is encrypted. It applies only to hardware you own or are authorised to administer; use on a machine without authorisation is unauthorised access.

Applicability and Limitations

On Windows 11, Device Encryption (a BitLocker variant) is enabled automatically on compatible hardware, so treat the volume as encrypted until confirmed otherwise. Modifying files on an encrypted volume triggers the recovery-key prompt on next boot. (Windows OS Hub; Pureinfotech — see References.)

Windows Server Applicability

The same utilman.exe swap works on Windows Server (Desktop Experience) editions — 2012 R2, 2016, 2019, 2022, and 2025 — using the identical Procedure below. The differences are operational, not mechanical. (Clouvider; PhoenixNAP; ServerAdminz — see References.)

Server-specific swap (drive letter substituted; E: shown), run in the recovery Command Prompt:

move E:\Windows\System32\utilman.exe E:\utilman.bak
copy E:\Windows\System32\cmd.exe E:\Windows\System32\utilman.exe

After reboot, at the login screen, press Ctrl+Alt+Del then Win+U for the SYSTEM prompt, then:

net user administrator /active:yes
net user administrator NewP@ssw0rd!

Restore utilman.exe afterward exactly as in Step 6.

Exceptions

• Domain Controllers. A DC has no local SAM — the local account database is removed during promotion (dcpromo), so net user for a local account resets nothing. Domain accounts are reset through Active Directory by an authorised administrator using Set-ADAccountPassword or Active Directory Users and Computers from another domain-joined admin session. Console and physical access to a DC is itself a critical security boundary and should be controlled accordingly. (Diengdoh — see References.)
• Server Core. The minimal logon UI has no Ease of Access button, so the utilman.exe swap has nothing to click. Use the Sticky Keys variant instead: swap sethc.exe (triggered by pressing Shift five times at the logon screen) rather than utilman.exe, with the same backup and restore discipline. (Inferred: Server Core retains Winlogon/LogonUI but omits the Explorer shell and accessibility button; the Sticky Keys trigger is a Winlogon-level feature and therefore still fires.)

Operational Note

On a server, treat this as emergency access only. Record the action in change control and audit logs, and after regaining access review account lockout policy, local/domain security policy, and the Security event log for anything unexpected. (ServerAdminz — see References.)

Prerequisites

• Physical or console access to the device (for headless servers: IPMI / remote KVM with ISO mount capability)
• Ability to reach WinRE (Shift+Restart, forced boot interruption, or Windows install media)
• The exact local account name (retrieved via net user during the process)
• BitLocker recovery key on hand if the volume is encrypted — retrieve from https://account.microsoft.com/devices/recoverykey

Procedure

Step 1: Boot into WinRE

From a reachable login screen:

Hold Shift > Power > Restart

If the desktop is inaccessible, force WinRE by interrupting boot three times (hard power-off during the boot spinner). Alternatively — and the standard path on Server — boot Windows install media and press Shift + F10 at the setup screen for a command prompt.

Then navigate:

Troubleshoot > Advanced options > Command Prompt

Step 2: Identify the Windows Volume

In WinRE, X: is the RAM disk. The Windows volume is frequently not C: — in the verified case it was E:. Enumerate volumes:

diskpart
list volume
exit

The Windows volume is the large NTFS partition (typically 100+ GB). Ignore:

Confirm the correct letter by checking for the Windows folder (substitute the letter found — E: shown here):

dir E:\Windows\System32\utilman.exe

If the file lists, the volume is correct. If “File Not Found”, try the next letter until it resolves.

Step 3: Verify BitLocker Status

This is the go/no-go gate before writing to System32:

manage-bde -status E:

Read Conversion Status and Protection Status:

• Fully Decrypted / Protection Off — safe to proceed to Step 4.
• Fully Encrypted / Protection On — unlock or suspend first.

Unlock with the recovery key:

manage-bde -unlock E: -RecoveryPassword <48-digit-key>
``` powershell

Or suspend protection to avoid the reboot prompt:

```  powershell
manage-bde -protectors -disable E:

Step 4: Swap utilman.exe with cmd.exe

Back up the original to the root of the fixed OS volume (not the USB, so it survives reboot), then overwrite:

copy E:\Windows\System32\utilman.exe E:\utilman.bak
copy E:\Windows\System32\cmd.exe E:\Windows\System32\utilman.exe

When prompted Overwrite ...utilman.exe?, respond:

Yes

The overwrite is expected — utilman.exe already exists and the original is preserved at E:\utilman.bak. Reboot into normal Windows:

wpeutil reboot

Step 5: Reset the Password

At the Windows login screen, click the Accessibility / Ease of Access button (bottom-right), or on a server press Ctrl+Alt+Del then Win+U. A SYSTEM-level command prompt opens instead of Utility Manager.

List local accounts to confirm the exact name:

net user

Reset the target account:

net user "YourAccount" NewP@ssw0rd!

If the account is disabled:

net user "YourAccount" /active:yes

Log in with the new password.

Step 6: Restore utilman.exe

Once booted into normal Windows, the OS volume reverts to its standard letter — C: — so the backup made at E:\utilman.bak is now at C:\utilman.bak. Open an elevated Command Prompt (Run as administrator) and restore:

copy C:\utilman.bak C:\Windows\System32\utilman.exe
del C:\utilman.bak

When prompted to overwrite, respond Yes. This closes the SYSTEM-level access left by the swapped binary. Do not skip this step.

If BitLocker protection was suspended in Step 3, re-enable it:

manage-bde -protectors -enable C:

Critical Notes

• Volume letter changes between environments. WinRE mounted the OS volume as E:; normal Windows mounts the same volume as C:. Back up and reference files using the letter valid in the current environment. This was the primary point of confusion during the verified run.
• Restore is mandatory. A swapped utilman.exe (or sethc.exe) is a persistent SYSTEM-level command prompt reachable from the lock screen by anyone with physical access. Restoring the original binary closes it.
• Data loss on reset. Resetting a local password invalidates that user’s EFS-encrypted files, Credential Manager entries, and DPAPI-protected secrets (browser-saved passwords, etc.). This is the most likely follow-on issue and is not recoverable. (Inferred from Windows credential architecture; consistent with Microsoft password-reset guidance.)
• Microsoft accounts and domain accounts are out of scope. net user only affects local accounts. An MSA must be reset online; a domain account must be reset through Active Directory.
• Physical access is the real control. This technique exists because console access to a machine is equivalent to control of its local accounts. For servers — and especially Domain Controllers — physical and out-of-band (IPMI/KVM) access is the security boundary that matters.

Troubleshooting

Command Reference