safemode.space
← All techniques
REC-0001.02
ST0001Reconnaissance
sub-technique

Firmware

Parent: REC-0001

Description

Firmware intelligence covers microcontroller images, programmable logic bitstreams, boot ROM behavior, peripheral configuration blobs, and anti-rollback or secure-boot settings for devices on the bus. Knowing device types, versions, and footprints enables inference of default passwords, debug interfaces (JTAG, SWD, UART), timing tolerances, and error handling under brownout or thermal stress. A threat actor may obtain firmware from vendor reference packages, public evaluation boards, leaked manufacturing files, over-the-air update images, or crash dumps. Correlating that with board layouts, harness drawings, or part markings helps map trust boundaries and locate choke points like power controllers, bus bridges, and watchdog supervisors. Attack goals include: preparing malicious but apparently valid updates, exploiting unsigned or weakly verified images, forcing downgrades, or manipulating configuration fuses to weaken later defenses. Even when cryptographic verification is present, knowledge of recovery modes, boot-pin strapping, or maintenance commands can offer alternate paths.

Mappings

EU regulation articles

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

    Secure-update mechanisms required by Annex I, Part I, (2)(c) constrain the leverage firmware reconnaissance produces: even with extensive firmware knowledge, the adversary cannot deliver patched/altered images without subverting the manufacturer-required update authentication.

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

    Firmware reconnaissance harvests vendor reference packages, evaluation-board firmware and bootstrap materials to construct exploit catalogs. CRA Annex I, Part II, (1) requires manufacturers to identify and document components and vulnerabilities (including via SBOM), which is the upstream discipline that surfaces the same component knowledge to the manufacturer's vulnerability-handling pipeline before adversary recon is converted into operational use.

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

    Eavesdropping on update channels (primary mappings: Part I, (2)(c) + Part II, (1)) is detected and reported via the CVD intake (5) when third parties observe anomalies in the update flow.

  • craAnnex I, Part II, (8)
    addresses
    moderate
    direct

    Eavesdropping on update channels (primary mapping: Part I, (2)(c)) cascades to (8) — the security-update obligation in (2)(c) includes the dissemination-without-delay timing element under (8).

  • eu-space-actArt. 80(3)
    addresses
    high
    direct

    Firmware images, bitstreams, and secure-boot settings are sensitive operator-held artifacts that 80(3)'s information-security categorization must cover.

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

    Firmware comes from supplier manufacturers; 92(1) requires supply-chain contracts to include information-security requirements that govern how vendor reference packages and OTA images are handled.

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

    Firmware reconnaissance leans heavily on vendor reference packages, public evaluation boards, and leaked manufacturing files; supplier-relationship security under Art. 21(2)(d) is the obligation that constrains how those artefacts move between integrators and the entity.

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

    Firmware update images, OTA bundles, secure-boot configuration, and anti-rollback policy live inside the network-and-information-systems development and maintenance pipeline that Art. 21(2)(e) explicitly governs, including handling of disclosed weaknesses in those mechanisms.

  • nis2Art. 21(3)
    addresses
    moderate
    derived

    Primary mapping to Art. 21(2)(d) covers the firmware-vendor relationship that leaks reference packages and evaluation board firmware. Art. 21(3) procedurally extends to assessment of those vendors' secure-handling practices for engineering artefacts, the procedural mechanism that constrains how such artefacts move between integrators.

  • nis2-implAnnex 12.1.1
    addresses
    moderate
    derived

    Firmware images and bootloader configuration are mission-critical assets whose classification level drives the storage, transmission and sharing controls that determine whether reconnaissance can recover them at all.

  • nis2-implAnnex 5.1.1
    addresses
    high
    direct

    Firmware reconnaissance leans heavily on vendor reference packages and leaked manufacturing files; the supply-chain security policy is the procedural mechanism that constrains how those artefacts move between integrators and the entity.

  • nis2-implAnnex 6.2.1
    addresses
    moderate
    derived

    Firmware images, OTA bundles, secure-boot configuration and anti-rollback policy are produced by the entity's network-and-information-systems development pipeline; the secure-development rules govern how those artefacts are stored, signed and protected from disclosure.

ENISA controls

  • ENISA-STL-2025-03-sD.24-i01
    addresses
    moderate

    Information classification and labelling governs the protection of firmware images and bitstreams REC-0001.02 targets, establishing handling rules rather than actively defending against collection.

  • ENISA-STL-2025-03-sD.28-i04
    addresses
    high

    Software supply-chain integrity is relevant to the firmware and supply-chain domain REC-0001.02 targets, but hash-sum tamper-detection does not actively prevent reconnaissance of firmware images and vendor packages, so addresses rather than mitigates.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, REC-0001.02 (SPARTA v3.2).

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