Option ROM is firmware stored on an expansion device that the system can execute during boot to add device support or pre-boot functions. Attackers can abuse malicious or modified Option ROM code to persist below the operating system, so defenders should verify firmware integrity and restrict unsigned hardware.
What Option ROM Does in the Boot Chain
Option ROM is pre-OS firmware on an expansion card or controller that can extend hardware support before the operating system loads. It matters because it runs early, before many endpoint protections are active, and it can shape how the machine starts.
That early execution model makes Option ROM part of the trusted boot path, not just a peripheral detail. If the firmware is legitimate, it helps the platform initialise devices cleanly. If it is altered, it can become an execution point that sits below the OS and survives ordinary software-based defenses.
Why Option ROM Is Security Sensitive
Security teams care about Option ROM because it can execute outside the visibility of the operating system and some endpoint tools. A malicious image can add hidden functionality, tamper with boot-time behaviour, or create a durable foothold that is difficult to inspect from user space.
This is one of the reasons firmware integrity checks matter at the platform layer. Defenders should treat expansion-device firmware as part of the attack surface and use trusted boot and hardware-rooted verification where available, rather than assuming the OS can detect everything after startup.
For broader control context, NIST’s control catalog covers system integrity, configuration management, and firmware-relevant safeguards in NIST SP 800-53 Rev 5 Security and Privacy Controls.
How Organisations Reduce Exposure
Exposure starts with inventory. Teams need to know which servers, workstations, and embedded platforms have expansion cards or controllers capable of carrying boot-time firmware, and which vendors actually allow firmware signing, secure boot integration, or ROM disabling.
Mitigation usually combines firmware verification, secure boot settings, device allowlisting, and procurement rules that reject untrusted hardware. In practice, the goal is to reduce the chance that unsigned or modified Option ROM code can execute at all, especially on systems that handle sensitive credentials or high-value workloads.
For a control-oriented lens on hardening and verification, NIST Cybersecurity Framework 2.0 provides a useful governance structure, while NIST AI Risk Management Framework is relevant where boot-time trust assumptions support AI-enabled infrastructure.
Detection, Response, and Recovery After Compromise
Option ROM abuse is hard to see because the malicious logic may live below the operating system and can survive disk reimaging or endpoint cleanup. That means defenders often need firmware-focused detection, platform attestation, and validation against known-good measurements rather than relying only on malware scans.
When compromise is suspected, the response question is not just “remove the file,” but “re-establish trust in the platform.” That can require firmware reflashing from a trusted source, hardware replacement in severe cases, and review of any boot-time tampering that may have enabled credential theft or persistence.
In environments that track adversary technique families, MITRE ATT&CK Enterprise Matrix is useful for mapping persistence and defense-evasion behaviours that align with firmware-level abuse.
Risk and Threat Considerations
Option ROM is dangerous because it can sit beneath the operating system, where many controls do not normally inspect. That makes it attractive for persistence, stealth, and boot-chain subversion, especially on systems where hardware trust is assumed rather than continuously verified.
Failure mechanism: A malicious or tampered ROM executes during boot, survives conventional OS-level remediation, and can preserve access or alter the system before higher-level defenses start.
Impact: The result can be long-lived compromise, hidden pre-OS control, and downstream exposure of credentials, boot integrity, or device trust across subsequent starts.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set 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 | Option ROM is firmware integrity in the boot chain. |
| CM-8 — System Component Inventory | Exposure depends on knowing which devices can carry bootable expansion firmware. | |
| SI-2 — Flaw Remediation | Tampered firmware often requires trusted reflash and recovery actions. | |
| Recommendation — Apply SI-7 to verify firmware integrity before trusting boot-time execution. Maintain CM-8 inventory coverage for devices with boot-capable expansion firmware. Use SI-2 to restore trusted firmware images and validate post-remediation state. | ||
| NIST CSF 2.0 | PR.DS-08 — Integrity Mechanisms | Boot firmware trust depends on integrity mechanisms and verification. |
| Recommendation — Deploy integrity mechanisms to detect unauthorized firmware changes. | ||
| MITRE ATT&CK | T1542.001 — Pre-OS Boot: System Firmware | Option ROM abuse is a classic pre-OS boot persistence mechanism. |
| Recommendation — Map firmware persistence activity to T1542.001 and hunt for boot-chain tampering. | ||
Practitioner Guidance
Why practitioners should care: Treat Option ROM as part of platform trust, not peripheral functionality. If a device can execute boot-time code, it can also become part of the persistence and integrity story for the whole endpoint.
What to watch for: Pay attention to unsigned firmware, unexpected expansion-device behaviour, unexplained boot anomalies, and environments where firmware provenance is unclear. Those are the conditions where a boot-chain issue is most likely to be missed.
Practitioner takeaway: If you cannot verify the firmware source and integrity of the device, you should not assume the platform is clean just because the operating system is.
Related resources from NHI Mgmt Group
- When does a cloud-native directory become the better option?
- Who should keep a non-mobile authentication option available?
- Why do unsafe option filters fail when Git wrappers accept multiple spellings of the same clone argument?
- Why do passkey flows fail when they only offer one authenticator option?