Secure Boot

What is Secure Boot?

Secure Boot is a security mechanism in which a device checks the digital signature of its firmware, bootloader and operating system at every start and only runs code signed by a trusted party. This stops tampered or malicious code from taking hold before the operating system or process automation software is running, the moment when antivirus and monitoring cannot yet see anything. In OT environments, Secure Boot protects PLCs, HMIs, industrial PCs (IPC) and embedded devices against persistent malware introduced through bootable media or modified firmware.

🧠 How does Secure Boot work?

Secure Boot builds a chain of trust. Each link verifies the next one before it is allowed to start:

1. Root of trust - an immutable starting point, for example boot ROM code in the processor with a hash of the public key in one-time-programmable fuses, or a secure element.
2. Firmware or UEFI - the root of trust verifies the signature of the platform firmware.
3. Bootloader - the firmware checks the bootloader against a list of permitted keys.
4. Kernel and drivers - the bootloader only loads a signed kernel; the operating system can then require drivers to be signed as well.
5. Rejection - if a check fails, the device halts or falls back to a recovery image. No unauthorised code runs.

Secure Boot itself does not keep a log of what was started. That is the job of measured boot: every step is hashed and recorded in a Trusted Platform Module (TPM), so that a server can later verify that the device booted cleanly.

🔧 How does UEFI Secure Boot work on industrial PCs?

On x86 systems such as engineering stations, SCADA servers and panel PCs, Secure Boot is defined in the UEFI specification (since version 2.3.1). The firmware manages four key databases:

An image only starts if it is in db and not in dbx. Most PCs ship with Microsoft certificates in KEK and db. Linux boots through a Microsoft-signed shim, which can add its own keys (Machine Owner Keys). Windows 11 requires a PC that supports UEFI Secure Boot, alongside TPM 2.0.

Current issue: Microsoft’s 2011 certificates expire in 2026. The KEK CA 2011 expired on 24 June 2026, the UEFI CA 2011 on 27 June 2026, and the Windows Production PCA 2011 expires on 19 October 2026. Devices without the 2023 successors keep booting, but no longer receive new dbx updates or boot security fixes. For OT PCs that rarely get firmware updates, this is a concrete patch management item.

🏭 Where does Secure Boot matter in OT?

A real-world example: in January 2023 Siemens reported (advisory SSA-482757, CVE-2022-38773) that certain S7-1500 CPUs lack an immutable hardware root of trust. Someone with physical access could replace the boot image, and no software patch could fix this. Siemens released new hardware versions with a new secure boot mechanism and advised restricting physical access to older units.

🔄 How does it differ from Firmware Signing and Code Signing?

The measures are complementary: signing decides what may be installed, Secure Boot decides what may run. Without Secure Boot, an attacker with write access to the storage medium can bypass a signed update by replacing the files directly.

🔐 What do IEC 62443 and the Cyber Resilience Act require?

• IEC 62443-4-2 - component requirement CR 3.14 Integrity of the boot process requires a device to verify the integrity of firmware and software during boot; requirement enhancement RE(1) adds verification of authenticity. CR 3.12 and CR 3.13 cover the secure provisioning of the supplier’s and the asset owner’s roots of trust.
• IEC 62443-3-3 - at system level this falls under SR 3.4 Software and information integrity, within FR 3 System Integrity.
• Cyber Resilience Act - Annex I requires manufacturers to protect the integrity of programs, commands and configuration against unauthorised modification and to ship products secure by default. Reporting obligations apply from 11 September 2026, full application from 11 December 2027.
• NIST SP 800-193 - the US guideline on Platform Firmware Resiliency (2018) goes beyond Secure Boot: protecting, detecting and recovering firmware.

In the CSIR model, Secure Boot falls primarily under VSE (a system-technical measure at firmware level), with VSP as supporting policy for firmware integrity.

⚠️ Which limitations and attacks should you know about?

• Boot time only - Secure Boot checks code when it is loaded, not during operation. An implant loaded into the memory of a running controller, as with TRITON in 2017, escapes it.
• Patched but not revoked - in 2022 and 2023 the BlackLotus bootkit abused CVE-2022-21894 in old Windows boot managers that had been patched but not yet added to dbx. Microsoft followed up in May 2023 with CVE-2023-24932, whose revocation initially had to be enabled manually.
• Weak keys - with PKfail (2024), many UEFI devices turned out to still use an AMI test key labelled “DO NOT TRUST” as their Platform Key.
• Legacy equipment - many installed PLCs and panel PCs do not support Secure Boot; only compensating controls help there.
• Misconfiguration - a wrongly applied dbx update or key change can also block legitimate bootloaders and updates. Moreover, Secure Boot only works if the supplier actually signs its firmware and software cryptographically.
• Disabled for convenience - on industrial PCs Secure Boot is sometimes switched off because of old drivers or vendor USB boot media.

🎯 How do you introduce Secure Boot in an OT environment?

1. Take inventory - record per device in the asset inventory whether Secure Boot is supported and enabled, and which hardware revision it has.
2. Test first - enable Secure Boot on a test system first; old drivers and vendor tools may refuse to start.
3. Manage keys and certificates - track the Microsoft certificate renewal and dbx updates through change management.
4. Combine with TPM and disk encryption - measured boot makes deviations visible, encryption protects against data being read out.
5. Set supplier requirements - include CR 3.14 in procurement requirements and ask about the root of trust and key management (supplier security).
6. Lock down the UEFI - set a UEFI password and disable booting from USB as part of hardening.

Secure Boot is thus one layer within defence in depth, alongside segmentation, access control and security by design.

❓ Frequently asked questions

Is Secure Boot the same as a TPM?

No, Secure Boot and a TPM complement each other. Secure Boot blocks unsigned code from starting, while a Trusted Platform Module records what was started (measured boot) and only releases keys after a clean boot.

Does Secure Boot protect against ransomware?

Secure Boot only protects against code that embeds itself in the boot chain, such as bootkits and rootkits. Ransomware that runs as an ordinary application after startup is not stopped by Secure Boot; that requires patching, segmentation and backups.

What happens when Microsoft’s 2011 Secure Boot certificates expire?

PCs that only have the 2011 certificates continue to boot normally. However, they can no longer receive new dbx revocations and boot security updates, so newly discovered bootkits will no longer be blocked.

Can I enable Secure Boot on an existing PLC afterwards?

Usually not, because Secure Boot on a PLC requires a hardware root of trust. For the Siemens S7-1500, only a new hardware version resolved the missing root of trust; for older devices, physical protection and network segmentation remain the main controls.

Which IEC 62443 requirement covers Secure Boot?

In IEC 62443-4-2, component requirement CR 3.14 covers the integrity of the boot process, with RE(1) for its authenticity. At system level, Secure Boot maps to SR 3.4 of IEC 62443-3-3, software and information integrity.

Does Secure Boot work on virtual machines?

Yes, modern hypervisors provide UEFI firmware with Secure Boot and a virtual TPM for virtual machines. For virtualised SCADA and historian servers you then need to check the certificate renewal at both hypervisor and VM level.

📌 In summary

Secure Boot ensures that a device only runs signed, trusted firmware and software at every start, making it the foundation for the integrity of PLCs, HMIs and industrial PCs.

It works through a chain of trust from an immutable root of trust. Combine it with firmware signing, a TPM, up-to-date certificate management and patch management. Secure Boot does not stop attacks during operation, and devices with remote access or physical exposure still need further controls, so it remains one layer in a broader OT defence.