UEFI, Secure Boot, TPM and firmware updates

Two calls reach the help desk on the same morning. Windows 11 Setup refuses an office desktop, and a laptop that took a BIOS update overnight now stops at a screen that asks for a 48-digit recovery key. Neither PC is broken: the desktop starts in an old compatibility mode with its TPM switched off, and the laptop’s new firmware no longer matches what BitLocker measured when it sealed the drive’s key.

UEFIUEFI: Unified Extensible Firmware Interface: the firmware that starts a modern PC before the operating system, replacing the older BIOS. Windows 11 installs in UEFI mode with Secure Boot. is the firmware that starts a PC, Secure BootSecure Boot: A UEFI firmware feature that refuses to start firmware drivers, boot loaders or operating systems that are not signed with keys the firmware trusts. Windows 11 needs Secure Boot capable firmware, in a VM too. More in “Build a practice lab with virtual machines” is its check that only signed start-up software runs, and a TPMTPM: Trusted Platform Module: a chip or firmware component that holds keys and measures the early start-up parts. BitLocker seals the volume key to it and the TPM releases the key only when the measurements match. holds keys that it hands over only when the start-up measurements match. Windows 11 needs UEFI firmware that is Secure Boot capable and a TPM 2.0. By the end you can reach those settings, read them from Windows, explain why Secure Boot’s certificates are being replaced, and update firmware without a recovery prompt.

Four firmware settings decide how a PC starts

Both calls are answered in UEFI setup, the firmware’s own settings screen, so the first job is getting there. Many PCs open it with a key pressed during power-on, and the key depends on the maker: Microsoft’s examples are F1, F2, F12 and Esc. When the key is unknown or the screen goes by too fast, Windows can restart straight into it. Open Settings, System, Recovery and choose Restart now beside Advanced startup; on the menu that follows, choose Troubleshoot, Advanced options, UEFI Firmware Settings. Holding Shift while choosing Restart opens the same menu. A Mac has no setup screen of this kind: on a Mac with Apple silicon or the T2 chip, the start-up security settings are in Startup Security Utility, which opens from macOS Recovery.

Inside UEFI setup, names and menus differ from maker to maker, but four settings matter for support work. The table gives what each one decides and what Windows 11 needs from it:

The TPM setting hides under the most names. Microsoft lists Security Device, Security Device Support, TPM State, Intel PTT (Platform Trust Technology) and AMD fTPM among its labels, usually in an Advanced, Security or Trusted Computing menu.

Change one setting at a time and note the old value, because two of these can stop a PC from starting. A PC installed in Legacy mode sits on an MBR disk, and UEFI starts Windows only from a GPTGPT: GUID Partition Table: the modern scheme for describing a disk's partitions that UEFI firmware expects, replacing the older MBR scheme. A UEFI install of Windows uses a GPT disk. disk, so switching the mode first leaves the PC with nothing to start. Microsoft’s MBR2GPT tool converts the disk in place without deleting data, with BitLocker suspended, and only then is the firmware switched to UEFI. Switching the TPM off, or clearing it, is on Microsoft’s list of changes that send a BitLocker drive into recovery.

These settings act at the very start of the boot chain. Step through one start of a BitLocker PC to see where Secure Boot checks a signature and where the TPM hands over the drive’s key:

The key is released or kept back before Windows itself loads, which is why a firmware change shows up as a recovery screen and not as an error message inside Windows.

Windows reports Secure Boot and the TPM without a restart

Before anyone opens UEFI setup, Windows can say what the firmware is doing. Open PowerShell as administrator and run Confirm-SecureBootUEFI. It gives three readings and one message that is not a reading at all:

• True: the firmware supports Secure Boot and it is on.
• False: the firmware supports Secure Boot and it is off. That still meets the Windows 11 minimum, which asks for Secure Boot capable firmware; Microsoft advises switching it on but does not require it.
• “Cmdlet not supported on this platform.”: the PC starts in Legacy mode, or its firmware has no Secure Boot.
• “Unable to set proper privileges. Access was denied.”: the window was not opened as administrator. This says nothing about the PC; run the cmdlet again in an elevated window.

System Information (msinfo32) shows the same answer as Secure Boot State, without PowerShell.

For the TPM, Get-Tpm in the same window lists TpmPresent, TpmReady and more. TpmPresent False means Windows cannot see a TPM, possibly because it is switched off in UEFI under one of the names above. TpmPresent True with TpmReady False means the TPM is there but Windows has not finished preparing it. Windows does that on its own; on a work PC whose policy saves TPM recovery information in Active Directory, it can finish only while a domain controller is reachable. Get-Tpm does not give the version, so open the TPM console, tpm.msc, and read Specification Version: Windows 11 needs 2.0.

The program below applies these readings to five PCs of one small office, recorded the way a technician writes them down before an upgrade. Run it, then change the Workshop PC’s "1.2" to "2.0" and run it again:

