All techniques
IMP-0005
ST0009Impact

Destruction

Description

Measures designed to permanently eliminate the use of a system, potentially through some physical damage to the system. Threat actors may destroy data, commands, subsystems, or attempt to destroy the victim spacecraft itself. This behavior is different from Degradation, as the individual parts are destroyed rather than put in a position in which they would slowly degrade over time.

Mappings

EU regulation articles

  • craAnnex I, Part I, (2)(f)
    addresses
    moderate
    direct

    Destruction of data, commands, or subsystems via cyber means is unauthorized modification of stored data and configuration, with corruption-reporting requirements; physical destruction is outside CRA scope but cyber destruction is squarely in (2)(f)'s integrity property.

  • craAnnex I, Part I, (2)(h)
    addresses
    moderate
    direct

    Permanent elimination of system use is the most severe availability impact; (2)(h)'s resilience obligation extends to safe-state recovery and mitigation against unrecoverable outcomes.

  • craArt. 14(10)
    relates to
    moderate
    direct

    Destruction severe-incident notification (primary mapping: Art. 14(3)) follows the format and procedures specified by (14)(10)'s implementing acts.

  • craArt. 14(3)
    triggers obligation
    high
    direct

    Destruction of data or functions is a clear severe-incident case under Art. 14(5)(a) — it eliminates availability and may also affect integrity — triggering the manufacturer's 14(3) notification obligations.

  • craArt. 14(4)
    addresses
    moderate
    direct

    Destruction severe-incident notification (primary mapping: Art. 14(3)) cascades to (14)(4)'s timing schedule — destruction is the most severe availability/integrity case.

  • craArt. 14(9)
    relates to
    moderate
    direct

    Destruction severe incidents (primary mapping: Art. 14(3)) may involve sensitive attribution information whose immediate release could compromise investigation; (14)(9)'s delay-grounds framework applies.

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

    82(1)'s physical-resilience obligation (Annex VII point 3 measures) reduces the probability of cyber-induced destruction succeeding by hardening physical and electronic vulnerabilities.

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

    Destruction (kinetic or cyber-induced) is mitigated only through redundancy — 86(3)'s redundancies and geographical-splitting clause limits per-strike mission impact.

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

    87(2)'s response-and-recovery plans cover the operator's discipline in re-establishing mission service after destruction of an asset.

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

    Destruction recovery (primary: Art. 87(2) BCDR) cascades to 87(4) — staff implementing post-destruction recovery (failover, asset replacement) need role-specific training.

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

    Destruction significant-incident reporting (primary: Art. 93(6)) cascades to 93(3) — NIS2-routed reporting via CSIRTs applies.

  • eu-space-actArt. 93(4)
    relates to
    moderate
    direct

    Destruction reporting (primary: Art. 93(6)) relates to 93(4) — significant destruction events likely also trigger NIS2 Art. 23 and possibly CER Art. 15 notifications.

  • eu-space-actArt. 93(6)
    triggers obligation
    high
    direct

    Destruction of mission assets is a clear severe operational disruption under 93(6)(a), triggering 93(1)/(2) reporting via the structure referred to in Art. 34(4) of Regulation (EU) 2021/696 and to competent authorities.

  • eu-space-actArt. 93(7)
    addresses
    high
    direct

    Destruction reporting (primary: Art. 93(6)) cascades to 93(7) — early-warning within 12h is required for Union-owned destroyed assets.

  • eu-space-actArt. 93(8)
    relates to
    moderate
    direct

    Destruction reporting (primary: Art. 93(6)) relates to 93(8) — implementing-acts govern report content for severe destruction events.

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

    Destruction of data, commands, subsystems, or the spacecraft itself is the most severe incident class the entity must handle through its incident-handling capability under Art. 21(2)(b), including post-incident analysis and lessons-learned distribution.

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

    Backup management, disaster recovery, and crisis management under Art. 21(2)(c) are the obligations that ensure mission continuity (including data recoverability) in the face of destruction-class incidents.

  • nis2Art. 23(1)
    triggers obligation
    high
    direct

    Loss of the spacecraft or major subsystem is a paradigmatic significant incident with cross-border impact (mission services frequently span Member States); Art. 23(1) notification applies.

  • nis2Art. 23(2)
    addresses
    high
    derived

    Primary mapping to Art. 23(1) treats destruction as a significant incident. Art. 23(2) timing applies once Art. 23(1) is triggered.

  • nis2Art. 23(3)
    relates to
    moderate
    derived

    Primary mapping to Art. 23(1) treats destruction as significant. Art. 23(3) significance test is met directly by the considerable-damage and operational-disruption criteria; cross-border impact applies when the destroyed asset served multi-Member-State users.

  • nis2Art. 23(4)
    addresses
    high
    derived

    Primary mapping to Art. 23(1) drives Art. 23(4) deadlines. Destruction is typically observable near-instantly via lost telemetry; the 24-hour clock starts at confirmation.

  • nis2-implAnnex 3.3.1
    addresses
    moderate
    derived

    Destruction is operator-visible (lost telemetry, missing assets); Annex 3.3.1 mechanism captures rapid employee escalation that feeds 3.4 assessment ahead of mission-impact analysis.

  • nis2-implAnnex 3.4.1
    addresses
    moderate
    derived

    Destruction events require the most stringent assessment under Annex 3.4.1 — scope, recoverability and crisis-management activation thresholds drive Annex 3.5.1 response.

  • nis2-implAnnex 3.4.2
    addresses
    moderate
    derived

    Operational assessment for destruction events evaluates whether mission services are recoverable from backups or whether crisis-management activation is required.

  • nis2-implAnnex 3.5.1
    addresses
    moderate
    derived

    Incident-response procedures govern containment of cascading destruction (preventing wiper variants from reaching backup systems) and recovery actions once the destructive scope is bounded.

  • nis2-implAnnex 3.6.1
    addresses
    moderate
    derived

    Post-incident review of destruction events is the highest-priority class — identifying root cause and propagation path is essential for cross-mission lessons learned.

  • nis2-implAnnex 3.6.2
    addresses
    moderate
    derived

    Improvements driven by destruction-event post-incident reviews typically span backup integrity, segmentation hardening and crisis-management procedure refinements.

  • nis2-implAnnex 3.6.3
    addresses
    moderate
    derived

    Annex 3.6.3 planned-interval tracking ensures destruction events do not slip the post-incident-review schedule.

  • nis2-implAnnex 4.2.1
    addresses
    high
    derived

    Backup-and-redundancy obligations are the principal recovery lever for destruction events affecting data, commands or subsystem state; backups are the difference between recoverable destruction and total loss.

  • nis2-implAnnex 4.3.1
    addresses
    high
    derived

    Crisis-management procedures cover destruction events whose impact exceeds the routine incident-response scope; spacecraft destruction is the canonical case for crisis-management activation.

