Denial

Denial — exhausting system resources, degrading subsystems, or blocking communications entirely — is the canonical denial-of-service case (2)(h)'s resilience and DoS-mitigation obligation directly addresses.

Resource-exhaustion denial can spread to neighboring systems via crosslink saturation; (2)(i)'s minimize-negative-impact-on-other-services obligation contributes to scope-limited denial behavior.

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

Denial that eliminates the availability of important functions meets the 14(5)(a) severe-incident threshold; the manufacturer must notify CSIRT-coordinator and ENISA per 14(3).

Denial severe-incident notification (primary mapping: Art. 14(3)) cascades to (14)(4)'s timing schedule.

Denial severe incidents (primary mapping: Art. 14(3)) may justify delayed notification while attacker activity is still active on other potentially-affected products; (14)(9) governs.

Denial — exhausting system resources or blocking communications — is mitigated by 86(1)'s backup-management policy enabling restoration with minimum downtime.

86(3)'s redundancies-of-relevant-components clause (with geographical splitting under (b)) is the operator-side resilience anchor against denial scenarios.

87(3)(f) explicitly covers interferences on the ground segment as a crisis-management scenario — denial is the primary case.

Denial significant-incident reporting (primary: Art. 93(6)) cascades to 93(3) — NIS2-routed reporting via CSIRTs applies for essential-entity space operators.

Denial reporting (primary: Art. 93(6)) relates to 93(4) — NIS2/CER coordination ensures parallel notifications are not waived.

Denial that eliminates space-mission services meets the 93(6) significant-incident threshold and triggers manufacturer notification obligations.

Denial significant-incident reporting (primary: Art. 93(6)) cascades to 93(7)'s timing schedule.

Denial reporting (primary: Art. 93(6)) relates to 93(8) — implementing-acts content/template requirements govern the report-format under the 93(7) timing.

Outright denial of service to ground controllers (resource exhaustion, subsystem degradation, full communications block) is the canonical availability incident incident-handling under Art. 21(2)(b) covers.

Business continuity, backup management, disaster recovery, and crisis management under Art. 21(2)(c) are precisely the controls that bound the mission impact of a denial event.

Denial of access to the victim spacecraft is severe operational disruption per Art. 23(3)(a); Art. 23(1) reporting (24h early warning, 72h notification) applies.

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

Primary mapping to Art. 23(1) treats denial as significant. Art. 23(3) significance test is met directly by the operational-disruption criterion (denial blocks ground-controller access entirely); cross-border impact applies when the denied service spans Member States.

Primary mapping to Art. 23(1) drives Art. 23(4) deadlines. Denial is typically observable immediately; the 24-hour early warning starts at detection.

Denial is observable through operator-noticed loss of access; Annex 3.3.1 mechanism captures employee-side denial reports that complement automated link-margin detection.

Denial events trigger Annex 3.4.1 assessment before Annex 3.5.1 response — identifying scope and resource exhaustion vector is the assessment-gate output.

Operational assessment for denial events (resource exhaustion, communications blocking) drives Annex 3.5.1 incident-response activation and recovery prioritization.

Incident-response procedures cover containment, eradication and recovery from denial events; the procedures determine the time-to-restore for ground-controller access to the spacecraft.

Post-incident reviews of denial events identify whether redundancy, fail-over or load-shedding designs proved adequate, and what must change.

Improvements driven by denial post-incident review typically extend to backup-and-redundancy hardening and crisis-management procedure refinements.

Annex 3.6.3 planned-interval review of post-incident-review status applies to denial events.

Denial events (resource exhaustion, subsystem degradation, communications blocking) are exactly the class of temporary access loss that business-continuity-and-disaster-recovery plans must address per the implementing regulation.

Primary mapping to Annex 4.1.1 (BCDR plan) implies the test-cadence obligation: Annex 4.1.4 requires planned-interval testing of continuity plans so they are operationally viable when denial events occur.

Backup-and-redundancy obligations require sufficient available resources, including facilities, to restore service after denial events; redundancy is the procedural lever that converts denial from outage into degraded-but-available operation.

Incident Recovery Plan defines the recovery sequence when communications are denied entirely, including roles and responsibilities of stakeholders.

Critical Services Delivery Requirements with autonomous-operation criteria and recovery-time targets directly cover the denial use case IMP-0003 inflicts.

Capacity-planning measures (high-availability networks, load balancers, redundant frequencies, hot-swaps) explicitly cover the system-resource-exhaustion variant of IMP-0003.

Geographically distributed redundant facilities provide alternate command and telemetry paths when one site is denied.

Denial via service stop (halting spacecraft service availability) is the direct match between SPARTA IMP-0003 'Denial' and T1489 'Service Stop'; both eliminate use/access without physical damage. Tactic and activity align.

T1498 'Network Denial of Service' covers network-level denial via resource exhaustion (bandwidth, channel capacity); SPARTA IMP-0003 'Denial' includes network-DoS-style total denial as one of its modes. Tactic-aligned but moderate because IMP-0003's scope extends beyond network DoS.

T0826 'Loss of Availability' is in MITRE ICS impact tactic and addresses adversary actions causing unavailability of system/process resources; SPARTA IMP-0003 'Denial' (deny access entirely) is the parent-level spacecraft equivalent. Tactic and activity align directly; T0826 is the broadest availability-loss impact technique applicable.

Denial of mission service is an intentional disruption in the practice's own terms, and recovery planning is the response the practice mandates.

CP-10 mitigates IMP-0003 by enabling reconstitution of denied mission services.

CP-13 addresses alternative security mechanisms during denial conditions.

CP-2 addresses mission-continuity planning whose enforcement limits IMP-0003 denial impact.

CP-9 (System Backup) mitigates IMP-0003 by preserving recovery sources when adversary denies access to live state.

IR-4 mitigates IMP-0003 by detecting and responding to denial indicators.

T1489 'Service Stop' covers interrupting services, disabling them, or taking control over them — direct match to IMP-0003's denial of access through subsystem degradation or communication blocking.

T2027 'Permanent loss to telecommand satellite' is the direct cross-framework counterpart of IMP-0003 Denial — both describe attacker actions that eliminate access to or operation of the spacecraft, contrasted with temporary disruption.