safemode.space
← All techniques
EX-0005
ST0004Execution

Exploit Hardware/Firmware Corruption

Description

The adversary achieves execution or effect by corrupting or steering behavior beneath the software stack, in device firmware, programmable logic, or the hardware itself. Examples include tampering with firmware images or configuration blobs burned into non-volatile memory; targeting MCU/SoC boot ROM fallbacks; editing FPGA bitstreams or partial-reconfiguration frames; or leveraging physical phenomena and timing to flip bits or skip checks. Because these actions occur below or alongside the operating system and application FSW, traditional endpoint safeguards see normal interfaces while trust anchors are already altered.

Mappings

EU regulation articles

  • craAnnex I, Part I, (2)(f)
    addresses
    moderate
    derived

    Integrity protection on firmware images and programmable-logic bitstreams resists corruption introduced beneath the software layer.

  • craAnnex I, Part II, (1)
    addresses
    moderate
    derived

    Component identification at hardware/firmware granularity surfaces the population that hardware-firmware-corruption attacks ride through; SBOM-style hardware inventories are the manufacturer's traceability control.

  • craAnnex I, Part II, (5)
    addresses
    high
    direct

    Exploitation of malicious code embedded during supply chain (primary mapping: Annex I, Part II, (1) + Art. 13(5)) requires CVD policy under (5) to receive and process third-party reports about such embedded artifacts.

  • craArt. 13(5)
    addresses
    high
    derived

    Manufacturer due-diligence on the supplier of the affected hardware/firmware is the upstream control that bounds the corruption surface beneath the software stack.

  • eu-space-actArt. 84(2)
    addresses
    moderate
    inferred

    Art. 84(2)'s comply-with-Annex-VII-5.1 reference is domain-relevant to below-OS exploitation but names no specific interdicting mechanism in the cited text.

  • eu-space-actArt. 92(1)
    addresses
    moderate
    direct

    Hardware/firmware corruption requires manipulation at supplier or integration stages; 92(1)'s contractual information-security obligation covers the supply-chain touchpoints where bitstreams and firmware images are produced or loaded.

  • nis2Art. 21(2)(d)
    addresses
    moderate
    direct

    Hardware/firmware corruption frequently originates with component or IP-block suppliers (boot ROMs, vendor MCUs, FPGA cores); Art. 21(2)(d)'s supplier-relationship security obligation governs that trust framework.

  • nis2Art. 21(2)(e)
    addresses
    high
    direct

    Firmware images, programmable-logic bitstreams, and configuration blobs in non-volatile memory are squarely within Art. 21(2)(e)'s network-and-information-systems acquisition/development/maintenance and vulnerability-handling obligation — particularly the disclosure of below-OS weaknesses traditional endpoint tooling misses.

  • nis2Art. 21(3)
    addresses
    high
    derived

    Primary mapping to Art. 21(2)(d) addresses the supplier of the affected hardware/firmware. Art. 21(3) procedurally extends that to assessment of the supplier's secure-development practices and known vulnerabilities, since hardware/firmware corruption typically exploits weaknesses introduced during the supplier's manufacturing or build pipeline.

  • nis2-implAnnex 5.1.1
    addresses
    high
    derived

    Hardware/firmware corruption rides through the supplier relationship that produces the affected component; the supply-chain policy is the procedural mechanism that scopes the verification regime applied at delivery.

  • nis2-implAnnex 6.10.1
    addresses
    moderate
    derived

    Vulnerability-handling obligations require the entity to obtain information about hardware/firmware vulnerabilities and act on them, which shrinks the dwell time for exploitation through hardware/firmware corruption paths.

  • nis2-implAnnex 6.2.1
    addresses
    moderate
    derived

    Firmware updates and programmable-logic bitstreams produced internally are governed by the secure-development life cycle; outsourced firmware development inherits the same rules under Annex 6.2.3.

ENISA controls

  • ENISA-STL-2025-03-sD.23-i02
    addresses
    moderate

    Anti-counterfeit hardware including tamper resistance reduces the surface for hardware-based corruption of firmware and configuration blobs.

  • ENISA-STL-2025-03-sD.25-i06
    addresses
    moderate

    Software/firmware updates with regression testing close the corruption windows EX-0005 leverages once vulnerabilities are identified.

  • ENISA-STL-2025-03-sD.25-i10
    addresses
    high

    Integrity checks on firmware, bitstreams, and programmable-logic images detect corruption of trust anchors below the application stack.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, EX-0005 (SPARTA v3.2).

Built 2026-07-25 from 216 techniques, 334 regulation articles, 125 ENISA controls, 2,610 framework controls, and 90 countermeasures.