# Five PCs of one small office, as a technician wrote them down before a
# Windows 11 upgrade: what Confirm-SecureBootUEFI printed, TpmPresent and
# TpmReady from Get-Tpm, and the Specification Version shown by tpm.msc
# ("" when Windows found no TPM). The minimum is UEFI firmware that is
# Secure Boot capable, and a TPM 2.0.

DENIED = "Unable to set proper privileges. Access was denied."
NOT_SUPPORTED = "Cmdlet not supported on this platform."

PCS = [
    ("Reception PC", "True", True, True, "2.0"),
    ("Sales laptop", "False", True, False, "2.0"),
    ("Store-room desktop", NOT_SUPPORTED, False, False, ""),
    ("Workshop PC", "True", True, True, "1.2"),
    ("Front-desk laptop", DENIED, True, True, "2.0"),
]

# How much a finding weighs: 1 advice, 2 check firmware, 3 below minimum.
VERDICTS = {
    0: "Meets the minimum",
    1: "Meets the minimum",
    2: "Check firmware settings first",
    3: "Below the Windows 11 minimum",
}


def findings(secure_boot, tpm_present, tpm_ready, tpm_spec):
    """The (weight, text) findings for one PC's readings."""
    found = []
    if secure_boot == "False":
        found.append((1, "Secure Boot capable but off: advise turning it on"))
    elif secure_boot == NOT_SUPPORTED:
        found.append((2, "Secure Boot not supported: look for Legacy/CSM"))
    if not tpm_present:
        found.append((2, "No TPM visible: check PTT, fTPM, Security Device"))
    elif tpm_spec != "2.0":
        found.append((3, f"TPM {tpm_spec} found: Windows 11 needs 2.0"))
    elif not tpm_ready:
        found.append((1, "TPM 2.0 not ready yet: let Windows prepare it"))
    return found


tally = {}
for name, secure_boot, tpm_present, tpm_ready, tpm_spec in PCS:
    if secure_boot == DENIED:
        verdict, found = "No verdict: run PowerShell as administrator", []
    else:
        found = findings(secure_boot, tpm_present, tpm_ready, tpm_spec)
        verdict = VERDICTS[max((weight for weight, _ in found), default=0)]
    tally[verdict] = tally.get(verdict, 0) + 1
    print(f"{name}: {verdict}")
    for _, text in found:
        print(f"  - {text}")

print()
for verdict, count in tally.items():
    print(f"{count} x {verdict}")

Reception PC: Meets the minimum
Sales laptop: Meets the minimum
  - Secure Boot capable but off: advise turning it on
  - TPM 2.0 not ready yet: let Windows prepare it
Store-room desktop: Check firmware settings first
  - Secure Boot not supported: look for Legacy/CSM
  - No TPM visible: check PTT, fTPM, Security Device
Workshop PC: Below the Windows 11 minimum
  - TPM 1.2 found: Windows 11 needs 2.0
Front-desk laptop: No verdict: run PowerShell as administrator

2 x Meets the minimum
1 x Check firmware settings first
1 x Below the Windows 11 minimum
1 x No verdict: run PowerShell as administrator

Two of the five meet the minimum, and one of them is the Sales laptop with Secure Boot off. The store-room desktop has two settings to look at, though Microsoft notes that a TPM 2.0 is not supported in Legacy or CSM mode, so its boot mode may be the only one at fault. The Workshop PC’s TPM 1.2 is below the minimum, and the front-desk reading has to be taken again in an elevated window.

Secure Boot trusts certificates, and the 2011 ones expire

Secure Boot decides what may start by checking signatures against certificates kept in the firmware. Since Windows 8 introduced it, Windows PCs have carried the same set of Microsoft certificates from 2011, and those reach their expiry dates during 2026. Microsoft has issued 2023 replacements, which the update writes into the firmware’s lists of trusted signers:

The last two rows split the old UEFI CA in two, so a PC can trust the drivers of its hardware without trusting every other vendor’s boot loader.

On a supported Windows PC that takes its updates from Microsoft, the change arrives through Windows Update, and most users need to do nothing. What they may notice is a restart: Microsoft warns that a limited number of devices restart one extra time while an update installs, after the certificate change is applied. That restart is the update finishing, not a crash. In a few cases, Microsoft says, a PC may not start or may ask for its BitLocker recovery key after receiving the certificates, so the rule of a reachable recovery key from the next section applies here too.

A PC that never gets the new certificates does not stop working. It keeps starting and installing ordinary updates, but it can no longer receive new protections for the earliest part of the start: new versions of Windows Boot Manager, new revocations and fixes for new boot-level weaknesses. The loss is silent, which is why a PC kept away from updates is worth a ticket of its own.

A firmware update changes what BitLocker measured

