Hardware and firmware vulnerabilities — SY0-701

WHAT IT IS

A hardware or firmware vulnerability is a weakness in a physical component or in the low-level code that controls that component — a weakness "by which an actor or event may intentionally exploit or accidentally trigger the weakness to access, modify, or disrupt the normal operations of a system" (NIST SP 800-61r3).

Firmware is "computer programs and data stored in hardware — typically in read-only memory (ROM) or programmable read-only memory (PROM) — such that the programs and data cannot be dynamically written or modified during execution of the programs" (CNSSI 4009-2015 / NIST SP 800-53 Rev. 5). Vulnerabilities in firmware therefore sit below the operating system and can persist across OS reinstalls.

---

Mental model

Think of a computing system as a stack of trust layers. The OS and applications sit at the top; below them is firmware (BIOS/UEFI); below that is the physical silicon. A weakness at a lower layer undermines every layer above it, because higher layers implicitly trust that the layer beneath them is functioning correctly. That asymmetry — lower layers are trusted more but are harder to inspect or update — is the core risk.

A weakness at layer C or D is invisible to tools that only inspect layers A or B.

---

When to use it

Use the hardware/firmware vulnerability category when the weakness is rooted in the physical component or in the low-level code that initializes or controls that component — not in an application or OS service running on top of it.

Scenario	Category	Why
Weakness in silicon that leaks information through power consumption or electromagnetic emissions	Hardware vulnerability / side-channel attack	The leakage originates from the physical cryptosystem (NIST SP 1800-21B)
Malicious code implanted in a device before installation, inserted during the supply chain	Supply chain attack	Adversary exploits "vulnerabilities inserted prior to installation" (CNSSI 4009-2015)
A rootkit installed by an attacker after gaining elevated access, concealing itself on the host	Software / OS rootkit	Tools used after gaining root-level access to the host (CNSSI 4009-2015)
Code stored in ROM that initializes hardware before the OS loads, found to contain a weakness	Firmware vulnerability	Weakness in "programs stored in hardware…in ROM or PROM" (CNSSI 4009-2015)

---

COMMON MISCONCEPTION

Misconception: patching the OS or reinstalling software removes a firmware-level implant.

This is the specific trap. A rootkit at the firmware layer is defined as a collection of files that "alter the standard functionality of the host in a malicious and stealthy way" (NIST SP 800-83 Rev. 1). Because firmware persists in ROM or PROM below the OS, an OS-level remediation does not touch it. The weakness survives a wipe-and-reinstall because it is not part of the software stack being replaced.

Similarly, candidates sometimes conflate a side-channel attack — which is "enabled by leakage of information from a physical cryptosystem" such as "timing, power consumption, electromagnetic emissions, and acoustic emissions" (NIST SP 1800-21B) — with a software exploit. A side-channel attack does not inject malicious code; it passively extracts information by observing physical behavior. The mitigation category differs accordingly.

---

How it shows up on the exam

The cognitive target for this concept is distinguishing the layer at which a vulnerability resides and choosing the appropriate countermeasure for that layer.

Candidates often read a scenario description and assume that any persistent, stealthy threat is an OS-level rootkit. The signal phrases that should redirect attention to the firmware/hardware layer include:

• "survives a reinstall" or "persists after the OS is replaced"
• "supply chain" or "implanted before delivery"
• "power analysis," "timing analysis," or "electromagnetic leakage" — signal phrases consistent with side-channel attacks (NIST SP 1800-21B)
• references to a Trusted Platform Module (TPM) — "a tamper-resistant integrated circuit built into some computer motherboards that can perform cryptographic operations" (NIST SP 800-147) — as either the target or the countermeasure
• references to UEFI, "a possible replacement for the conventional BIOS" (NIST SP 800-147), in the context of integrity verification

A common misconception is that any "low-level" attack is addressed by endpoint-detection or antivirus tools. Candidates who understand that firmware vulnerabilities reside below the software trust stack will recognize that responses such as reinstalling the OS or updating antivirus definitions do not address firmware- or hardware-layer weaknesses.

---

Related concepts

• Memory vulnerabilities
• Race conditions
• SQL injection