Secure boot
In device security, secure boot is a chain of trust that verifies the signature of each boot stage before running it, so modified firmware or a tampered operating system will not start. It is the control that separates a rootkit from a bootkit: a bootkit persists in the boot chain below the operating system, exactly where secure boot enforces trust.
How it works
Secure boot builds trust from an immutable starting point, typically code in read-only memory or a hardware root of trust that cannot be changed. That first stage verifies the digital signature of the next stage before executing it; that stage verifies the next, and so on up through the bootloader and into the operating system. If any stage fails verification (because it was modified, or signed by a key the chain does not trust) the boot stops or falls back. The effect is that only firmware and software the manufacturer signed will run, which closes off the persistence trick of quietly replacing an early boot component. It is the same signature machinery used everywhere else, applied to the order in which a device starts.
What goes wrong
Understanding secure boot clarifies a common confusion between a rootkit and a bootkit. A rootkit hides within a running system; a bootkit installs itself in the boot chain, below the operating system, so it loads before any operating-system defence and survives a reinstall of the operating system. Secure boot is precisely the control that stops a bootkit, because the tampered boot component fails signature verification. The failures we find are secure boot absent entirely, present but with signature checks that can be disabled, or a device that verifies the operating system but not the firmware beneath it, leaving the lowest layer, the one a bootkit targets, unprotected. Verifying one layer while leaving the layer below it open is a partial defence that reads as a full one.
Where this shows up in an audit
We test the boot chain from the root of trust upward: whether each stage is verified, whether the checks can be bypassed or disabled, and whether the firmware layer beneath the operating system is covered. This connects to firmware analysis, since a device that runs unsigned firmware has no boot integrity to speak of, and to the update path, because signed updates are what keep the chain trustworthy over time. For products in scope of the Cyber Resilience Act this integrity is an expectation, not an option. This is part of how we test the boot chain and update integrity.