safemode.space
← All techniques
IA-0007.01
ST0003Initial Access
sub-technique

Compromise On-Orbit Update

Parent: IA-0007

Description

Adversaries may target the pipeline that produces and transmits updates to an on-orbit vehicle. Manipulation points include source repositories and configuration tables, build and packaging steps that generate images or differential patches, staging areas on ground servers, update metadata (versions, counters, manifests), and the transmission process itself. Spacecraft updates span flight software patches, FPGA bitstreams, bootloader or device firmware loads, and operational data products such as command tables, ephemerides, and calibration files, each with distinct formats, framing, and acceptance rules. An attacker positioned in the ground system can substitute or modify an artifact, alter its timing and timetags to match pass windows, and queue it through the same procedures operators use for nominal maintenance. Activation can be immediate or deferred: implants may lie dormant until a specific mode, safing entry, or table index is referenced.

Mappings

EU regulation articles

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

    Manufacturer obligation to ensure vulnerabilities can be addressed through security updates implies the integrity of the update mechanism itself; subverting the update path defeats the (2)(c) obligation, so manufacturers must protect that mechanism.

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

    Malicious commands during software/firmware update (primary mappings: Part II, (7) + Art. 13(8)) presupposes a CVD process under (5) to receive reports of update-channel exploitation.

  • craAnnex I, Part II, (7)
    addresses
    high
    derived

    Manufacturer obligation to provide secure update-distribution mechanisms is precisely the defense against on-orbit update pipeline manipulation: signed, integrity-verified update channels resist source-tree manipulation, build-step subversion and packaging tampering.

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

    Malicious commands during firmware update (primary mappings: Part I, (2)(c) + Part II, (7)) cascade to (8) — once corrective updates exist, timely dissemination is the operational obligation.

  • craArt. 13(8)
    addresses
    moderate
    derived

    Manufacturer obligation to provide security updates throughout the support period extends to the trustworthiness of the on-orbit update production and delivery pipeline.

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

    Update-pipeline manipulation requires access to source repositories, build steps, staging areas, and update metadata — all governed by 81(1)'s IAM protocols.

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

    On-orbit-update pipeline compromise (primary: Art. 81(1)) cascades to 81(4) — pipeline-credential audit is part of credential lifecycle.

  • eu-space-actArt. 85(1)
    addresses
    high
    direct

    Update-image authentication relies on cryptographic signing — 85(1)'s cryptographic concept must cover signed-update verification end-to-end from build to flight.

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

    On-orbit-update pipeline compromise (primary: Art. 85(1) signed updates) cascades to 85(2) — signing-key lifecycle is the operator-side discipline that limits malicious-update insertion.

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

    Build pipelines often involve supplier toolchains; 92(1)'s contractual information-security obligation covers the build-environment security clauses for supplier touchpoints.

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

    IA-0007.01 substitutes or modifies update artefacts in the build, packaging and staging pipeline before transmission to the vehicle; NIS2 21(2)(e) security in acquisition, development and maintenance governs the integrity of this pipeline.

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

    Art. 21(2)(h) requires cryptography policies and procedures covering update integrity and image signing; it addresses compromise of on-orbit updates by mandating those measures, while the deployed image signing, integrity-protected manifests, and monotonic counters, not the policy obligation, are what defeat substitution and rollback.

  • nis2-implAnnex 6.2.1
    addresses
    high
    derived

    Source repositories, build steps and packaging tooling for flight-software updates live inside the secure-development life cycle, with explicit rules on how artefacts are produced and protected from manipulation.

  • nis2-implAnnex 6.4.1
    addresses
    high
    direct

    On-orbit update production is a change-management process; the implementing regulation requires the entity to apply documented procedures to control changes, including releases, modifications and emergency builds for flight software, configuration tables and ephemerides.

  • nis2-implAnnex 6.6.1
    addresses
    high
    derived

    Security-patch management procedures govern how security updates are produced, signed and deployed to flight assets; they are the procedural envelope around the on-orbit update pipeline.

ENISA controls

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

    Documented change-management with configuration change control governs the staging and queuing steps where IA-0007.01 substitutes artefacts.

  • ENISA-STL-2025-03-sD.23-i11
    addresses
    high

    Cryptography and key management on signing keys denies forging an update package without the key, but IA-0007.01's dominant scope is pre-signing pipeline compromise: substituting or modifying artifacts at source repositories, build and packaging steps, and staging areas, which are then signed and promoted through normal procedures. Crypto does not reach the dominant pre-signing scope, so the relationship is addresses.

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

    Software-update procedures with regression testing cover the on-orbit update pipeline IA-0007.01 manipulates between source and transmission.

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

    Integrity-checking mechanisms validate mission software, programmable-logic, and firmware images, the artefacts IA-0007.01 substitutes.

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

    Hash-sum integrity and supplier audits on the update pipeline detect substitution of images, differential patches, and update metadata.

Cross-reference controls

SPARTA countermeasures

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

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