All techniques
IA-0005.02
ST0003Initial Access
sub-technique

Docked Vehicle / OSAM

Parent: IA-0005

Description

Docking, berthing, or service capture during on-orbit servicing, assembly, and manufacturing (OSAM) creates a high-trust bridge between vehicles. Threat actors exploit this moment, either by pre-positioning code on a servicing vehicle or by manipulating ground updates to it, so that, once docked, lateral movement occurs across the mechanical/electrical interface. Interfaces may expose power and data umbilicals, standardized payload ports, or gateways into the target’s C&DH or payload networks (e.g., SpaceWire, Ethernet, 1553). Service tools that push firmware, load tables, transfer files, or share time/ephemeris become conduits for staged procedures or implants that execute under maintenance authority. Malware can be timed to activation triggers such as “link up,” “maintenance mode entered,” or specific device enumerations that only appear when docked. Because OSAM operations are scheduled and well-documented, the adversary can align preparation with published timelines, ensuring that the first point of execution coincides with the brief window when cross-vehicle trust is intentionally elevated.

Mappings

EU regulation articles

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

    Authentication obligations apply to docking/berthing interfaces; the product must enforce mutual authentication on rendezvous-permission, capture-permission and post-dock command exchanges.

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

    81(3)(b)'s restriction-of-access-to-critical-functions obligation governs which docking-interface tooling can write to bus gateways or push firmware loads.

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

    Docking/OSAM interfaces that push firmware, load tables, or transfer files are controlled-system interfaces under 84(3) — only-authorized-devices governance must apply at the mechanical/electrical bridge.

  • eu-space-actArt. 91(3)
    addresses
    low
    direct

    OSAM service vehicles are typically third-party hosted-service contexts; 91(3)'s pre-defined-agreements-with-third-party-entities clause governs the coordination/discipline at docking interfaces.

  • nis2Art. 21(2)(b)
    addresses
    moderate
    derived

    Anomalous file transfers, firmware loads, or table edits crossing the docking interface during a maintenance window are detectable incidents the entity's incident-handling capability under Art. 21(2)(b) must surface from cross-vehicle audit trails.

  • nis2Art. 21(2)(d)
    addresses
    high
    direct

    OSAM/servicing vehicle operators are direct service providers connecting via high-trust mechanical/electrical interfaces; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework, key management, and procedure separation across the dock.

  • nis2Art. 21(3)
    addresses
    moderate
    direct

    Servicing-vehicle operator's segmentation, key-loading discipline, and procedure rigour vary by supplier; Art. 21(3) requires the entity to take those supplier-specific vulnerabilities into account when authorising OSAM contact.

  • nis2-implAnnex 11.6.1
    addresses
    moderate
    derived

    Authentication procedures across OSAM/docking interfaces (rendezvous tokens, capture-permission exchanges, post-dock command channel handshakes) must satisfy the implementing regulation's secure-authentication requirements.

  • nis2-implAnnex 5.1.1
    addresses
    high
    derived

    OSAM servicers, cargo vehicles and visiting vehicles are functional suppliers of services delivered through a docking/berthing interface; the supply-chain policy governs how the entity contracts for and verifies the security posture of these counterparties.

ENISA controls

  • Third-party risk management is the operator-side discipline that vets the servicer organisation whose vehicle docks via this technique.

  • OSAM dual authorization mandates multi-factor authentication of the servicer by both the serviced ground station and the serviced asset, the named defense for docked-vehicle compromise.

Cross-reference controls

SPARTA countermeasures

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

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