Annex I, Part I, (2)(f)

Disabling fault management modifies authoritative configuration (limit tables, watchdog parameters, voting logic) and reporting routes — exactly the unauthorized manipulation of stored data, programs, and configuration that (2)(f) requires the product to protect against and report on corruption of.

Deception-based downlink attacks manipulate transmitted telemetry content — the canonical case (2)(f) integrity-of-transmitted-data covers, including its corruption-reporting requirement.

Falsifying telemetry within the ground system (modifying command counters, acknowledgments, housekeeping data) is exactly the unauthorized manipulation of processed data (2)(f) covers, including the corruption-reporting requirement.

Disabling on-board telemetry publishers and altering packet filters/rates is the unauthorized modification of programs and configuration (2)(f) addresses; the corruption-reporting requirement is directly defeated by the technique.

On-board values obfuscation rewrites housekeeping and control values (counters, flags, modes, clock) — the manipulation of stored/processed data and configuration (2)(f) requires protection against and corruption-reporting on.

Zeroing, freezing, or steering the Vehicle Command Counter is unauthorized manipulation of stored counter data and the telemetry field that reports it — the integrity property (2)(f) covers, including the corruption-reporting requirement.

Suppressing, clearing, or forging the Rejected Command Counter — and tampering with associated reason codes — is unauthorized manipulation of stored data (2)(f) addresses with its corruption-reporting requirement.

Toggling receiver enable states is unauthorized modification of receiver configuration — the manipulation-of-configuration scope (2)(f) covers.

Modifying AGC and signal-strength parameters is unauthorized modification of receiver configuration — within (2)(f)'s integrity-of-configuration scope.

Tampering with command-lock indicators and lock thresholds — freezing flags, raising/lowering internal thresholds — is unauthorized modification of stored data and configuration (2)(f) addresses.

Switching telemetry downlink modes and editing rates/filters/playback parameters is unauthorized modification of configuration parameters within (2)(f)'s scope.

Editing or pruning command-history buffers, logs, and file records is unauthorized modification of stored data (2)(f) covers, including the corruption-reporting requirement that the technique tries to suppress.

Biasing the spacecraft's authoritative time — writing clock registers, altering disciplining sources — is unauthorized modification of stored configuration that propagates into telemetry timestamps and command histories, within (2)(f)'s integrity scope.

Falsifying telemetered ephemeris data to deceive ground operators is unauthorized modification of transmitted data — the integrity property (2)(f) addresses with its corruption-reporting requirement.

Modifying watchdog parameters or relocating the petting source is unauthorized modification of configuration within (2)(f)'s scope.

Poisoning training data with crafted examples or labels is unauthorized modification of the data (and downstream model) the product processes — the integrity property (2)(f) covers.

Tampering with virtual channel IDs, APIDs, and source sequence counts to misattribute logs is unauthorized modification of stored/transmitted data within (2)(f)'s scope.

Modifying the on-board whitelist is unauthorized modification of a security-critical configuration table — squarely within (2)(f)'s integrity-of-configuration scope.

A rootkit patches flight-software APIs, kernel syscalls, and message queues — the canonical case of unauthorized modification of programs (2)(f) addresses, including the corruption-reporting requirement.

A bootkit patches boot ROM handoff, early loaders, and device tables — unauthorized modification of programs and configuration during the most privileged phase of the product, within (2)(f)'s scope.

Compromising or spoofing observational feeds, injecting falsified tracks, and tampering with fusion/association parameters are unauthorized modifications of the SDA product's processed data — within (2)(f)'s integrity scope.

Coordinated cooperative behavior between compromised components manipulates shared resources (files, buses) — modification of stored/transmitted data within (2)(f)'s scope.

Integrity protection of stored, transmitted and processed commands and programs ensures duplicated frames do not pass integrity checks; replay defeats by integrity binding.

Integrity protection on commands ensures replayed PDUs (lacking fresh integrity context) are rejected by the receiver.

Integrity protection on bus traffic prevents replayed messages from being accepted by subsystems that subscribe to specific message classes.

Integrity protection on programs (including authentication-validating code) is the manufacturer-side obligation that resists modifications to authentication logic; signed code, runtime integrity verification and secure-boot make hot-patching the auth layer fail integrity checks.

Integrity protection on programs and configurations is the manufacturer-side obligation that requires secure boot, measured boot and integrity-verified bootloader chains — the precise defense against pre-OS boot-memory compromise.

Integrity protection on firmware images and programmable-logic bitstreams resists corruption introduced beneath the software layer.

Integrity-protection obligations are equally non-negotiable; products must not allow arbitrary disabling of integrity checks via runtime configuration.

Integrity protection on programs and configurations is the manufacturer-side obligation that resists introduction of executable logic via malicious code.

