safemode.space
← All techniques
PER-0002.01
ST0005Persistence
sub-technique

Hardware Backdoor

Parent: PER-0002

Description

Hardware backdoors leverage properties of the physical design to provide durable, low-visibility reentry. Examples include enabled test/scan chains, manufacturing or boot-strap modes invoked by pins or registers, persistent debug interfaces (JTAG/SWD/UART), undocumented device commands, and logic inserted in FPGA/ASIC designs that activates under specific stimuli. Because these mechanisms sit below or beside flight software, they can grant direct access to buses, memories, or peripheral control even when higher layers appear healthy. Triggers may be electrical (pin states, voltage/clock sequences), protocol-level (special patterns on an instrument link), or environmental/temporal (particular temperature ranges, timing offsets). Once on orbit, such pathways are difficult to remove or reconfigure, allowing the attacker to persist by reusing the same physical entry points whenever conditions are met.

Mappings

EU regulation articles

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

    Component identification at hardware granularity supports lifecycle traceability needed to detect hardware-backdoor classes at delivery and during operations.

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

    Hardware-backdoor persistence (primary mappings: Part II, (1) + Art. 13(5)) requires CVD intake under (5) for receiving hardware-component vulnerability reports relevant to backdoor detection.

  • craArt. 13(5)
    addresses
    high
    derived

    Hardware backdoors enter through silicon, board and firmware suppliers; manufacturer due-diligence on those suppliers is the upstream control on test/scan-chain enablement and bootstrap-mode misuse.

  • eu-space-actArt. 76(6)
    addresses
    moderate
    direct

    Hardware-backdoor detection (primary: Art. 88(1)) requires effectiveness assessment per 76(6) — given the difficulty of test-coverage validation in hardware backdoor scenarios.

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

    Hardware-backdoor detection requires test/scan-chain validation, fuse-state checks, and reverse engineering — within 88(1)'s testing programme scope.

  • eu-space-actArt. 88(3)
    addresses
    moderate
    direct

    Hardware-backdoor testing (primary: Art. 88(1)) cascades to 88(3) — TLPT cadence with hardware-attestation testing surfaces durable backdoors.

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

    Hardware backdoors are typically introduced at supplier or integration stages; 92(1)'s contractual information-security obligation governs supplier-side discipline that limits hardware-backdoor insertion.

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

    Hardware backdoors (test/scan chains, boot-strap modes, persistent JTAG/SWD/UART, FPGA/ASIC inserted logic) originate at hardware suppliers; Art. 21(2)(d)'s supplier-relationship security obligation governs the contractual and technical posture around scan-chain disablement and test-mode hardening.

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

    Hardware-integrity assurance and firmware-level vulnerability handling are part of Art. 21(2)(e)'s network-and-information-systems acquisition/development/maintenance and vulnerability-handling/disclosure obligation.

  • nis2Art. 21(3)
    addresses
    moderate
    direct

    Hardware suppliers vary widely in scan-chain hardening, fuse policy, and FPGA-IP integrity; Art. 21(3) requires the entity to take those supplier-specific vulnerabilities into account when relying on third-party silicon.

  • nis2-implAnnex 12.4.1
    addresses
    moderate
    derived

    Asset-inventory obligations at component granularity (lot, configuration, test history) underpin the lifecycle traceability needed to detect hardware-backdoor classes at delivery and during operations.

  • nis2-implAnnex 5.1.1
    addresses
    high
    derived

    Hardware backdoors enter through suppliers (test/scan-chain enablement, undocumented bootstrap modes, microarchitectural quirks); the supply-chain policy is the procedural mechanism that scopes the verification regime applied at delivery.

  • nis2-implAnnex 5.1.6
    addresses
    high
    derived

    Hardware backdoor planting rides through silicon, board and firmware suppliers; Annex 5.1.6 ongoing monitoring of those suppliers' disclosed errata, supply changes and incident reports is essential for catching backdoors that ship signed and provenance-clean.

  • nis2-implAnnex 5.1.7
    addresses
    moderate
    derived

    Annex 5.1.7 follow-up procedures convert hardware-supplier monitoring signals into lot-screening reinforcement, supplier audit and contractual remediation.

ENISA controls

  • ENISA-STL-2025-03-sD.23-i02
    mitigates
    high

    Anti-counterfeit hardware policies including tamper resistance and protection against malicious hardware are the named defense against hardware-Trojan and FPGA-implant backdoors.

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

    Disabling or removing data connection ports including JTAG/SWD/UART prior to operations directly defeats persistent-debug-interface hardware backdoors.

  • ENISA-STL-2025-03-sD.25-i09
    mitigates
    moderate

    ASIC/FPGA development at accredited trusted foundries reduces opportunities for hardware Trojans embedded as PER-0002.01 backdoors.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, PER-0002.01 (SPARTA v3.2).

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