UCS Updated Oct 18, 2026

ESXi Check Secure Boot Status: secureBoot.py, Enabling Secure Boot (Cisco UCS) and the “Host secure boot was disabled” Alarm

7 min read

Short answer: SSH to the host and run /usr/lib/vmware/secureboot/bin/secureBoot.py -s. It prints Enabled or Disabled. Before you switch Secure Boot on in the firmware, run the same script with -c; it reports either “Secure boot can be enabled” or “Secure boot CANNOT be enabled” and lists the VIBs that block it. On hosts with a TPM, esxcli system settings encryption get also shows whether Secure Boot is enforced.

The esxcli system settings encryption commands used for Secure Boot checks are in the interactive ESXCLI mindmap, where you can compare 7.0, 8.0 and 9.x.

ESXi check Secure Boot status with secureBoot.py

ESXi (and ESX 9) ships with a validation script. It has three modes. This is the help output from one of my hosts:

/usr/lib/vmware/secureboot/bin/secureBoot.py -h
usage: secureBoot.py [-h] [-a | -c | -s]

optional arguments:
  -h, --help            show this help message and exit
  -a, --acceptance-level-check
                        Validate acceptance levels for installed vibs
  -c, --check-capability
                        Check if the host is ready to enable secure boot
  -s, --check-status    Check if UEFI secure boot is enabled
OptionWhat it answersTypical output
-sIs UEFI Secure Boot enabled right now?Enabled / Disabled
-cCan Secure Boot be enabled on this install?Secure boot can be enabled: ... or Secure boot CANNOT be enabled: ...
-aDo the installed VIBs meet the required acceptance levels?Acceptance level validation result

Status on a host that still boots with Secure Boot off:

/usr/lib/vmware/secureboot/bin/secureBoot.py -s
Disabled

Check whether the host is ready for Secure Boot (-c)

Run the capability check before you change anything in the firmware. This matters most on hosts that were upgraded from older releases. Here is a host that passes:

/usr/lib/vmware/secureboot/bin/secureBoot.py -c
Secure boot can be enabled: All vib signatures verified. All tardisks validated. All acceptance levels validated

According to the Broadcom upgrade documentation, the result depends on how the host was upgraded:

  • Every installed VIB needs an acceptance level of at least PartnerSupported. A single CommunitySupported VIB blocks Secure Boot.
  • The signature of every installed VIB must be stored on the system. Older ESXi versions did not save the signatures, and an upgrade done with ESXCLI commands doesn’t save them either. An ISO-based upgrade, including a vSphere Lifecycle Manager upgrade that uses the ISO, does save them.
  • An old third-party driver VIB that the upgrade did not replace stays on the host without a stored signature, so it blocks Secure Boot.
  • The script does not check whether the bootloader is up to date, and Secure Boot needs a current one.

ESXi Secure Boot enable: firmware and Cisco UCS boot policy

ESXi doesn’t turn Secure Boot on by itself. You enable it in the server firmware, and the host must boot in UEFI mode. On most servers you do this in the BIOS/UEFI setup, usually under Boot or Security. Shut the host down gracefully first.

On Cisco UCS Manager-managed servers the setting lives in the boot policy. Set Boot Mode to UEFI and check Boot Security (UEFI Secure Boot), then associate the policy through the service profile. Cisco lists these points in its boot configuration guide:

  • UEFI boot mode must be enabled in the boot policy before you can use UEFI Secure Boot.
  • Cisco UCS Manager and the BIOS firmware must be Release 2.2 or later. User-generated encryption keys are not supported.
  • On UCSM-managed servers, only Cisco UCS Manager can control UEFI Secure Boot.
  • You cannot mix UEFI and legacy boot mode on the same server. Moving an existing legacy-BIOS ESXi install to UEFI is a separate task (see the related post below).
Cisco UCS Manager boot policy with Boot Mode set to UEFI and Boot Security (UEFI Secure Boot) enabled for an ESXi host
Cisco UCS Manager boot policy: UEFI boot mode with Boot Security (UEFI Secure Boot) enabled

After the host reboots with the new policy, check the status again:

/usr/lib/vmware/secureboot/bin/secureBoot.py -s
Enabled

Secure Boot enforcement on hosts with a TPM

On vSphere 7.0 Update 2 and later, a host with an active TPM can enforce Secure Boot on every boot. This setting is separate from the firmware toggle and you manage it with ESXCLI:

esxcli system settings encryption get
   Mode: TPM
   Require Executables Only From Installed VIBs: false
   Require Secure Boot: true

If Mode shows NONE, activate the TPM in the firmware and run esxcli system settings encryption set --mode=TPM. Broadcom warns that you cannot undo this once it is set. To enforce Secure Boot, first enable it in the firmware and restart. Then run the following:

esxcli system settings encryption set --require-secure-boot=T
esxcli system settings encryption get
/bin/backup.sh 0

To turn enforcement off, use --require-secure-boot=F and run /bin/backup.sh 0 again.

“Host secure boot was disabled”: the vCenter alarm

Broadcom KB 369525 documents this condition as the Host TPM attestation alarm in the vSphere Client (vCenter 8.x, ESXi 7.x/8.x). The main cause is that vCenter sees Secure Boot disabled on a host that has a TPM. Secure Boot is a requirement for successful attestation. The alarm can also fire when host and vCenter data get out of sync after a network glitch, a restart or a new host being added. The KB resolution:

  1. Check the current state with secureBoot.py -s.
  2. If it’s disabled, run secureBoot.py -c. If the host is compatible, enable Secure Boot in the firmware and boot ESXi.
  3. If Secure Boot is already enabled and the alarm stays, disconnect and reconnect the host. Then go to Monitor > Issues and Alarms and use Reset to Green on the alarm.
  4. If Secure Boot can’t be enabled on that hardware, the KB says you can use Reset to Green to suppress the alarm.

Fixing “Secure boot CANNOT be enabled” and unsigned VIB failures

  • Find the blocking VIB. The -c output names the VIBs whose signatures it could not verify. Compare them with esxcli software vib list, which includes an AcceptanceLevel column.
  • Replace or remove it. Install the vendor’s current signed driver or add-on, or remove a VIB you no longer need. Then run -c again.
  • Reboot after patching. KB 319600 describes a false failure on esx-base with “Failed to verify checksum for payload btldr”. It appears when you run the check after a live VIB install but before the reboot. Reboot and check again.
  • Purple screen “UEFI Secure Boot failed: Failed to verify signatures of the following vibs”. TechDocs says to reboot with Secure Boot disabled, run the validation script, and check /var/log/esxupdate.log.
  • VIB install fails on a host that already has TPM and Secure Boot. KB 384314 covers the error “Could not find a trusted signer”. The VIB must be signed through the VMware partner program. Disabling Secure Boot is not the recommended fix.
vSphere Secure Boot

Sources

Related on vdan.cz

Daniel Micanek

Senior Service Architect, SAP/TDL Platform Services Team at Vivicta | vExpert ⭐⭐⭐⭐⭐⭐⭐ | Broadcom Knight: vSphere Kubernetes Service, VCF Networking (NSX), VCF Automation | Broadcom Software Knight: vSphere | Cisco Champion. Notes from running about 1,000 ESXi hosts on Cisco UCS, VCF 9 and SAP HANA on vSphere.