You inherited an environment. The guy who built it left three years ago. Nobody knows the root password on at least one ESXi host, and the documentation is a Word file last saved in 2019. This is the most common reason people search for ESXi password recovery, and the answer depends entirely on which version of ESXi you're running and whether the host is still managed by vCenter.

The short version: there are three methods that actually work on modern ESXi (7.x, 8.x, 9.x), and one old trick that stopped working in ESXi 7.0 Update 2. If your host is managed by vCenter, the PowerCLI method is the easiest path. If it's not, and you don't have the right license tier, you may be looking at a reinstall.

Why the old live CD method is dead

If you search for ESXi password reset, half the results describe booting a Linux live USB, mounting the ESXi boot banks, extracting state.tgz, unpacking it to find the shadow file, and replacing the root password hash with one generated by openssl passwd -6. This worked on ESXi 6.x and early 7.0 builds. It does not work on ESXi 7.0 U2 or later, including all of ESXi 8.x and 9.x.

Broadcom encrypted the local user account data in the state bundle starting with ESXi 7.0 Update 2 (released March 2021). The shadow file inside state.tgz is no longer plaintext. You can still unpack the archive, but the contents you need to edit are not human-readable, and there is no documented way to re-encrypt a modified copy. Broadcom's own KB articles do not list this as a supported recovery method for current versions.

I mention this up front because if you're following a blog post from 2019 and it's not working, that's why. Stop spending time on it.

Method 1: PowerCLI through vCenter (no special license required)

This is the method Broadcom documents in KB 376979, and it works for ESXi 7.x, 8.x, and 9.x hosts managed by vCenter Server. The requirement is that the host shows as Connected in vCenter. If the host is Disconnected or Not Responding, this method will not work because vCenter can't reach the host's agent to execute the change.

If you haven't set up PowerCLI before, the complete PowerCLI installation guide walks through getting version 13.x installed and connected to vCenter. Once you're connected, the process is about ten lines of PowerShell.

# Connect to vCenter
Connect-VIServer -Server vcenter.yourdomain.local -User administrator@vsphere.local

# Create a credential object with the new password
$creds = Get-Credential -UserName "root" -Message "Enter root as username and the new password"

# Get a reference to the target host
$esxiserver = Get-VMHost -Name esxi-host-01.yourdomain.local

# Get the ESXCLI V2 object
$esxcli = Get-EsxCli -VMHost $esxiserver -V2

# Build the argument to set the account
$userarg = $esxcli.system.account.set.CreateArgs()
$userarg.id = $creds.UserName
$userarg.password = $creds.GetNetworkCredential().Password
$userarg.passwordconfirmation = $creds.GetNetworkCredential().Password

# Execute the password change
$esxcli.system.account.set.invoke($userarg)

The final command returns True on success. No reboot required. No maintenance mode required. The VMs keep running.

There is one catch on ESXi 8.x and later that Broadcom added to the KB after initial publication: this method fails with an "Access to perform the operation was denied. Only users with shell access can make these changes" error if shell access for the vpxuser account is disabled on the host. The fix Broadcom documents is running localcli system account set --id dcui --shell-access true on the host itself, which requires an active root login. If you've lost the root password and shell access for vpxuser is off, you're stuck and need to move to the Host Profile method below.

Password requirements: ESXi enforces a minimum of 7 characters and a maximum of 40. Complexity rules require at least four character classes (uppercase, lowercase, digits, special characters) by default, though this can be relaxed. Generate a password in your password manager that meets the host policy rather than reusing something memorable.

Method 2: vSphere Configuration Profiles (vSphere 8.0 and later)

If you're running vSphere 8.0 or newer, vSphere Configuration Profiles (formerly Host Profiles, now redesigned) offer a JSON-based approach to bulk password management. Broadcom documents this in KB 404104.

The workflow involves exporting your reference host's configuration to JSON, modifying the password hash, and remediating the cluster against the updated profile. This is more involved than the PowerCLI one-liner but handles entire clusters at once, which matters if you're rotating passwords across 40 hosts as part of a security audit.

# Generate a new SHA-512 password hash on any Linux box with openssl
openssl passwd -6
# Prompts for the password twice, outputs a hash like:
# $6$randomsalt$longhashstring...

Take that hash and put it into the exported JSON under authentication.user_accounts[0].password_hash for the root entry. Import the JSON back into vCenter under the cluster's Configuration Draft, run a pre-check, and remediate.

One thing to watch for: if someone changes the root password locally on a host outside of this profile mechanism, vCenter flags the cluster as out of compliance because the password hash no longer matches what the profile expects. This is called configuration drift, and it trips up teams that mix local administration with profile-based management. If you're going to use Configuration Profiles, use them for all password changes or expect to reconcile drift regularly.

Method 3: Host Profiles (vSphere Enterprise Plus or VCF)