Firmware updates reach a PC three ways: the PC maker’s own update app or support site; Windows Update, which delivers firmware as a driver package that UEFI applies during a restart (Surface devices, for one, get theirs this way); and on Linux the fwupd service, which takes updates from the Linux Vendor Firmware Service (LVFS) that the major distributions use. Whatever the route, keep the power steady. Microsoft’s advice for its Surface devices is to plug in, have at least 40 % battery, and leave the device connected and switched on until the update finishes.

The catch is BitLockerBitLocker: The Windows feature that encrypts whole drives, so that the data on a lost, stolen or carelessly decommissioned device stays unreadable to whoever finds it. More in “Windows Security: Defender, firewall, BitLocker”. With a TPM, BitLocker seals the drive’s key to measurements of the early start-up parts that the TPM keeps in its Platform Configuration RegistersTPM PCR: Platform Configuration Register: a measurement slot inside the TPM that records hashes of firmware and boot components. BitLocker seals its key to these measurements, so a firmware change triggers recovery.. New firmware measures differently, so on the first start after a BIOS or UEFI update the TPM keeps the key back and the PC asks for the 48-digit recovery key. Microsoft’s list of causes puts firmware upgrades beside a TPM that is switched off or cleared and changes to the boot manager.

For a planned update the answer is to suspend BitLocker first. Suspending decrypts nothing: the drive stays encrypted, but its key is left in the clear and nothing is checked at start-up, for as many restarts as -RebootCount says (one when it is left out, while 0 means until Resume-BitLocker). When the count runs out, BitLocker resumes and seals the key to the new measurements, with nobody typing a key:

# Suspends BitLocker on C: for one restart, so the first start after a
# firmware update does not stop at the recovery screen. Run it in
# PowerShell opened as administrator, after confirming the recovery key.
# -RebootCount is the number of restarts the update needs: 1 when it is
# left out, while 0 waits for Resume-BitLocker. Afterwards,
# manage-bde -status shows whether protection is on again.

Suspend-BitLocker -MountPoint "C:" -RebootCount 1

A suspended drive can be read by anyone who starts the PC, so keep the count to the restarts the update needs, and check afterwards that protection is back on: manage-bde -status shows it. Step through the whole update:

Its first and last steps happen outside the update itself, and they are the two that make a failed update recoverable and a finished one protected again.

Practise on the office’s PCs

The self-check below opens on the section where your answers have been weakest, and each right answer brings a harder question. Then write the Windows 11 decision yourself, as a function of the three readings the example used:

def windows11_verdict(secure_boot: str, tpm_present: bool, tpm_spec: str) -> str:
    """Return "run as administrator", "below minimum", "check firmware" or "meets minimum"."""
    # Your code here
    pass

from starter import windows11_verdict

DENIED = "Unable to set proper privileges. Access was denied."
NOT_SUPPORTED = "Cmdlet not supported on this platform."


def test_secure_boot_on_meets():
    assert windows11_verdict("True", True, "2.0") == "meets minimum"


def test_secure_boot_off_still_meets():
    assert windows11_verdict("False", True, "2.0") == "meets minimum"


def test_legacy_mode_checks_firmware():
    assert windows11_verdict(NOT_SUPPORTED, True, "2.0") == "check firmware"


def test_no_tpm_checks_firmware():
    assert windows11_verdict("True", False, "") == "check firmware"


def test_tpm_1_2_is_below_minimum():
    assert windows11_verdict(NOT_SUPPORTED, True, "1.2") == "below minimum"


def test_access_denied_has_no_verdict():
    assert windows11_verdict(DENIED, True, "1.2") == "run as administrator"

Interview questions

The warm-up is answered in full below. The two longer cases both start from a laptop that BitLocker protects, one a developer’s dual-boot plan and the other a recovery screen that keeps coming back; decide what you would check before anything else, then compare it with each case’s first step:

Key takeaways

• UEFI setup holds the four settings that decide how a PC starts, the boot order, UEFI or Legacy (CSM) mode, Secure Boot and the TPM, and it opens from a startup key or from Advanced startup in Windows.
• Windows 11 needs UEFI firmware that is Secure Boot capable and a TPM 2.0, so a Confirm-SecureBootUEFI answer of False still meets the minimum, while “not supported” or a missing TPM sends you to the firmware settings.
• The checks are taken in a window opened as administrator, because an access-denied message is not a reading, and clearing a TPM is a last resort, done from Windows, because it deletes every key the TPM holds.
• Secure Boot’s Microsoft certificates from 2011 are replaced by 2023 ones through Windows Update; one extra restart is expected, and a PC that misses them keeps starting but loses new start-up protections.
• Before a firmware update on a BitLocker PC, confirm the recovery key, keep the PC on mains power and suspend BitLocker for the restarts the update needs, then check that protection has resumed.