Annex I, Part I, (2)(d)

Receiver-enable changes should require authenticated configuration commands and access controls; (2)(d)'s authentication and access-management obligation mitigates this attack at the config-change boundary.

Crypto-mode manipulation including authentication-bypass selection (e.g., turning to a profile the ground does not validate against) is the precise attack (2)(d)'s authentication obligation requires the product to resist.

Masquerading by crafting authenticated-looking telecommand frames, imitating station fingerprints, or replaying crosslink identities is the canonical authentication-bypass attack (2)(d) requires the product's access-management mechanisms to resist.

Issuing maintenance-looking commands under safe-mode's broadened acceptance is an authentication-bypass scenario (2)(d) requires the product's access-management to resist regardless of operating mode.

Intermittent or misleading transponder replies and spoofed RF identities are authentication failures of the proximity-identification protocol — within (2)(d)'s authentication and report-on-unauthorised-access scope.

Credentialed evasion is the canonical case (2)(d)'s 'report on possible unauthorised access' clause is meant to surface — appropriate-control-mechanisms must include detection of legitimate-but-anomalous credential use.

Manufacturer authentication obligations include replay-resistant mechanisms (counters, timestamps, MAC binding); products designed under (2)(d) reject re-sent traffic and convert replay attempts into immediate rejection.

Telecommand authentication with monotonic counters and MAC binding makes whole-PDU replay unsuccessful; this is the manufacturer-side defense against captured-and-replayed commands.

Authentication on internal command/data buses (1553, SpaceWire, custom) is the manufacturer-side control that resists bus-traffic replay; products should enforce origin authentication on bus messages.

Authentication architecture itself is an obligation; manufacturers must design auth processes that resist self-modification through hardware-rooted identity and signed/enforced code paths.

Authentication of boot artefacts (signed bootloaders, hardware root of trust) is a manufacturer-side protection mechanism encompassed by (2)(d) access-control obligations.

Manufacturer obligation to provide protection from unauthorized access via authentication and access-management applies to low-level/maintenance command interfaces; products must constrain JTAG, scan-chain and memory-mapped-register access.

Authentication and access-control obligations bound who can issue commands that toggle cryptographic state, narrowing the population that can subvert encryption.

Authentication obligations apply during safe-mode; manufacturer-designed safe-mode profiles must not relax auth requirements that would otherwise be enforced.

Authentication and access-management obligations bound which actors can write to live or persistent on-board values.

Authentication-and-access-control obligations apply to register-level interfaces; manufacturers must constrain which actors can issue memory-mapped register writes.

Authentication obligations bound who can issue raw memory operations; manufacturers must constrain memory-write authority via factor-bound auth.

Authentication obligations bound who can alter scheduling parameters whose modification can starve safety-critical tasks.

Authentication obligations bound who can alter propulsion parameters whose tampering produces mission-impact effects.

Authentication bounds who can issue ADCS-parameter modifications.

Authentication bounds who can alter C&DH configuration that governs command parsing and dispatch.

Authentication procedures with rate-limiting, per-counter validation and identity binding reduce the resource cost of valid-command flooding by enabling cheap rejection.

Authentication obligations bind inputs to verifiable identities; spoofed inputs lacking valid authentication tokens are rejected by subsystems applying these procedures.

Authentication on time-distribution paths (signed PTP/NTP, authenticated cross-link time tags) reduces the success of forged time inputs.

Authentication on internal bus interfaces (1553, SpaceWire, custom) is the manufacturer-side defense against forged-frame injection from arbitrary nodes.

Replay-resistant authentication (counter freshness, nonces, timestamp windows) is the precise authentication property (2)(d) requires the product's access-management mechanisms to provide.

Authentication and access-management (2)(d) addresses EXF-0003 by limiting reuse of intercepted commands via replay-counter binding, but the interception vector itself is interdicted by confidentiality/encryption (2)(e); recorded here as addresses.

Authentication with replay protection (2)(d) addresses EXF-0003.01 by reducing reuse of captured uplink material, but interception of the command path is interdicted by confidentiality/encryption (2)(e); recorded here as addresses.

Art. (2)(d) is access-control relevant (authenticated frame structure limits reuse/replay of captured material) but does not interdict the eavesdropping vector itself; the operative control against interception of downlink content is confidentiality/encryption (2)(e).

Out-of-band channels need the same authentication and access-management discipline as primary TT&C; (2)(d)'s appropriate-control-mechanisms obligation covers vendor/service modes that carry file fragments.

Communications-config changes should require authenticated commands and access controls; (2)(d)'s authentication and access-management obligation mitigates this attack at the config-change boundary.

SDR profile/configuration changes should require authenticated commands; (2)(d)'s authentication obligation applies to all privileged configuration interfaces.

Transponder routing/QoS changes should require authenticated commands; (2)(d)'s access-management obligation governs who can edit these tables.

Compromise of operator workstations, mission control servers, and telemetry processing pipelines is the canonical case (2)(d)'s authentication and access-management obligation addresses for ground-segment products with digital elements.

