All techniques
IA-0004.02
ST0003Initial Access
sub-technique

Receiver

Parent: IA-0004

Description

Threat actors may target the spacecraft’s secondary (backup) RF receive path, often a differently sourced radio, alternate antenna/feed, or cross-strapped front end that is powered or enabled under specific modes. Threat actors map when the backup comes into play (safing, antenna obscuration, maintenance, link degradation) and what command dictionaries, framing, or authentication it expects. If the backup receiver has distinct waveforms, counters, or vendor defaults, the attacker can inject traffic that is accepted only when that path is active, limiting exposure during nominal ops. Forcing conditions that enable the backup, jamming the primary, exploiting geometry, or waiting for routine tests, creates the window for first execution. The result is a foothold gained through a rarely used RF path, exploiting differences in implementation and operational cadence between primary and standby receive chains.

Mappings

EU regulation articles

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

    Backup on-board receivers must enforce the same authentication mechanisms as the primary path under the manufacturer's product-cybersecurity obligations.

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

    Limited attack surfaces apply to backup receivers; cross-strapped or alternate front ends should be locked down except when actively required.

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

    Secondary on-board receivers must obey 84(3)'s only-authorized-devices-communicate rule even when activated under safing or maintenance modes.

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

    85(3)(a)'s end-to-end-authentication-between-SCC-and-space-segment obligation must extend to backup receive paths to prevent adversary injection on alternate hardware/waveforms.

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

    Backup receiver design — when it activates, what command set it accepts — falls under business-continuity and disaster-recovery design; Art. 21(2)(c) is the obligation that requires the entity to prove its contingency configurations don't relax security to gain availability.

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

    Authentication parity on the backup receive chain interdicts command forgery, and unlike the Sprint D encryption-only ENISA excerpt, NIS2 Art. 21(2)(h) does span authentication, so that earlier ruling does not control here. Even so, under the strict bar the dominant residual is consistent cross-path access control, as for the parent technique IA-0004: cryptography interdicts the forgery vector but not exploitation of the alternate path. The relationship at 21(2)(h) is therefore addresses, the strict bar resolving the item against its own authentication-scope counter.

  • nis2-implAnnex 11.6.1
    addresses
    high
    derived

    Secondary on-board receivers must enforce the same secure-authentication procedures (TC frame MAC, counters) as the primary path; the implementing regulation calibrates authentication strength to asset classification, not to channel role.

  • nis2-implAnnex 6.4.1
    addresses
    moderate
    derived

    Change-management procedures govern when backup receivers are enabled, reconfigured or cross-strapped, which are precisely the moments adversary access via the alternate path is most likely.

ENISA controls

  • Communications security on the backup receiver path preserves the same encryption and authentication posture, denying the differential-acceptance window IA-0004.02 relies on.

  • Cryptography on uplink/downlink is relevant to protecting the backup receive path, but the eavesdropping-prevention excerpt does not actively defend against command exploitation of the backup receiver.

  • Authentication mandates apply to every command path including secondary receivers, defeating differences in vendor defaults that IA-0004.02 exploits.

Cross-reference controls

SPARTA countermeasures

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

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