safemode.space
← All techniques
IA-0002
ST0003Initial Access

Compromise Software Defined Radio

Description

Adversaries target SDR-based transceivers and payload radios because reconfigurable waveforms, FPGA bitstreams, and software flowgraphs create programmable footholds. Manipulation can occur in the radio’s development pipeline (toolchains, out-of-tree modules), at integration (loading of bitstreams, DSP coefficients, calibration tables), or in service via update channels that deliver new waveforms or patches. On-orbit SDRs often expose control planes (command sets for mode/load/select), data planes (baseband I/Q), and management/telemetry paths, any of which can embed covert behavior, alternate demod paths, or hidden subcarriers. A compromised SDR can establish clandestine command-and-control by activating non-public waveforms, piggybacking on idle fields, or toggling to time/ephemeris-triggered profiles that blend with nominal operations. On the ground, compromised SDR modems can be used to fabricate mission-compatible emissions or to decode protected downlinks for reconnaissance. Attackers leverage the SDR’s malleability so that malicious signaling, once seeded, presents as a legitimate but rarely exercised configuration.

Mappings

EU regulation articles

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

    Manufacturer obligation to ensure vulnerabilities can be addressed through security updates extends to SDR firmware and waveform packages whose remediation cadence determines compromise dwell time.

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

    FPGA bitstreams, software flowgraphs and waveform packages are components that must be enumerated in the manufacturer's component identification under Annex I, Part II, (1).

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

    Compromised software updates initial-access (primary mappings: Part I, (2)(c) + Part II, (1) + Art. 13(5)) places a CVD policy obligation under (5) so update-channel anomalies can be reported and processed.

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

    Compromised-software-update initial-access (primary mapping: Part I, (2)(c) security updates) cascades to (8) — the (2)(c) obligation includes dissemination without delay as the timing element.

  • craArt. 13(5)
    addresses
    high
    derived

    SDR vendors and waveform suppliers fall under manufacturer due-diligence; the integrity expectations on vendor-supplied bitstreams and configuration profiles are part of supplier-integration vetting.

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

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

  • eu-space-actArt. 85(1)
    addresses
    moderate
    inferred

    Art. 85(1)'s cryptographic concept is domain-relevant to SDR-mediated crypto, but the generic concept names no mechanism interdicting SDR compromise itself.

  • eu-space-actArt. 85(2)
    addresses
    moderate
    direct

    SDR compromise (primary: Art. 85(1)) cascades to 85(2) — when SDR compromise touches crypto material, key lifecycle discipline (signed waveform updates, rotation) is the operator-side control.

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

    SDR compromise via the radio's development pipeline is supply-chain attack surface; 92(1)'s contractual obligation extends to SDR vendor relationships and toolchain governance.

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

    SDR vendors and their update-channel operators are direct suppliers; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework through which waveforms and patches arrive.

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

    Toolchains, out-of-tree modules, bitstream loading, and update channels for SDR waveforms are precisely the network-and-information-systems acquisition/development/maintenance pipeline Art. 21(2)(e) governs, including disclosed-vulnerability handling on the SDR stack.

  • nis2Art. 21(2)(h)
    addresses
    moderate
    inferred

    Signed waveform and bitstream profiles defeat rogue DSP and framing loads into the software-defined radio, but they do not cover the broad SDR-compromise scope, including covert command-and-control waveforms that are not cryptographically interdicted, where the operative control is supply-chain and configuration integrity. The CIR (EU) 2024/2690 Annex assigns those to sections 5 and 6 (6.3 configuration management), not to the section 9 cryptography requirements. At NIS2 Art. 21(2)(h) the relationship is addresses.

  • nis2Art. 21(3)
    addresses
    high
    derived

    Primary mapping to Art. 21(2)(d) covers the SDR vendor relationship. Art. 21(3) extends procedurally to assessment of that vendor's secure-build and vulnerability-handling practices, since SDR compromises typically ride trojanized waveform updates or vendor configuration profiles delivered through the supplier channel.

  • nis2-implAnnex 5.1.1
    addresses
    high
    derived

    SDR vendors and waveform suppliers are direct suppliers governed by the supply-chain policy; that policy frames the integrity expectations on vendor-supplied bitstreams, flowgraphs and configuration profiles.

  • nis2-implAnnex 5.1.6
    addresses
    high
    derived

    SDR vendors and waveform suppliers require Annex 5.1.6 ongoing monitoring because reconfigurable radios depend on continuous integrity oversight of vendor-supplied bitstreams and configuration profiles.

  • nis2-implAnnex 5.1.7
    addresses
    moderate
    derived

    Annex 5.1.7 follow-up converts SDR-vendor monitoring signals into bitstream-integrity actions and supplier remediation.

  • nis2-implAnnex 6.2.1
    addresses
    high
    derived

    FPGA bitstreams, software flowgraphs and reconfigurable waveforms are produced through the entity's network-and-information-systems development pipeline; the secure-development rules govern how those artefacts are written, reviewed, signed and verified.

  • nis2-implAnnex 6.4.1
    addresses
    high
    derived

    Change-management procedures govern how SDR firmware, profiles and bitstreams are altered, reviewed and pushed to flight or ground SDRs — the procedural envelope an SDR-compromise adversary must subvert.

  • nis2-implAnnex 6.6.1
    addresses
    moderate
    derived

    Security-patch management for SDR firmware and waveform packages is the lever that closes the SDR-compromise opportunity before it is exploited.

ENISA controls

  • ENISA-STL-2025-03-sD.21-i07
    addresses
    moderate

    Separation of SDR development environments from production deployment limits cross-contamination from compromised toolchains and out-of-tree modules.

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

    A regularly performed, regression-tested update process governs the SDR software and bitstream baseline, but regression testing validates function rather than detecting the malicious waveform or bitstream manipulation IA-0002 uses, so addresses rather than mitigates.

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

    SDR waveforms, bitstreams, and DSP modules ride the same software supply chain whose integrity is governed here, including update-channel hash verification.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, IA-0002 (SPARTA v3.2).

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