BIOS is targeted by firmware implants, unauthorised flashing, bootkits, and attacks that disable secure boot or hardware protections. If an attacker controls BIOS, they can persist below the operating system and evade many tools. Defenders should restrict firmware updates, use integrity checking where available, protect boot settings, and monitor for unexpected firmware changes.
What kind of attacks target BIOS, and why does that matter?
BIOS is a high-value firmware layer because it runs before the operating system and can shape every later security decision. The attack patterns that matter most are those that change firmware code, alter boot trust, or weaken hardware protections so the system starts already compromised. That makes BIOS attacks less visible than ordinary malware and harder to remove with standard endpoint tools.
Firmware implants are especially dangerous because they survive reinstalls, disk wipes, and many incident-response steps. Bootkits aim for the same advantage by intercepting the boot chain early enough to load malicious code before higher-level defenses are active, while settings tampering can quietly remove the checks that would normally stop unauthorised boot components.
Which BIOS attack paths are most common in practice?
The main paths are malicious firmware modification, unauthorised flashing, bootloader or boot-chain tampering, and attacks that disable secure boot or other platform protections. In operational terms, these attacks either replace trusted firmware with hostile code or change the conditions under which trusted code is allowed to start. Both approaches are designed to give the attacker durable pre-OS control.
One useful way to think about this is that BIOS compromise is often not a single exploit but a sequence: gain administrative or physical access, change firmware or boot settings, and then use that foothold to persist beneath the operating system. The system can look normal from the OS perspective even when the trust base has been altered.
For firmware and boot-chain weaknesses, Firmware and Boot Security Guide is the most direct reference for secure boot, measured boot, bootkits, firmware update hygiene, and platform protections that limit this class of attack.
At the broader attack-chain level, BIOS compromise fits the same persistence logic seen in real intrusions that abuse identity material, trusted update paths, and early-stage execution. The State of NHI & AI Agent Breach Report 2026 is not BIOS-specific, but it helps frame how attackers convert trusted access paths into durable control once they get a foothold.
How should defenders think about detection and recovery?
BIOS attacks are difficult to confirm because the compromise sits below the operating system, so defenders need to verify firmware integrity rather than rely only on endpoint alerts. Useful checks include comparing firmware hashes where available, reviewing boot configuration for unexpected changes, and confirming that secure boot and platform protections are still enabled after maintenance events or physical access.
Recovery is usually more involved than malware cleanup. If the firmware has been altered, the safer response is often to reflash from a trusted source, restore approved boot settings, and inspect adjacent components such as BMCs, boot media, and firmware update channels. If you cannot establish firmware trust, you cannot assume the operating system image is trustworthy either.
Where secure boot or boot-chain controls are part of the issue, the same firmware and boot security guidance is useful for deciding what to verify first and which integrity signals matter most.
Risk and Threat Considerations
BIOS compromise matters because it creates persistence below the operating system, where normal EDR, antivirus, and many forensic tools have limited visibility. Once an attacker can change boot trust or firmware code, they can survive reimaging and use that position to interfere with later security controls, credential handling, and incident response.
Failure mechanism: The attacker abuses firmware update paths, boot settings, or pre-boot trust controls to install malicious code or disable the checks that would block it. That lets the system execute attacker-controlled code before the OS can enforce its own protections.
Impact: The result can be long-lived compromise, stealthier persistence, and loss of confidence in the platform’s boot integrity. In practice, that often means wider remediation, more cautious evidence handling, and a lower threshold to reflash or replace affected hardware.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Firmware implants and tampering directly require firmware integrity controls. |
| CM-5 — Access Restrictions for Change | Unauthorized flashing and boot-setting changes are change-control failures. | |
| AC-3 — Access Enforcement | Boot-setting protection depends on enforcing who can alter privileged configuration. | |
| Recommendation — Verify firmware integrity and alert on unexpected changes to boot-critical code. Restrict who can modify BIOS settings or flash platform firmware. Enforce least-privilege access for firmware administration paths. | ||
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | Firmware compromise can coexist with weak platform and environment configuration controls. |
| Recommendation — Harden platform configuration paths that can affect firmware trust. | ||
| MITRE ATT&CK | T1542.001 — System Firmware | BIOS implants are a canonical system-firmware persistence technique. |
| Recommendation — Map pre-OS persistence findings to firmware-focused hunting and triage. | ||
Practitioner Guidance
What to verify: Confirm whether the platform supports firmware integrity checks, secure boot status, and trusted update workflows. If those controls are present but not monitored, the environment can still be vulnerable even when no malware is visible in the OS.
Escalation / exception: Treat unexplained firmware changes, boot-setting drift, or repeated secure-boot failures as a high-priority investigation, especially after remote administration, vendor servicing, or physical access events. If the system protects sensitive workloads, escalate faster and assume possible pre-OS persistence until disproven.
Practitioner takeaway: BIOS attacks are dangerous because they attack trust itself, so the right response is to verify firmware state, not just scan the operating system.