{"id":14367,"date":"2026-07-21T11:43:42","date_gmt":"2026-07-21T09:43:42","guid":{"rendered":"https:\/\/irg-net.com\/?p=14367"},"modified":"2026-07-21T11:46:31","modified_gmt":"2026-07-21T09:46:31","slug":"tpm-encryption-recovery-key-backup-alarm","status":"publish","type":"post","link":"https:\/\/irg-net.com\/index.php\/tpm-encryption-recovery-key-backup-alarm\/","title":{"rendered":"TPM Encryption Recovery Key Backup Alarm"},"content":{"rendered":"
\n
\"\"<\/figure>\n<\/div>\n\n\n
<\/div>\n\n\n\n

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:<\/p>\n\n\n\n

“TPM Encryption Recovery Key Backup”<\/strong><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\"\"<\/figure>\n\n\n\n
<\/div>\n\n\n\n

Root Cause<\/h3>\n\n\n\n

Starting with vSphere 7.0 Update 2, ESX hosts equipped with an active TPM 2.0 chip<\/strong> automatically encrypt their host configuration using the physical TPM. This mechanism protects security-relevant host configuration data \u2014 such as encryption keys and Secure Boot state \u2014 from unauthorised access, even in scenarios where a host is physically removed or its storage media is read directly.<\/p>\n\n\n\n

When such a host is added to vCenter Server, vCenter checks whether the TPM Encryption Recovery Key<\/strong> 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<\/strong> \u2014 specifically the backup of the recovery key.<\/p>\n\n\n\n

The vim.fault.TpmTrustNotEstablished<\/code> 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.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Procedure to fix the issue<\/h3>\n\n\n\n

The alarm was resolved on each affected host in accordance with Broadcom Knowledge Base Article 323401<\/strong>, following three steps:<\/p>\n\n\n\n

<\/div>\n\n\n\n

Step 1 \u2014 Verify the encryption mode.<\/strong>
SSH access was used on each ESX host to query the active encryption mode:<\/p>\n\n\n\n

<\/circle><\/circle><\/circle><\/g><\/svg><\/span>