safemode.space
← All techniques
IA-0006
ST0003Initial Access

Compromise Hosted Payload

Description

Adversaries target hosted payloads as an alternate doorway into the host spacecraft. Hosted payloads often expose their own command sets, file services, and telemetry paths, sometimes via the host’s TT&C chain, sometimes through a parallel ground infrastructure under different operational control. Initial access arises when an attacker obtains the ability to issue payload commands, upload files, or alter memory/register state on the hosted unit. Because data and control must traverse an interface to the host bus (power, time, housekeeping, data routing, gateway processors), the payload–host boundary can also carry management functions: mode transitions, table loads, firmware updates, and cross-strapped links that appear only in maintenance or contingency modes. With knowledge of the interface specification and command dictionaries, a threat actor can activate rarely used modes, inject crafted data products, or trigger gateway behaviors that extend influence beyond the payload itself. In multi-tenant or commercial hosting arrangements, differences in keying, procedures, or scheduling between the payload operator and the bus operator provide additional opportunity for a first foothold that looks like routine payload commanding.

Mappings

EU regulation articles

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

    Authentication obligations apply to payload-to-bus command interfaces; the bus should accept payload-originating commands only with manufacturer-defined authentication.

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

    Limited attack surfaces apply to host-bus/payload gateway interfaces; manufacturers must design products to expose minimal trust through these gateways to prevent payload-to-bus pivot.

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

    Exploitation mitigation mechanisms (sandboxing, partition isolation, separation kernels) reduce the impact of payload compromise on host-bus operations.

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

    Regular security tests and reviews of the product would exercise the hosted payload's exposed command sets, file services, and payload-host bus interface, surfacing the rarely-used modes, table-load and firmware-update paths, and unvalidated command channels that this technique exploits for a first foothold. Without that recurring testing discipline, the cross-strapped and contingency-mode behaviors that appear only in maintenance go unprobed and remain available to an attacker who knows the interface specification.

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

    81(3)(b)'s restriction-of-access-to-critical-functions covers the boundary between hosted payload and host bus — limiting the population that can issue payload commands or alter memory across the gateway.

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

    Hosted-payload command sets that traverse the host bus must obey 84(3)'s only-authorized-devices-communicate rule — payload-host gateway processors are the boundary the obligation applies to.

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

    91(3) explicitly governs hosted-payload incident scenarios — 'When a satellite hosts third-party payloads' is the exact context of IA-0006, and the pre-defined-agreements clause shapes the access discipline at the boundary.

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

    Hosted-payload operators are direct service providers sharing the host bus and frequently a parallel ground infrastructure; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework across that boundary.

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

    Hosted-payload command sets, file services, telemetry paths, and gateway processors that bridge to the host bus are the precise asset class Art. 21(2)(i)'s access-control + asset-management obligation governs.

  • nis2Art. 21(3)
    addresses
    moderate
    direct

    Differences in keying, procedures, and scheduling between the payload operator and the bus operator are exactly the supplier-specific vulnerabilities Art. 21(3) requires the entity to consider when hosting third-party payloads.

  • nis2-implAnnex 11.2.1
    addresses
    high
    derived

    Access-rights provisioning between hosted payload and host bus is the operational lever that limits which payload commands the bus accepts and which bus telemetry the payload can read.

  • nis2-implAnnex 5.1.1
    addresses
    moderate
    derived

    The hosted-payload provider is a direct supplier under the supply-chain policy; the policy frames the integration security expectations imposed on payload code, file services and telemetry paths.

  • nis2-implAnnex 5.1.6
    addresses
    high
    derived

    Hosted-payload providers maintain ongoing access via gateway interfaces; Annex 5.1.6 monitoring detects supplier-side incidents and posture changes that would expose the host bus to payload-side compromise.

  • nis2-implAnnex 5.1.7
    addresses
    moderate
    derived

    Annex 5.1.7 reporting and follow-up procedures operationalize hosted-payload provider monitoring, linking supplier signals to host-bus protective actions.

  • nis2-implAnnex 6.8.1
    addresses
    high
    derived

    Network segmentation between hosted payload and host-bus subsystems is the architectural control that prevents payload-to-bus pivot; the implementing regulation requires segmentation based on risk-assessment-driven trust boundaries.

ENISA controls

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

    Third-party risk management governs hosted-payload operator agreements where keying, procedures, and scheduling differ between payload and bus operator.

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

    Least-privilege access control between hosted payload and host-bus management functions denies IA-0006 the cross-strapped pivot it relies on.

Cross-reference controls

SPARTA countermeasures

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

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