A configuration backup alone does not establish that an ESXi host can recover its encrypted configuration after a TPM or motherboard change. First identify the host's configuration-encryption mode and confirm that the matching recovery material has an authorised custodian. Do not substitute a VM key-provider backup or a Windows recovery password for the host's own requirement. A12-S1, A12-S2
This is an inspection-only assessment for ESXi 8.0, using Broadcom's guidance for host configuration encryption introduced in the 7.0 Update 2 era. No hardware maintenance, recovery boot or key retrieval was performed.
Identify what is encrypted
The protected object here is the ESXi host configuration. The TPM can participate in protecting the material needed to use that configuration. Replacing relevant hardware can break the existing relationship and require the documented recovery path.
A host configuration backup preserves configuration content, but recovery also depends on being able to decrypt the protected state. Broadcom's hardware-change article explicitly warns about this dependency. Treat “backup file exists” and “required recovery material is available” as separate evidence. A12-S1
This is different from adding a virtual TPM to a guest VM. A VM's vTPM state and its key-provider dependency belong to that VM's protection design. Guest BitLocker introduces another recovery layer. All three can exist in the same environment, but their recovery material is not interchangeable.
KB 316424 explicitly names motherboard, CMOS battery, CPU and RAM replacement as hardware-change triggers. Its boot failure message is “Unable to restore the system configuration. A security violation was detected.” For the documented TPM recovery case, the KB says that a configuration backup without the encryption recovery key is insufficient: the host cannot be recovered that way and a complete rebuild is required. This is a recovery-planning consequence, not an instruction to rebuild.
Read the host's current mode
Prerequisites are the exact ESXi build, the host's identity, the planned hardware scope and already authorised read access or a current configuration capture. Do not enable services or change access to obtain this check.
Broadcom documents this read-only command:
esxcli system settings encryption get
It reads configuration-encryption settings. The documented modes include NONE and TPM. Record the actual result for the host being maintained; do not infer the mode from the presence of a physical TPM alone. A12-S2
The command was not executed for this article. An output captured for another host, or before a later configuration change, does not establish the current target's state. Keep host identity and capture date with the mode observation.
Reading mode does not require copying a recovery key into the report. The diagnostic record should state whether custody has been confirmed through the approved secret-handling process, not contain the secret itself.
Both cited KBs name esxcli system settings encryption recovery list as the command that displays the recovery material. Unlike the mode query, its output is a secret. It is named here to identify what the authorised custodian must protect, not as a collection step for this article: use the approved secret store, never tickets, shared reports or these manuscript files. No key was read or stored for this work. The sources cover broader releases, but this article intentionally limits its maintenance assessment to ESXi 8.0; it does not validate recovery steps on 7.x or 9.x.
Build a recovery dependency record
For a TPM-mode host, ask the responsible custodian to establish that the recovery material belongs to this host and remains retrievable independently of the hardware under maintenance. Record the approved vault reference or custody acknowledgement in the restricted change record.
Keep four facts distinct: the configuration backup exists, its host/version association is known, recovery material is held by the authorised custodian, and the supported hardware-change recovery procedure has been reviewed. None of these alone proves a successful recovery.
If the only known backup is an appliance or VM backup, establish whether it actually covers the ESXi host configuration. A file labelled “VMware backup” is too ambiguous for this decision.
Worked maintenance decision
Consider an invented host H1 scheduled for motherboard replacement:
| Evidence | State |
|---|---|
| Existing configuration capture | Associated with H1 |
| Encryption mode | TPM |
| Host recovery material | Custodian cannot confirm it |
| VM key-provider backup | Available |
The maintenance readiness result is held. The available VM key-provider backup does not close the missing host recovery dependency. This is a specific recoverability gap, not a claim that the running host has already lost data.
If H2 reports NONE, KB 323401 says the warning could be a false positive. Do not automatically apply the TPM recovery scenario to it. Record that mode and assess its actual configuration-recovery requirements. Do not change H2's mode as part of this inspection or claim it has equivalent protection to H1.
Troubleshooting the warning
A host recovery-key warning is a prompt to establish the documented custody requirement. Clearing or acknowledging an alarm does not create a usable recovery record. Likewise, the absence of a warning is not evidence that the person performing maintenance can retrieve the necessary material.
Broadcom's recovery article contains operations that modify boot or encryption state. They are intentionally excluded here. Do not clear a TPM, replace it, change encryption mode or attempt a recovery boot merely to test whether the current backup is sufficient.
Acceptance and safe limits
The inspection is complete when the target's mode, build, configuration-backup association and custody status are recorded without exposing secrets. A missing item remains an explicit maintenance hold for the hardware-change owner.
A future qualified recovery rehearsal would need its own isolated design and acceptance criteria. This source-only assessment cannot certify that a motherboard replacement will succeed. Hardware rollback is also not equivalent to restoring a file; vendor-specific dependencies must be handled in the approved maintenance plan.
Read-only inspection needs no rollback. The practical lesson is to identify the encrypted object first: host configuration, VM vTPM state and guest disk protection each have their own recovery dependency.
References
- A12-S1: TPM Enabled ESXi Host Preparation for Hardware Changes
- A12-S2: "TPM Encryption Recovery Key Backup" warning alarm present in host summary page