Basic Input/Output System (BIOS) is firmware that starts a computer, performs hardware checks and hands control to the operating system loader. Because it runs before the OS, it can influence boot integrity and device trust. Defenders should protect firmware settings, restrict boot order changes and monitor for unauthorised firmware modification or bootkits.
What BIOS actually does during startup
BIOS is the first layer of firmware that runs after power-on. Its job is to initialise enough hardware to make the machine usable, perform a basic POST-style check, and locate the boot device that contains the operating system loader. On older PCs, BIOS also defined the handoff between firmware and the OS; on modern systems, that role is often shared with or replaced by UEFI, but the boot sequence problem is the same.
Because BIOS runs before the operating system, it sits below normal endpoint protections. That means firmware settings, boot order, and boot-device trust are part of the startup security boundary rather than just convenience options. If those settings are weak or altered, the system can be steered toward untrusted media or a compromised loader before the OS ever gets a chance to enforce policy.
BIOS is also limited by design. It is not a rich security platform, and it usually does not offer deep visibility into later boot stages, running processes, or network activity. Its security value comes mainly from controlling the early trust path, not from detecting threats after the OS is live.
How the BIOS-to-OS handoff works
At a practical level, BIOS brings the platform up in a fixed sequence. It initialises chipset and memory basics, checks attached devices, and uses its boot configuration to decide where to look first for executable startup code. Once it identifies a valid boot target, it loads the boot sector or hands off to a boot loader that can continue initialising the operating system.
This handoff matters because the firmware trusts the selected boot path before the OS can apply its own controls. If the boot order points to removable media, an external disk, or a tampered internal loader, the machine may still start, but from the wrong trust anchor. That is why startup integrity is tied to the firmware configuration itself, not only to the installed OS.
In environments that still rely on legacy BIOS behaviour, the main operational question is not whether the firmware “works”, but whether it is predictable, locked down, and consistent across the fleet. If firmware settings drift between devices, boot behaviour becomes harder to audit and easier to abuse.
Why BIOS security still matters
The security implications of BIOS are concentrated in pre-boot trust. A hostile or careless change to firmware settings can disable secure startup controls, weaken device trust, or expose the system to boot-level malware. For that reason, basic startup management is still a meaningful control surface even when the operating system is well hardened.
Firmware-hardening guidance is strongest when it treats BIOS as part of the chain of trust rather than as a one-time setup screen. NHIMG’s Firmware and Boot Security Guide is useful here because it covers measured boot, bootkits, BIOS security, and the broader pre-OS trust path that determines whether the machine starts from a known-good state.
Defenders should especially care about firmware changes that persist across reboots. A bootkit, altered boot order, or modified firmware image can survive normal OS-level remediation if the team only rebuilds the operating system and never inspects the startup layer.
Risk and Threat Considerations
BIOS risk is highest when an attacker can change boot behaviour, alter firmware, or force the machine to trust a malicious startup path. The practical danger is not just unauthorised access to a single device, but persistence below the operating system, where many endpoint controls are blind or only partially effective.
Failure mechanism: Weak firmware settings, unprotected boot order, or compromised firmware can let malicious code run before the OS, giving an attacker persistence and a trusted execution path that can survive routine OS repair.
Impact: The result can be device compromise, silent re-infection after reboot, and loss of trust in the platform’s startup integrity, especially if the environment does not monitor firmware state changes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-3 — Device Identification and Authentication | Boot firmware trust depends on device-level authentication and startup integrity. |
| CM-6 — Configuration Settings | BIOS security depends on controlled startup settings and restricted boot order. | |
| SI-7 — Software, Firmware, and Information Integrity | Firmware modification and bootkits are integrity threats at the pre-OS layer. | |
| Recommendation — Authenticate managed devices before allowing trusted boot paths and firmware updates. Enforce approved firmware configuration baselines and monitor for drift. Verify firmware integrity and investigate unexpected pre-boot changes. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | BIOS hardening is part of secure configuration for enterprise endpoints. |
| CIS-8 — Audit Log Management | Firmware-setting changes and boot anomalies need auditable detection. | |
| Recommendation — Harden firmware settings and prevent unauthorised boot configuration changes. Log and review firmware configuration changes and boot-chain anomalies. | ||
Practitioner Guidance
What to verify: Confirm that BIOS or firmware passwords are enabled where appropriate, boot order is restricted to approved devices, and any firmware update path is controlled and logged. If a device can boot from removable media without administrative approval, treat that as a security gap rather than a convenience setting.
What to prioritise: Review firmware integrity on systems that handle sensitive credentials, privileged administration, or sensitive workloads first, because a compromised boot path can undermine every higher-level control that depends on the OS being trustworthy.
Practitioner takeaway: BIOS is not just startup plumbing, it is the first trust decision the computer makes, so the most important judgement is whether that trust path is locked down enough to survive tampering before the OS loads.