safemode.space
← All techniques
EX-0011
ST0004Execution

Exploit Reduced Protections During Safe-Mode

Description

The adversary times on-board actions to the period when the vehicle is in safe-mode and operating with altered guardrails. In many designs, safe-mode enables contingency command dictionaries, activates alternate receivers or antennas, reduces data rates, and prioritizes survival behaviors (sun-pointing, thermal/power conservation). Authentication checks, anti-replay windows, rate/size limits, and interlocks may differ from nominal; counters can be reset, timetag screening relaxed, or maintenance procedures made available for recovery. Ground cadence also changes, longer passes, emergency scheduling, atypical station selection, creating predictable windows for interaction. Using knowledge of these patterns, an attacker issues maintenance-looking loads, recovery scripts, parameter edits, or boot/patch sequences that the spacecraft is primed to accept while safed. Because responses (telemetry beacons, acknowledgments, mode bits) resemble normal anomaly recovery, the first execution event blends with expected behavior, allowing unauthorized reconfiguration, software modification, or state manipulation to occur under the cover of fault response.

Mappings

EU regulation articles

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

    Authentication obligations apply during safe-mode; manufacturer-designed safe-mode profiles must not relax auth requirements that would otherwise be enforced.

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

    Availability-after-incident obligation covers safe-mode windows: manufacturers must design products so essential cybersecurity functions remain enforced even in reduced-functionality contingency states.

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

    81(3)(c)'s requirement that IAM protocols be tailored to standard operations and to emergency situations directly governs the safe-mode authentication discipline EX-0011 exploits.

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

    Art. 87(2)'s response and recovery plans are domain-relevant to safe-mode incidents but govern incident containment, not interdiction of the safe-mode-abuse vector.

  • eu-space-actArt. 87(4)
    addresses
    moderate
    direct

    Safe-mode exploitation (primary: Art. 87(2) BCDR) cascades to 87(4) — operators executing safe-mode recovery must be trained on adversary exploitation patterns of relaxed checks.

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

    Contingency dictionary scope, alternate-receiver activation rules, and emergency-scheduling cadences are squarely within business-continuity, backup-management, and crisis-management practice under Art. 21(2)(c); the obligation requires those procedures not to relax security to gain availability.

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

    Art. 21(2)(h) crypto policy does not interdict timing on-board actions to a relaxed safe-mode window; the operative control is recovery-posture hardening, not cryptography. Addresses (domain relevance).

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

    EX-0011 exploits relaxed authentication and interlocks during safe-mode to get unauthorised commands accepted; NIS2 21(2)(i) access control policies govern keeping command authentication from being improperly relaxed across operating modes.

  • nis2-implAnnex 11.7.1
    addresses
    high
    derived

    Multi-factor authentication on commanding paths must remain enforced during safe-mode operations; contingency commanding does not justify a relaxed authentication regime under the implementing regulation.

  • nis2-implAnnex 3.2.1
    addresses
    moderate
    derived

    Monitoring-and-logging procedures must run continuously across mode transitions; the implementing regulation does not exempt safe-mode windows from log retention and review.

  • nis2-implAnnex 6.7.1
    addresses
    moderate
    derived

    Network-security measures must remain in force across mode transitions; safe-mode does not exempt the entity from network-protection obligations, which is the implementing-regulation lever that closes the reduced-protection window the technique exploits.

ENISA controls

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

    Cybersecurity-safe-mode design mandates that authentication, encryption, and integrity protection persist in safe-mode — the explicit defense against EX-0011's reduced-protections premise.

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

    Secure command modes including geographic, temporal, and special operational restrictions limit the broadened command acceptance EX-0011 exploits during safe-mode windows.

  • ENISA-STL-2025-03-sD.26-i06
    mitigates
    moderate

    Authentication on every command session — including during contingency dictionaries — denies the safe-mode-broader-acceptance pattern EX-0011 relies on.

Cross-reference controls

SPARTA countermeasures

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

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