TPM Encryption Recovery Key Backup Alarm
Immediately after the successful bring-up of the VCF 9.1 environment, the following warning alarm was triggered on all four ESX hosts within the vCenter Cluster Monitor page:
“TPM Encryption Recovery Key Backup”
This alarm appeared on all hosts simultaneously and was not an indicator of a deployment error, but rather an expected consequence of the hardware and software configuration in use.
Root Cause
Starting with vSphere 7.0 Update 2, ESX hosts equipped with an active TPM 2.0 chip automatically encrypt their host configuration using the physical TPM. This mechanism protects security-relevant host configuration data — such as encryption keys and Secure Boot state — from unauthorised access, even in scenarios where a host is physically removed or its storage media is read directly.
When such a host is added to vCenter Server, vCenter checks whether the TPM Encryption Recovery Key of that host has been backed up. Since this had not yet been performed immediately after bring-up, vCenter triggered the corresponding warning alarm on each host. The alarm therefore does not signal a technical problem but rather a pending administrative action — specifically the backup of the recovery key.
The vim.fault.TpmTrustNotEstablished error observed in the hostd logs of the ESX hosts during the same period is consistent with this and is equally attributable to the not-yet-completed key backup process.
Procedure to fix the issue
The alarm was resolved on each affected host in accordance with Broadcom Knowledge Base Article 323401, following three steps:
Step 1 — Verify the encryption mode.
SSH access was used on each ESX host to query the active encryption mode:
esxcli system settings encryption getThe result confirmed a mode of TPM on all hosts, verifying that host configuration encryption via TPM 2.0 is active and that the alarm does not represent a false positive.
Step 2 — Back up the Recovery Key.
The TPM Encryption Recovery Key was retrieved on each host:
esxcli system settings encryption recovery listThe resulting key should be documented and stored securely in the customers Privileged Access Management (PAM) solution — alongside the other break-glass credentials of the platform (VCSA root, administrator@vsphere.local, Native Key Provider backup or similiar). This key is required in the event that a host is unable to independently decrypt its encrypted configuration following a hardware replacement or Secure Boot related issue.
Step 3 — Reset the alarm.
Following the successful backup, the alarm was manually reset to Green on each host within the vSphere Client:
vSphere Client → Select host → Monitor → Issues and Alarms → Right-click alarm → Reset to Green
And that’s it from this post, if you have any questions please use the comment section below. 🙂