Cross-organization links (partner stations to MOC) need authenticated boundary controls; (2)(d)'s access-management obligation mitigates man-in-the-middle on these links when paired with mutual authentication.

Manufacturer obligation to provide authentication and access-management mechanisms applies to crosslink interfaces; properly-authenticated peers preclude a compromised neighbor from being a bridgehead.

Manufacturer authentication obligations apply uniformly to primary and secondary/backup channels; the product must enforce equivalent authentication on contingency TT&C, beacons and emergency commanding paths.

Authentication obligations apply equally on backup ground-station infrastructure; products must enforce equivalent auth on contingency commanding paths.

Backup on-board receivers must enforce the same authentication mechanisms as the primary path under the manufacturer's product-cybersecurity obligations.

Authentication obligations apply to docking/berthing interfaces; the product must enforce mutual authentication on rendezvous-permission, capture-permission and post-dock command exchanges.

Authentication obligations apply to payload-to-bus command interfaces; the bus should accept payload-originating commands only with manufacturer-defined authentication.

Authentication obligations apply to ground-system products that command the spacecraft; mission-control software, baseband modems and operator workstation tooling must enforce manufacturer-defined authentication.

Manufacturer authentication obligations require strong, factor-based identity verification on commanding consoles; valid-GS misuse (using already-configured ground equipment) is bounded when the product enforces independent multi-factor authentication on commanding actions.

Authentication obligations on the spacecraft uplink (cryptographic command authentication, counters, replay protection) reduce a rogue external transmitter to noise; the product manufacturer must implement these mechanisms regardless of the legitimate ground architecture.

Manufacturer-implemented authentication on the uplink defeats rogue ground stations: per-counter MAC verification rejects commands lacking valid keys regardless of transmit power or geometry.

Authentication on crosslink and proximity-domain interfaces converts a rogue spacecraft into an unauthenticated peer; manufacturer-mandated auth makes RF geometry insufficient without valid keys.

Authentication obligations bound the privileges third-party connections receive within the product; products designed under (2)(d) require explicit, factor-bound auth even from trusted relationships.

Authentication obligations bound vendor remote-administration access; manufacturer-enforced auth on these privileged paths prevents credential leak from converting into operations-affecting access.

Authentication on user-segment interfaces bounds what user-segment compromise can reach in the product's commanding or telemetry-distribution backends.

Authentication obligations apply during safe-mode; manufacturer-designed safe-mode profiles must not relax auth requirements that would otherwise be enforced.

Authentication on peripheral interfaces bounds which auxiliary devices can deliver data or code to the product.

Compromised allied ground infrastructure used as the source of communications to the spacecraft is an authentication-bypass scenario (2)(d) requires the spacecraft's access-management to resist regardless of source apparent legitimacy.

Strict authentication and access-management mechanisms restrict who can access the data stores and downlink channels theft would target — within (2)(d)'s appropriate-control-mechanisms scope.

Authentication and access-management mechanisms across the gateway processor between host and payload mitigate the privileged-service requests (time/ephemeris distribution, firmware loads) that LM-0001 abuses.

Forging message IDs or terminal addresses, replaying actuator/sensor frames, and seizing bus-controller roles are authentication failures of the bus protocol — within (2)(d)'s authentication and access-management obligation.

Crafted crosslink traffic that 'appears to originate from a trusted neighbor' is the canonical authentication-bypass scenario (2)(d) requires the product's access-management to resist on inter-satellite links.

Docking-time umbilical and firmware push channels are exactly the high-trust access path (2)(d)'s authentication and access-management obligation must scope, even within expected post-dock procedures.

Launch vehicle ↔ payload commissioning links carry commands, file transfers, and configuration; (2)(d)'s authentication obligation applies to these high-trust short-duration interfaces.

Reuse of credentials/keys to cross domain boundaries is the canonical case (2)(d)'s access-management obligation addresses — appropriate-control-mechanisms must enforce role and scope boundaries on credentials.

Authentication and access-management obligations on ground-system products are what bound the convertibility of foothold to commanding access; manufacturer-implemented MFA and identity-binding break long-dwell credential leverage.

Authentication obligations include identity life-cycle management of cryptographic keys; manufacturers must design products so key replacement requires verified, factor-bound authority.

Credentialed persistence is the canonical case (2)(d) addresses: the obligation requires authentication and identity/access-management mechanisms plus reporting on possible unauthorised access — which credential lifecycle hygiene, monitoring, and access-revocation directly target.

Manufacturer obligation to provide authentication and access-management mechanisms determines the value of obtained cryptographic keys: well-designed products bind keys to product-side verification (counters, factor binding, hardware-backed identity) so adversary-acquired keys do not directly yield operational access.

Manufacturer obligation to ensure protection from unauthorized access by appropriate control mechanisms (including authentication, identity, access management) is the design-side defense that converts commanding-detail reconnaissance into a still-blocked command path: even full knowledge of the command schema does not yield acceptance without valid authentication.

Manufacturer obligation to provide authentication, identity and access-management mechanisms is the procedural lever that bounds the value of credential reconnaissance: products designed under (2)(d) bind credentials to verified factors so passive harvesting alone does not yield commanding access.