How do attackers use Option ROM?

How attackers abuse Option ROM during startup

option rom is attractive because it runs before the operating system has a chance to enforce normal security controls. Malicious code placed there can execute during firmware or device initialisation, giving attackers early persistence, a hiding place from host-based tooling, and a way to change boot behaviour. The important security question is not just whether the machine boots, but whether the boot chain still reflects trusted firmware and devices.

Where the attack surface comes from

Option ROMs are firmware payloads associated with expansion devices such as storage, network, graphics, and other peripherals. If the platform allows them to load unchecked, an attacker with firmware-writing access, malicious hardware, or a supply-chain foothold can abuse that trust boundary. The value of the technique is that it sits beneath the operating system, so many endpoint controls will not see the malicious code until after damage is already done.

That makes the real exposure broader than simple malware persistence. A tampered ROM can interfere with boot integrity, alter device behaviour before policy loads, or create a bridge into the platform firmware environment. A useful defensive reference point is Firmware and Boot Security Guide, which covers the surrounding boot-chain controls that matter when you are assessing this class of abuse.

How to confirm and reduce exposure

The first step is to confirm which devices can even supply executable ROM code in your fleet. That means inventorying expansion hardware, checking firmware policy settings, and verifying whether unsigned, unexpected, or vendor-default ROM paths are allowed to load. In practice, many organisations discover that the risk is not one device class, but a combination of legacy compatibility settings and weak change control over firmware updates.

Reduction is about tightening trust at the boot layer. Disable unused expansion devices where possible, restrict firmware update paths, and require integrity checks for device and platform firmware. If the platform supports measured boot, attestation, or related firmware validation, use those signals to tell the difference between an expected boot path and an altered one. The goal is to make any ROM change observable, not merely possible.

Because this is a pre-OS attack path, defenders should also consider the surrounding ecosystem, including supply-chain and device-management risk. A compromised or tampered platform component can matter as much as a traditional malware infection. For a broader attacker view, The State of NHI & AI Agent Breach Report 2026 is useful mainly as a reminder that early, hidden access paths often matter more than the final payload.

Risk and Threat Considerations

Option ROM abuse is dangerous because it attacks the trust assumptions that sit underneath the operating system. Once code runs at firmware or device-initialisation time, defenders may lose visibility, boot behaviour can be altered, and compromise can survive OS reinstallation if the underlying firmware state is not cleaned up.

Failure mechanism: The attacker places or modifies ROM code so the malicious payload executes before normal security tooling, then uses that early execution to persist, mask activity, or alter the boot chain.

Impact: The result can be stealthy persistence, a compromised boot process, and a platform that appears healthy from the OS perspective while remaining untrustworthy below it.

Practitioner Guidance

What to verify: Confirm which systems permit third-party or legacy Option ROM execution, and verify that firmware settings, device inventories, and boot integrity evidence all match the approved baseline. Treat unexplained boot delays, device enumeration changes, or new firmware signatures as security events, not just stability issues.

Decision rule: If a platform can boot from or load external device firmware that you cannot validate, prioritise firmware integrity controls and hardware policy changes before you rely on host scanning or reimaging. If you only investigate the operating system layer, you may miss the persistence mechanism entirely.

Practitioner takeaway: The practical defence is to treat boot-time firmware as part of the security boundary, because once malicious ROM code is trusted during initialisation, many later controls are already too late.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?