Integrity protection on stored data and configuration resists ransomware-induced encryption of mission-critical content.

Integrity protection of executable images and configuration resists wiper-driven destruction.

Integrity protection on flight-software processes, OS components and FSW frameworks resists rootkit installation; signed code, runtime integrity verification and measured-boot mechanisms are manufacturer-side controls.

Integrity protection on boot artefacts is the manufacturer-side obligation requiring secure boot, measured boot and integrity-verified bootloader chains — the precise defense against bootkit installation.

Integrity protection on stored, transmitted and processed data, commands, programs and configurations is the manufacturer-side obligation directly engaged by on-board-value modification.

Integrity protection on internal routing tables resists rewrites of message-ID-to-handler mappings that would re-route traffic to attacker-controlled subscribers.

Integrity protection on stored data and programs resists arbitrary memory-load manipulation; signed-image enforcement and write-protected memory regions are manufacturer-side defenses.

Integrity protection on subscriber tables resists modification of message-ID-to-subscriber mappings.

Integrity protection covers scheduling-algorithm parameters and per-task configuration; modifications must be detected and rejected.

Integrity protection on stored or transmitted data covers payload products, raw frames, Level-0 streams and metadata against in-place modification.

Integrity protection on propulsion configuration (thruster calibration, valve timing, safing thresholds) is critical safety-related obligation under (2)(f).

Integrity protection on ADCS parameters (star-tracker catalogs, sensor alignments, gyro biases) ensures attitude-control integrity.

Integrity protection on EPS parameters (bus voltage limits, charge curves, load-shed priorities) safeguards power-subsystem behaviour.

Integrity protection on C&DH tables and runtime values (opcode-to-handler maps, queue policies) is essential to command correctness.

Integrity protection on watchdog-timer configuration ensures liveness-supervision logic cannot be silently bypassed.

Integrity protection on system-clock state and time-distribution sources resists clock-write tampering with anti-replay counters and time-tag validation.

Integrity protection on training-data inputs and model artefacts is the (2)(f) obligation engaged by data-poisoning attacks against onboard ML.

Integrity protection on inputs (sensor measurements, time tags, bus messages) resists fabricated content being treated as authoritative truth.

Integrity protection on time-distribution inputs resists biased or forged time tags that would reorder execution and break anti-replay counters.

Integrity protection on bus traffic resists forged-frame acceptance by subscribers.

Integrity protection on sensor-data interfaces resists fabricated-measurement injection between sensors and FSW.

Integrity protection extends to PNT-receiver design choices: multi-constellation cross-checks and integrity-monitoring fall-back are product-side defenses against PNT spoofing.

Counters, timetags, and acceptance conditions ARE the integrity controls (2)(f) requires; replay defeats them when the protections are absent or weak.

Retuning carriers, editing modulation/coding profiles, remapping virtual channels/APIDs, and editing routing tables are unauthorized modifications of communications configuration — the integrity-of-configuration scope (2)(f) covers, including the corruption-reporting requirement.

Modifying SDR DSP chains (filters, mixers, FEC, framing) is unauthorized modification of programs and configuration; (2)(f)'s integrity-of-programs scope and corruption-reporting requirement directly address this.

Remapping transponder I/O paths, shifting translation frequencies, and editing routing tables are unauthorized modifications of authoritative configuration — the integrity-of-configuration scope (2)(f) covers.

Embedding telemetry taps, extended logging, or data-export features into builds is unauthorized modification of programs that manifests post-deployment — the integrity-of-programs property (2)(f) requires the manufacturer to protect end-to-end through the build pipeline.

Steganographic embedding of host-bus data into payload products manipulates transmitted data that the user did not authorize for that channel — within (2)(f)'s integrity scope.

Modifying telemetry values to induce mission stakeholders to react in error is the canonical case (2)(f) integrity addresses — manipulation of transmitted data not authorized by the user, with the corruption-reporting requirement.

IMP-0002 explicitly differs from denial in that it can also modify data and messages as they pass — within (2)(f)'s integrity-of-transmitted-data scope.

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.

Routing updates, service advertisements, and time/ephemeris distribution traversing crosslink are processed data whose integrity (2)(f) requires protection of, including the corruption-reporting requirement.

Integrity protection on boot ROM handoff vectors and first-stage code is the manufacturer-side obligation requiring secure-boot, measured boot and immutable bootloader chains.

Integrity protection on stored keys and configurations resists unauthorized rotation through procedural manipulation.

Annex I, Part I, (2)(f) requires manufacturers to protect the integrity of stored, transmitted and processed data, commands, programs and configuration; reconnaissance of cryptographic algorithms and modes loses operational value when integrity protection is properly enforced.