How does an option ROM work?

What an option ROM actually does during boot

An option rom is not part of the operating system. It is firmware attached to a peripheral, expansion card, or similar device that the platform can execute early in the boot process. Its job is to initialise the hardware, expose boot-time services, or hand off a device-specific function before the OS and its drivers are fully available.

That early execution window is why option ROMs matter to boot security. They run with very little of the host’s normal control stack in place, so the firmware itself becomes part of the trusted computing base for that boot path. If the platform loads it, the code can influence device initialisation, boot order, and sometimes the integrity of what the operating system later inherits.

An important practical distinction is that a legitimate option ROM supports device bring-up, while a malicious one can masquerade as trusted pre-boot firmware. The risk is not theoretical: pre-OS code can bypass many runtime defenses simply because those defenses are not active yet.

How boot-time firmware abuse works in practice

Option ROM abuse usually depends on a platform accepting and executing untrusted firmware before the OS has a chance to enforce policy. That can let an attacker modify boot behavior, hide persistence below the OS, or create a foothold that survives ordinary endpoint tools. The issue is closely related to broader firmware attack surfaces such as bootkits, UEFI abuse, and malicious peripheral firmware.

Modern systems try to reduce that exposure with secure boot controls, firmware signature checks, and measured boot. The key idea is to make pre-boot execution contingent on trusted code and to record what ran so integrity can be verified later. For guidance on the wider boot-security surface, see Firmware and Boot Security Guide.

Option ROMs can also be introduced through devices that are rarely reviewed as security-sensitive, which makes them easy to overlook during change management. A benign-looking card, dock, or adapter can still contribute executable firmware to the boot chain if the platform allows it.

What defenders should verify and control

Defenders should treat option ROMs as part of firmware governance, not just hardware support. The first question is whether the platform even permits external or unsigned option ROM execution. If it does, the next question is whether that behavior is intentional, documented, and monitored. Secure boot, firmware allowlisting, and device inventory are the core controls that reduce the attack surface.

Firmware update hygiene matters just as much as startup policy. If device firmware can be updated without strong provenance checks, an attacker who reaches the supply or update path may be able to replace a benign ROM with one that survives reboots. The practical control objective is to know which devices can execute firmware, which firmware versions are approved, and how deviations are detected.

Use platform firmware settings, vendor update channels, and signed firmware enforcement together rather than as isolated checks. A strong boot posture is one where unsigned pre-boot code is blocked by default and exceptions are rare, explicit, and auditable.

Risk and Threat Considerations

Option ROMs are risky because they sit below the operating system’s normal visibility and can execute before endpoint controls, EDR, or application telemetry are fully effective. That gives malicious firmware an opportunity to establish persistence or alter boot behavior while remaining difficult to inspect from the host OS alone.

Failure mechanism: A platform accepts untrusted or malicious option ROM code during boot, allowing the code to run before normal security controls are active and to influence device or boot initialization.

Impact: The result can be pre-OS persistence, weakened boot integrity, hidden compromise, and a recovery problem that often requires firmware-level remediation rather than ordinary malware cleanup.

Practitioner Guidance

What to verify: Confirm whether your device fleet allows external option ROM execution, whether secure boot is consistently enabled, and whether any exceptions are tied to a documented business need. If a platform can boot from removable or add-in hardware, test that path as part of hardening, not only during incident response.

What to prioritise: Focus first on devices that are frequently docked, expanded, repaired, or supplied by third parties, because those are the settings where unreviewed firmware often enters the environment. If you cannot fully block the feature, make sure the platform records firmware state changes and that the security team can review them.

Practitioner takeaway: Treat option ROMs as boot-chain code with security consequences, not as routine device firmware. If you cannot trust the pre-OS code path, you cannot fully trust the machine’s startup state.

Related resources from NHI Mgmt Group

• How does Boot ROM work?
• Option ROM
• What is an SVID and how does it work?
• How does OAuth 2.0 work for NHIs and what are its limitations?