All techniques
IA-0012
ST0003Initial Access

Assembly, Test, and Launch Operation Compromise

Description

Assembly, Test, and Launch Operation (ATLO) concentrates people, tools, and authority while components first exchange real traffic across flight interfaces. Test controllers, EGSE, simulators, flatsats, loaders, and data recorders connect to the same buses and command paths that will exist on orbit. Threat actors exploit this density and dynamism: compromised laptops or transient cyber assets push images and tables; lab networks bridge otherwise separate enclaves; vendor support accounts move software between staging and flight hardware; and “golden” artifacts created or modified in ATLO propagate into the as-flown baseline. Malware can traverse shared storage and scripting environments, ride update/checklist execution, or piggyback on protocol translators and gateways used to stimulate subsystems. Because ATLO often introduces late firmware loads, key/counter initialization, configuration freezes, and full-system rehearsals, a single well-placed change can yield first execution on multiple devices and persist into LEOP.

Mappings

EU regulation articles

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

    Limited attack surfaces during AIT-time integration constrain the ingress points adversaries exploit when EGSE, simulators and flatsats touch flight interfaces.

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

    Assembly/test/launch-operation trusted-relationship initial-access (primary mapping: Art. 13(5)) requires SBOM documentation of integrated test-equipment and ATLO-tooling components under (1).

  • craArt. 13(5)
    addresses
    high
    derived

    Manufacturer due-diligence on AIT facility, integrator and pad-side service providers covers exactly the touchpoints where ATLO compromise is introduced.

  • eu-space-actArt. 76(4)
    addresses
    high
    direct

    76(4)(b) explicitly covers manufacturing, assembly, integration, verification, validation, and qualification phases — the ATLO lifecycle stage IA-0012 attacks; risk-management measures must extend through ATLO.

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

    ATLO-stage compromise (primary: Art. 76(4) manufacturing/test phases) is an ISMS-managed lifecycle risk per 76(5).

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

    81(2)'s logical-and-physical-access conditions extend to ATLO lab networks, EGSE workstations, and shared storage — limiting cross-enclave bridging that IA-0012 exploits.

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

    ATLO concentrates supplier touchpoints (test controllers, EGSE, simulators, vendor support); 92(1)'s contractual information-security obligation covers the supplier-density of integration and test sites.

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

    ATLO concentrates multiple suppliers and integrators on shared lab networks (test controllers, EGSE, vendor support accounts, simulators); Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework across that highly mixed environment.

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

    ATLO is the late-stage network-and-information-systems acquisition/development/maintenance phase before flight; Art. 21(2)(e) — including disclosed-vulnerability handling — governs late firmware loads, key/counter initialisation, and configuration freezes that the technique exploits.

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

    Test controllers, EGSE, simulators, flatsats, loaders, and golden artefacts are precisely the asset class Art. 21(2)(i)'s access-control + asset-management obligation governs — including the lab-network bridges between otherwise separate enclaves.

  • nis2Art. 21(3)
    addresses
    high
    derived

    Primary mapping to Art. 21(2)(d) covers the AIT facility and integrator relationships at the launch site. Art. 21(3) procedurally extends to assessment of those suppliers' secure-development and operations practices — the lever applicable to cleanroom operators, EGSE vendors, and pad integrators where ATLO compromises happen.

  • nis2-implAnnex 12.3.1
    addresses
    moderate
    derived

    EGSE-introduced media, simulator-stored test images and flatsat removable storage at AIT all engage the removable-media policy that governs how media flow into integration environments.

  • nis2-implAnnex 13.3.1
    addresses
    high
    derived

    ATLO concentrates personnel, tools and authority at a physical site; perimeter and physical-access control are the implementing-regulation obligations that prevent on-site insertion paths during AIT and pre-launch.

  • nis2-implAnnex 5.1.1
    addresses
    high
    derived

    AIT facilities, integrators and pad-side service providers are direct suppliers under the supply-chain policy; that policy governs the security regime imposed at AIT and during launch operations.

  • nis2-implAnnex 5.1.6
    addresses
    high
    derived

    ATLO suppliers (AIT facility, integrator, pad-side service providers) require Annex 5.1.6 ongoing monitoring because each launch campaign exposes the entity to fresh supplier-side security posture variations.

  • nis2-implAnnex 5.1.7
    addresses
    moderate
    derived

    Annex 5.1.7 reporting and follow-up procedures convert ATLO-supplier monitoring signals into AIT-environment hardening and pre-launch verification actions.

  • nis2-implAnnex 6.4.1
    addresses
    moderate
    derived

    Change-management procedures govern flight-software, configuration table and parameter pushes during AIT and last-minute pad-side updates; ATLO compromises ride exactly that change pipeline.

ENISA controls

  • Third-party risk management governs vendor support accounts and transient assets active during ATLO that move software between staging and flight hardware.

  • Separation of ATLO/test/production environments is the structural defense against the cross-enclave bridges and shared storage IA-0012 exploits.

  • Least-privilege access control on EGSE, simulators, and test controllers denies a compromised laptop the broad reach IA-0012 needs.

  • Intrusion detection and prevention with documented baseline activities surfaces the late firmware loads, key/counter initialisation, and full-system rehearsals IA-0012 abuses.

Cross-reference controls

SPARTA countermeasures

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

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