safemode.space
← All techniques
DE-0005
ST0006Defense Evasion

Subvert Protections via Safe-Mode

Description

The adversary exploits the spacecraft’s recovery posture to bypass controls that are stricter in nominal operations. During safe-mode, vehicles often accept contingency dictionaries, relax rate/size and timetag checks, activate alternate receivers or antennas, and emit reduced or summary telemetry. By timing actions to this state, or deliberately inducing it, the attacker issues maintenance-looking edits, loads, or mode changes that proceed under broadened acceptance while downlink visibility is thinned. Unauthorized activity blends with anomaly response, evading both automated safeguards and operator suspicion.

Mappings

EU regulation articles

  • craAnnex I, Part I, (2)(b)
    addresses
    moderate
    inferred

    Authentication and access-management (2)(d) addresses DE-0005 by maintaining enforcement through safe-mode rather than relaxing acceptance; secure-by-default config (2)(b) bears on the contingency posture but does not block the safe-mode acceptance vector.

  • craAnnex I, Part I, (2)(d)
    addresses
    moderate
    direct

    Issuing maintenance-looking commands under safe-mode's broadened acceptance is an authentication-bypass scenario (2)(d) requires the product's access-management to resist regardless of operating mode.

  • craAnnex I, Part I, (2)(k)
    addresses
    moderate
    inferred

    CRA Annex I (2)(k) incident-impact reduction is domain-relevant but does not mitigate DE-0005, which exploits the recovery/safe-mode posture itself; the harm is blended unauthorised activity under relaxed checks, not an availability impact. The operative control is recovery-posture hardening that preserves checks during contingency. Addresses.

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

    Subvert-protections-via-safe-mode (primary mapping: Annex I, Part I, (2)(k) exploitation mitigation) requires regular tests under (3) of the safe-mode posture itself — only repeated security review validates that contingency dictionaries do not relax authentication beyond intended.

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

    81(3)(c) requires IAM protocols to be tailored to standard operations and emergency situations — safe-mode is the emergency context DE-0005 exploits, and the obligation forbids unbounded relaxation.

  • 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

    Subvert-protections-via-safe-mode (primary: Art. 87(2) BCDR) cascades to 87(4) — staff implementing safe-mode recovery procedures must be trained to recognize attacker exploitation of safing posture.

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

    Contingency-mode design — what command sets are accepted, what rate/size limits change, what alternate receivers activate — falls under business-continuity 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 exploitation of a relaxed safe-mode acceptance posture; the operative control is recovery-posture hardening that preserves checks during contingency, not cryptography. Addresses (domain relevance).

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

    DE-0005 exploits safe-mode relaxed authentication, timetag screening and interlocks to get maintenance-looking commands accepted; NIS2 21(2)(i) access control policies govern keeping 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; relaxation of MFA in contingency operations creates exactly the protection-subversion window this technique exploits.

  • nis2-implAnnex 3.2.1
    addresses
    high
    derived

    Monitoring-and-logging must run continuously across mode transitions; safe-mode is precisely where reduced visibility creates the protection-subversion opportunity, and the implementing regulation does not exempt it.

  • nis2-implAnnex 6.4.1
    addresses
    moderate
    derived

    Safe-mode profiles, contingency dictionaries and relaxed-check parameters are change-managed configuration; documented procedures must govern their definition and ensure the entry/exit transitions do not become evasion windows.

ENISA controls

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

    Cybersecurity-safe-mode design mandates authentication and encryption persist in safe-mode and that integrity-protected configurations are unmodifiable.

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

    Secure command modes — geographic, temporal, and special operational restrictions — limit the broadened command acceptance DE-0005 abuses.

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

    Authentication on every commanding session is uniformly enforced regardless of safe-mode state.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, DE-0005 (SPARTA v3.2).

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