Annex I, Part I, (2)(h)

Denial-based downlink attacks (disabling telemetry links, crashing telemetry software) target the availability of essential monitoring functions, which (2)(h) requires resilience and DoS-mitigation measures for.

Disabling telemetry software, corrupting processing pipelines, or crashing display interfaces directly attacks the availability of the ground product's essential monitoring functions.

RF jamming itself is environmental and outside CRA's manufacturer scope, but (2)(h) places a positive obligation on the product to maintain availability of essential functions through resilience and DoS mitigation — link-margin design, alternate paths, autonomous-mode fallback partially mitigate jam-induced telemetry loss.

AGC tampering blocks legitimate command reception, attacking the availability of the command-and-control function — the resilience obligation in (2)(h).

Saturating ingestion and alerting with noisy or adversarial inputs is a denial-of-service / overload condition (2)(h) requires resilience and DoS-mitigation measures against.

CRA Annex I (2)(h) availability is domain-relevant but does not mitigate DE-0010: log/telemetry buffer exhaustion hides activity via rollover while essential functions stay available. The operative controls are protected non-wrapping audit storage and logging-integrity monitoring. Addresses.

Manufacturer obligation to protect availability of essential and basic functions also after an incident is the recovery-side obligation engaged by ransomware: products must remain operationally recoverable through resilience and mitigation mechanisms.

Availability-after-incident obligation covers wiper events: products must maintain or recover essential functions even after destructive payloads execute.

Availability-after-incident obligation covers safe-mode windows: manufacturers must design products so essential cybersecurity functions remain enforced even in reduced-functionality contingency states.

Availability-after-incident obligation covers propulsion-tampering events that compromise safe operation.

Availability obligation covers power-related tampering whose effects directly compromise essential-function availability.

Availability obligation extends to watchdog mechanisms whose disabling allows hung software to persist undetected.

Availability obligation explicitly references resilience and mitigation against denial-of-service attacks; flooding is the canonical DoS class governed by (2)(h).

Availability obligation covers valid-command flooding; products must absorb or shed legitimate-but-saturating command traffic without losing essential functions.

Availability obligation covers erroneous-input flooding; products must resist parser-saturation through hardened ingress logic and resource controls.

Availability obligation covers continued operation under PNT spoofing through fall-back to non-GNSS time/position sources.

Manufacturer obligation to protect availability of essential and basic functions also after an incident bounds the exploitation window during safe-mode: products must maintain protection mechanisms even in reduced-functionality states.

Disrupting spacecraft-to-ground communications during critical times is exactly the availability impact (2)(h) requires resilience and DoS-mitigation measures against, including the 'also after an incident' clause.

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.

Permanent impairment of subsystems or hosted payload directly attacks the availability of essential functions; (2)(h)'s resilience obligation includes mitigation against persistent degradation, not only transient DoS.

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.