Host Profiles are the original Broadcom-supported recovery method, documented in the ESXi root password recovery KB. They require vSphere Enterprise Plus or VMware Cloud Foundation licensing. If you're on vSphere Standard or VVF, you don't have this feature.

The process: create or attach a Host Profile to a reference host whose root password you know, edit the profile to change the password policy, apply it to the target host(s), and remediate. The host needs to be connected to vCenter and in maintenance mode for remediation.

This is functionally similar to Method 2 but uses the older profile engine. Broadcom has been migrating features from Host Profiles to Configuration Profiles across vSphere 8.0 update releases, and Configuration Profiles are the recommended path for new deployments on 8.0+. If you're on 8.0+, prefer Method 2. If you're on 7.x with Enterprise Plus, Host Profiles are your option.

The licensing requirement matters here. If your renewal moved you from Enterprise Plus to VVF, you may have lost Host Profile access, which narrows your recovery options to PowerCLI or reinstall. Check your current license entitlements before assuming Host Profiles are available.

When none of those work: the reinstall

If the host is standalone (no vCenter), the root password is lost, and you have no Host Profile or Configuration Profile access, Broadcom's documented answer is reinstalling ESXi. This sounds worse than it is, but treat it as a last resort and document everything first.

Before reinstalling, capture the current configuration if the host is still partially reachable: management VMkernel IP, subnet, VLAN, uplinks, storage adapter layout, and which disks hold VMFS datastores. Confirm backups exist for all running VMs. If ESXi is installed on the same physical disk or LUN as your VMFS datastores, the installer prompts become high-risk. Read each prompt carefully and never accept a format operation unless you're certain.

An ESXi reinstall preserves VMFS datastores as long as you do not reformat them during installation. The installer detects existing datastores and gives you the option to keep them. After reinstall, you reconfigure networking, rejoin vCenter, and re-register the VMs from the datastore's inventory. VMs that were powered on before will need to be powered on again. Configuration like vSwitches, port groups, NTP, and SSH settings will need to be reapplied.

The practical steps for a reinstall recovery:

1. Boot the ESXi installer from USB (a reliable 32GB USB flash drive works fine)
2. Select the target disk, choose to preserve VMFS when prompted
3. Complete the install, set a new root password
4. Reconfigure the management network (you'll need the VMkernel IP, subnet, and VLAN from your records)
5. Reconnect to vCenter or redeploy vCenter if needed
6. Browse the datastore in the UI, right-click each .vmx file, and register the VMs back into inventory

The reconfiguration is the time-consuming part. If you have Host Profiles or Configuration Profiles already in place for the cluster, reapplying the configuration after reinstall is a few clicks. If you're documenting everything manually, budget an hour per host for network and storage reconfiguration.

What about the DCUI?

The Direct Console User Interface (DCUI) does not have a password reset option. You can press F2 at the console to enter system customization, but every option under it requires the root password. There is no recovery console, no single-user mode bypass, and no boot parameter that resets the password. This is by design: ESXi's security model assumes physical access means full access via reinstall, not a backdoor.

If you have physical or IPMI/iLO access, the DCUI does let you toggle the management network, put the host in maintenance mode, and view logs. None of those help with a forgotten password. The DCUI is useful during a reinstall recovery for verifying the management network configuration before reconnecting to vCenter.

Password policy after reset

Once you've reset the root password, check the password policy on the host. ESXi defaults to requiring four character classes and a minimum of 7 characters, with password history preventing reuse of the last five passwords. You can view the current policy with PowerCLI:

$esxcli = Get-EsxCli -VMHost $esxiserver -V2
$policy = $esxcli.system.account.policy.get.invoke()
$policy

The output shows passwordhistory, passwordminlength, passwordminlowercase, passwordminuppercase, passwordmindigits, passwordminspecial, and passwordmaxlength. If you're rotating passwords as part of an audit, also check that SSH is disabled if you don't need it, and that lockdown mode is enabled if vCenter is managing the host and you want to prevent direct root logins.

Version summary

The single most important detail in that table: if you're on ESXi 7.0 U2 or later, which includes every current production build, the live CD method is not an option. Plan around PowerCLI, Configuration Profiles, Host Profiles, or reinstall.

A note on licensing reality

The password recovery options available to you are tied to what you're licensed for, and licensing has shifted significantly under Broadcom. Host Profiles require Enterprise Plus or VCF. Configuration Profiles require vSphere 8.0. PowerCLI requires vCenter management. If you're a smaller environment on vSphere Standard with standalone hosts, your realistic recovery path is reinstall, which is worth knowing before you lose a password rather than after. The Broadcom licensing breakdown covers what each current bundle includes if you're unsure where your entitlements stand.

Keep your root passwords in a password manager. The recovery methods above all work, but none of them are faster than having the password written down somewhere accessible. A password manager with shared vault access for the infrastructure team prevents the inherited-environment scenario that brings people to this article in the first place.