safemode.space
← All techniques
IA-0010
ST0003Initial Access

Unauthorized Access During Safe-Mode

Description

Adversaries time their first execution to coincide with safe-mode, when the vehicle prioritizes survival and recovery. In many designs, safe-mode reconfigures attitude, reduces payload activity, lowers data rates, and enables contingency dictionaries or maintenance procedures that are dormant in nominal operations. Authentication, rate/size limits, command interlocks, and anti-replay handling may differ; some implementations reset counters, relax timetag screening, accept broader command sets, or activate alternate receivers and beacons to improve commandability. Ground behavior also shifts: extended passes, emergency scheduling, and atypical station use create predictable windows. An attacker who understands these patterns can present syntactically valid traffic that aligns with safe-mode expectations, maintenance loads, recovery scripts, table edits, or reboot/patch sequences, so the first accepted action appears consistent with fault recovery rather than intrusion.

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)
    relates to
    high
    direct

    Manufacturer obligation to protect availability of essential and basic functions also after an incident bounds the exploitation window during safe-mode: products must maintain protection mechanisms even in reduced-functionality states.

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

    Art. 76(2)(a)'s ensure-resilience obligation is domain-relevant to safe-mode abuse, but the generic resilience mandate names no mechanism interdicting unauthorised safe-mode access; command authentication on the safe-mode path would be the interdiction.

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

    Safe-mode unauthorized-access risk (primary: Art. 76(2) resilience) is part of the ISMS-managed contingency-mode risk register per 76(5).

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

    81(3)(c) requires identity-and-access-management protocols to be tailored to standard operations and to emergency situations — safe-mode is exactly the emergency case where IA-0010 exploits relaxed checks; 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 unauthorised safe-mode access; authenticated safe-mode commanding would be the interdiction.

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

    Safe-mode unauthorized-access (primary: Art. 87(2) BCDR) cascades to 87(4) — recovery-staff training is the personnel-side counterpart to safe-mode response design.

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

    Contingency-mode design, dictionary scope, and rapid-response procedures are squarely within business-continuity and crisis-management practice under Art. 21(2)(c); the obligation requires those procedures not to weaken security.

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

    Art. 21(2)(h) crypto policy does not interdict initial access timed to a relaxed safe-mode acceptance posture; the operative control is recovery-posture hardening, not cryptography. Addresses (domain relevance).

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

    IA-0010 gains first execution during safe-mode by exploiting relaxed authentication, anti-replay and command-set restrictions; NIS2 21(2)(i) access control policies govern keeping authentication consistent across operating modes.

  • nis2-implAnnex 11.7.1
    addresses
    moderate
    derived

    Multi-factor authentication on commanding paths must remain enforced during safe-mode operations; emergency 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, including during safe-mode windows; the implementing regulation does not exempt reduced-payload or contingency operating regimes 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 is a network-security context where reduced visibility creates the exact opportunity this technique exploits.

ENISA controls

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

    Cyber-safe-mode design mandates that authentication and encryption remain enabled in safe-mode, the precise weakening IA-0010 exploits.

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

    Authentication requirements apply uniformly across nominal and safe-mode states; cryptographic auth on every command denies the safe-mode-broader-acceptance pattern.

  • ENISA-STL-2025-03-sD.26-i10
    addresses
    moderate

    Session-termination rules at end-of-session or after inactivity prevent lingering trusted sessions during the safe-mode handoff window.

Cross-reference controls

SPARTA countermeasures

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

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