ENISA controls

  • Tested backups with verified integrity provide the recovery path when data and commands are destroyed.

  • Incident Recovery Plan including drills tests staff capability to respond to destruction events — the operator-side discipline for IMP-0005 response.

  • Critical Services Delivery Requirements with autonomous-operation criteria cover degraded operation following destruction of individual elements.

  • System redundancy across ground-segment facilities and key/code material preserves mission viability when individual subsystems are destroyed.

  • Protective technology — failsafe systems, load balancing, hot swapping — meets resilience requirements under destruction-class adverse conditions.

Cross-reference controls

  • mitre-attack-enterpriseT1485Data Destruction
    addresses
    high

    T1485 'Data Destruction' is the impact-tactic technique for permanently eliminating data; SPARTA IMP-0005 'Destruction' is the parent-level spacecraft equivalent (permanently eliminate use through destruction of data, commands, subsystems, or the spacecraft itself). Tactic and activity align directly.

  • mitre-attack-enterpriseT1495Firmware Corruption
    addresses
    moderate

    T1495 'Firmware Corruption' covers permanent firmware-level damage that renders devices inoperable; SPARTA IMP-0005 'Destruction' includes firmware/component destruction as a destruction mode. Tactic-aligned moderate (T1485 is the dominant primary anchor for total destruction).

  • mitre-attack-icsT0809Data Destruction
    addresses
    moderate

    T0809 'Data Destruction' addresses adversary destruction of data; SPARTA IMP-0005 'Destruction' includes destruction of mission data (recorder contents, telemetry archives, payload products) as one mode. Cross-tactic moderate (T0809 in inhibit-response-function vs SPARTA IMP-0005 impact); complementary to T0879's primary property-damage anchor.

  • mitre-attack-icsT0879Damage to Property
    addresses
    high

    T0879 'Damage to Property' is the impact-tactic ATT&CK ICS technique for permanent property/equipment damage; SPARTA IMP-0005 'Destruction' (permanent total loss including spacecraft destruction) maps directly. Tactic and activity align.

  • nasa-bpgMI-MA-01Mission Recovery Function
    addresses
    moderate

    Destruction is deliberately typed below its sibling impact techniques: recovery planning cannot restore a destroyed vehicle, so the practice governs the mission's preparation for the loss rather than recovering from the technique.

  • nist-80053-rev5CP-10System Recovery and Reconstitution
    addresses
    moderate

    CP-10 mitigates IMP-0005 by enabling reconstitution from clean state after destruction.

  • nist-80053-rev5CP-13Alternative Security Mechanisms
    addresses
    moderate

    CP-13 addresses alternative security mechanisms during destruction-induced asset loss.

  • nist-80053-rev5CP-2Contingency Plan
    addresses
    moderate

    CP-2 addresses mission-continuity planning whose enforcement limits IMP-0005 destruction impact.

  • nist-80053-rev5CP-9System Backup
    addresses
    moderate

    CP-9 mitigates IMP-0005 by preserving backups that survive deliberate destruction.

  • nist-80053-rev5IR-4Incident Handling
    addresses
    moderate

    IR-4 mitigates IMP-0005 by detecting and responding to destruction indicators.

  • space-shieldT2028Resource damage
    addresses
    high

    T2028 'Resource damage' parent covers all attempts to damage a space resource to cause mission loss — direct match to IMP-0005 Destruction at the parent level.

  • space-shieldT2028.005Physical sabotage
    addresses
    high

    T2028.005 'Physical sabotage' covers physical damage to satellites including kinetic kill vehicles, RF jammers, lasers, HPM, and robotic mechanisms — direct match to IMP-0005's permanent destruction objectives.

Cite as SafeMode Space, IMP-0005 (SPARTA v3.2).

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