safemode.space
← All techniques
EX-0005.01
ST0004Execution
sub-technique

Design Flaws

Parent: EX-0005

Description

Threat actors may exploit inherent properties or errata in the hardware/logic design rather than injecting new code. Levers include undocumented or weakly specified behaviors (scan chains, test modes, debug straps), counter/timer rollovers and wraparound, interrupt storms and priority inversions, MMU/TLB corner cases, DMA engines that can write outside intended buffers, and bus arbitration or clock-domain crossing issues that permit stale or reordered writes. RNGs and crypto accelerators with flawed seeding or side-channel leakage can expose secrets or enable predictable authentication values. In programmable logic, vulnerable state machines, insufficient reset paths, and hazardous partial-reconfiguration regions create opportunities to drive the design into privileged or undefined states. Even reliability features can be turned: hardware timers intended for liveness can be paced to starve control loops; ECC policies can be nudged so correction conceals attacker-induced drift. The common thread is using the platform’s own guarantees, timing, priority, persistence, or fault handling, to cause privileged behavior that the software stack accepts as “by design.”

Mappings

EU regulation articles

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

    Manufacturer obligation to identify and document vulnerabilities in components covers design flaws and errata in supplied silicon, board and programmable logic.

  • craAnnex I, Part II, (2)
    addresses
    high
    derived

    Address-and-remediate-without-delay obligations apply to design-flaw findings; manufacturers must close design-flaw exploitation paths under documented vulnerability handling.

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

    Hardware-supply-chain backdoor exploitation (primary mappings: Part II, (1) + Part II, (2) + Art. 13(2)) creates a vulnerability-handling cascade where (5)'s CVD policy is the inbound channel for hardware-related vulnerability reports.

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

    Hardware supply-chain backdoor exploitation (primary mapping: Part II, (2)) cascades to (8) — once a remediating update exists, the manufacturer must disseminate it without delay.

  • craArt. 13(2)
    addresses
    moderate
    derived

    Manufacturer cybersecurity-risk assessment obligations cover identification of design-flaw classes and their exploitation potential; the assessment is the upstream input to design-flaw remediation prioritisation.

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

    Hardware-design-flaw exploitation (primary: Art. 88(1)) requires periodic effectiveness assessment per 76(6) of test-coverage against design-flaw classes.

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

    Hardware design-flaw exploitation depends on errata and undocumented behaviors that 78(1)(c) requires the operator to identify as cybersecurity vulnerabilities — the precise discipline that surfaces these flaws.

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

    88(1)'s testing programme can include hardware-design fuzzing, scan-chain testing, and FPGA partial-reconfig validation — surfacing the design-flaw classes EX-0005.01 enumerates.

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

    Hardware-design-flaw exploitation (primary: Art. 88(1)) cascades to 88(3) — pre-launch + 3-yearly TLPT is the cadence at which design-flaw classes are stressed by external testers.

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

    Design flaws originate at hardware and IP-block suppliers; Art. 21(2)(d)'s supplier-relationship security obligation governs how the entity tracks supplier errata and disclosure cadence.

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

    Errata, undocumented test modes, and counter/timer rollovers are exactly the kind of disclosed-or-disclosable weaknesses Art. 21(2)(e)'s vulnerability handling and disclosure obligation requires the entity to track and remediate within its N+IS dev/maintenance posture.

  • nis2Art. 21(3)
    addresses
    high
    derived

    Primary mapping to Art. 21(2)(d) covers the upstream silicon/board vendor. Art. 21(3) procedurally extends to assessment of the supplier's secure-design practices, since design flaws are introduced by suppliers and must be evaluated as part of supplier-quality scrutiny rather than only at the entity's integration boundary.

  • nis2-implAnnex 5.1.1
    addresses
    high
    derived

    Design flaws and errata enter through the supplier of the affected silicon, board or programmable logic; the supply-chain policy frames the security expectations on supplier-disclosed errata and supplier-conducted design review.

  • nis2-implAnnex 6.10.1
    addresses
    high
    derived

    Vulnerability-handling and disclosure procedures require the entity to monitor design errata, evaluate impact and remediate or compensate; this is the procedural lever for design-flaw exploitation paths.

ENISA controls

  • ENISA-STL-2025-03-sD.20-i01
    addresses
    high

    Threat modelling and vulnerability assessment surface design flaws — undocumented behaviors, race conditions, hazardous partial-reconfig regions — before they ship.

  • ENISA-STL-2025-03-sD.21-i03
    addresses
    high

    A documented secure development lifecycle is the engineering discipline through which design flaws (test modes, debug straps, MMU corner cases) are identified and removed.

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

    Vulnerability management identifies, validates, and records design-flaw exposures with a defined disclosure-and-remediation process.

Cross-reference controls

SPARTA countermeasures

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

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