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
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.
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.
Destruction severe-incident notification (primary mapping: Art. 14(3)) follows the format and procedures specified by (14)(10)'s implementing acts.
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.
Destruction severe-incident notification (primary mapping: Art. 14(3)) cascades to (14)(4)'s timing schedule — destruction is the most severe availability/integrity case.
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.
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.
Destruction (kinetic or cyber-induced) is mitigated only through redundancy — 86(3)'s redundancies and geographical-splitting clause limits per-strike mission impact.
87(2)'s response-and-recovery plans cover the operator's discipline in re-establishing mission service after destruction of an asset.
Destruction recovery (primary: Art. 87(2) BCDR) cascades to 87(4) — staff implementing post-destruction recovery (failover, asset replacement) need role-specific training.
Destruction significant-incident reporting (primary: Art. 93(6)) cascades to 93(3) — NIS2-routed reporting via CSIRTs applies.
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.
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.
Destruction reporting (primary: Art. 93(6)) cascades to 93(7) — early-warning within 12h is required for Union-owned destroyed assets.
Destruction reporting (primary: Art. 93(6)) relates to 93(8) — implementing-acts govern report content for severe destruction events.
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.
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.
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.
Primary mapping to Art. 23(1) treats destruction as a significant incident. Art. 23(2) timing applies once Art. 23(1) is triggered.
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.
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.
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.
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.
Operational assessment for destruction events evaluates whether mission services are recoverable from backups or whether crisis-management activation is required.
Incident-response procedures govern containment of cascading destruction (preventing wiper variants from reaching backup systems) and recovery actions once the destructive scope is bounded.
Post-incident review of destruction events is the highest-priority class — identifying root cause and propagation path is essential for cross-mission lessons learned.
Improvements driven by destruction-event post-incident reviews typically span backup integrity, segmentation hardening and crisis-management procedure refinements.
Annex 3.6.3 planned-interval tracking ensures destruction events do not slip the post-incident-review schedule.
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.
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
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.
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).
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.
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.
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.
CP-10 mitigates IMP-0005 by enabling reconstitution from clean state after destruction.
CP-13 addresses alternative security mechanisms during destruction-induced asset loss.
CP-2 addresses mission-continuity planning whose enforcement limits IMP-0005 destruction impact.
CP-9 mitigates IMP-0005 by preserving backups that survive deliberate destruction.
IR-4 mitigates IMP-0005 by detecting and responding to destruction indicators.
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.
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).