All techniques
LM-0006.01
ST0007Lateral Movement
sub-technique

Rideshare Payload

Parent: LM-0006

Description

In shared launches, multiple independent payloads cohabit common infrastructure until separation. If isolation is incomplete (e.g., shared data buses, mispartitioned deployer controllers, common logging/telemetry collectors, or cross-connected laptops and recorders), a compromise in one payload’s domain can be leveraged to observe or influence another’s traffic before release. Threat actors exploit these transient but real connections to read configuration, pivot through deployer control paths, or stage data/commands that execute as neighboring payloads power and check out, enabling cross-payload access or tampering prior to independent flight.

Mappings

EU regulation articles

  • craAnnex I, Part I, (2)(j)
    addresses
    high
    direct

    Shared data buses, deployer controllers, and common logging collectors used by rideshare neighbors are the precise multi-tenant attack surface (2)(j)'s limit-attack-surfaces obligation requires payload manufacturers to constrain via isolation.

  • craArt. 13(2)
    addresses
    moderate
    direct

    Rideshare deployment is part of the 'reasonably foreseeable use' and 'conditions of use' the manufacturer must consider in the cybersecurity risk assessment under 13(2).

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

    Rideshare neighbors operate under hosted-context-style agreements; 91(3)'s pre-defined-agreements clause governs how cross-payload incidents are coordinated.

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

    Rideshare deployment involves shared launch infrastructure — the canonical multi-tenant supplier scenario 92(1)'s contractual information-security obligations cover.

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

    Rideshare partner operators co-resident on the launch infrastructure are direct service providers; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework around shared deployer controllers, common logging/telemetry collectors, and cross-connected lab assets.

  • nis2Art. 21(3)
    addresses
    high
    direct

    Rideshare-partner isolation maturity (data-bus partitioning, deployer-controller segmentation, common-logger boundaries) varies by partner; Art. 21(3) requires the entity to take those partner-specific vulnerabilities into account when its payload shares infrastructure pre-separation.

  • nis2-implAnnex 5.1.1
    addresses
    high
    derived

    Rideshare cohabitants and deployer operators are direct suppliers under the supply-chain policy; the policy governs the security expectations imposed on shared infrastructure across rideshare manifest entries.

  • nis2-implAnnex 5.1.6
    addresses
    moderate
    derived

    Rideshare cohabitants and deployer operators require Annex 5.1.6 ongoing monitoring because shared-infrastructure threats are determined by other-payload supplier posture.

  • nis2-implAnnex 5.1.7
    addresses
    moderate
    derived

    Annex 5.1.7 follow-up procedures translate rideshare monitoring signals into deployer-controller isolation and shared-bus protective actions.

  • nis2-implAnnex 6.8.1
    addresses
    high
    derived

    Network segmentation between rideshare payloads (data buses, deployer controllers, telemetry collectors) is the architectural control that the implementing regulation requires to prevent inter-payload pivot before separation.

ENISA controls

  • Third-party risk management covers co-payload operators whose mispartitioned domains create LM-0006.01's transit pathway.

  • Access-based network segmentation between rideshare payloads' command/data domains denies cross-connected laptop and recorder transit.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, LM-0006.01 (SPARTA v3.2).

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