Art. 21(2)(h)

Art. 21(2)(h) crypto policy does not interdict suppression or alteration of onboard fault detection through flight-code and table patching; the operative control is fault-management integrity and code integrity. Addresses (domain relevance).

An authenticated telemetry MAC interdicts in-pipeline value substitution on the reporting path, but it does not cover the dominant scope of visibility denial, induced crashes and display tampering, where the operative control is integrity-monitoring and redundancy rather than cryptography. Under the strict bar the cryptographic control covers one vector but not the defining scope, so at NIS2 Art. 21(2)(h) the relationship is addresses.

Signed and integrity-protected counter values, severity flags, and mode indicators under cryptography policy at Art. 21(2)(h) detect rewrites of the fields ground operators rely on for command-hygiene judgement.

Signed verified-command-count reports defeat ground-side rewriting of the reported counter, but they do not stop onboard counter and field tampering by an adversary with write access, since cryptography cannot prevent direct register edits at the source. Under the strict bar the cryptographic control covers the reporting path but not the defining onboard vector, so at NIS2 Art. 21(2)(h) the relationship is addresses.

Cryptographic mode controls, algorithm selectors, key IDs, and 'crypto off/clear' states are precisely the surface cryptography policy at Art. 21(2)(h) is meant to govern — including the ground/space synchronisation that the technique attacks.

Append-only signed command-history makes pruning and rewriting detectable, but it does not prevent onboard log pruning by an adversary with write access, where the operative control is audit-record integrity and protection rather than a cryptography-use policy. Under the strict bar the cryptographic control makes tampering detectable but does not interdict the defining onboard vector, so at NIS2 Art. 21(2)(h) the relationship is addresses.

Authenticated time service and integrity-protected disciplining sources under cryptography policy at Art. 21(2)(h) defeat the time-bias attack the technique uses to misalign acknowledgments and stored sequence execution.

Art. 21(2)(h) requires the entity to maintain cryptography policies and procedures covering link-layer and crosslink authentication; that governance obligation addresses masquerading by mandating the authentication measures, while the deployed authentication and identity binding, not the policy article, are what reject crafted frames presented as an authorised origin.

Art. 21(2)(h) crypto policy does not interdict exploitation of a relaxed safe-mode acceptance posture; the operative control is recovery-posture hardening that preserves checks during contingency, not cryptography. Addresses (domain relevance).

Art. 21(2)(h) crypto policy does not interdict modification of onboard command whitelists; the operative control is allowlist integrity and execution control. Addresses (domain relevance).

Secure-boot signature verification and anti-rollback are cryptographic mechanisms, but the operative control against bootkit precedence is protection against malicious and unauthorised software, which the CIR (EU) 2024/2690 Annex assigns to section 6 (6.9 protect against and detect or prevent the use of malicious or unauthorised software; 6.4 change management of software in operation), not to the section 9 cryptography requirements (cryptography policy, algorithm and cipher selection, and key management). At NIS2 Art. 21(2)(h), use of cryptography, the relationship to this technique is addresses; the mitigation sits at the section-6 control.

Art. 21(2)(h) obliges the entity to hold cryptography policies and procedures covering anti-replay and message authentication; it addresses replay by requiring those measures, while the deployed anti-replay state and MAC-bound counters, not the policy article, are what make captured traffic ineffective on retransmission.

Art. 21(2)(h) mandates cryptography policies and procedures covering anti-replay; it addresses command-packet replay by requiring those measures, while the deployed anti-replay windows and fresh counters, not the policy obligation, are what defeat re-transmission of captured PDUs whose framing and MAC are intact.

This technique modifies the running command-validation logic to become the trust oracle; Art. 21(2)(h) crypto is the subject being subverted, and the operative control is flight-code and memory integrity. Addresses (domain relevance).

Secure boot and anti-rollback are cryptographic mechanisms that interdict boot-image replacement and downgraded-image selection, but they do not reach the glitch-fault and configuration-bit-flip vectors that act before the signature check, where the operative control is boot integrity and fault resistance. The CIR (EU) 2024/2690 Annex assigns that control to section 6 (6.9; 6.4 change management), not to the section 9 cryptography requirements. At NIS2 Art. 21(2)(h) the relationship is addresses.

EX-0006 forces command, telemetry or data onto paths where encryption is absent, weakened or inconsistently applied; NIS2 21(2)(h) policies on the use of cryptography and encryption govern this risk.

Signed binaries, table loads and firmware are cryptographic mechanisms that defeat malicious code accepted via the load path, but they do not reach runtime interpreter, shellcode and memory-write execution, where the operative control is execution control and memory protection. The CIR (EU) 2024/2690 Annex assigns that control to section 6 (6.9 protection against malicious and unauthorised software), not to the section 9 cryptography requirements. At NIS2 Art. 21(2)(h) the relationship is addresses.

Art. 21(2)(h) crypto policy does not interdict an in-host rootkit that hooks live calls and rewrites values; the operative control is operating-system and kernel integrity with runtime attestation. Addresses (domain relevance).

Secure boot and anti-rollback enforced from immutable ROM are cryptographic mechanisms, but the operative control against bootkit precedence is protection against malicious and unauthorised software, which the CIR (EU) 2024/2690 Annex assigns to section 6 (6.9; 6.4 change management of software in operation), not to the section 9 cryptography requirements (cryptography policy, algorithm and cipher selection, and key management). At NIS2 Art. 21(2)(h) the relationship is addresses; the mitigation sits at the section-6 control.

Art. 21(2)(h) crypto policy does not interdict timing on-board actions to a relaxed safe-mode window; the operative control is recovery-posture hardening, not cryptography. Addresses (domain relevance).

Signed table loads and authenticated parameter edits are cryptographic mechanisms that defeat malicious data introduced via legitimate load and write mechanisms, but they do not cover direct configuration and data tampering by an adversary with write access, where the operative control is system-integrity and access control. The CIR (EU) 2024/2690 Annex assigns those to section 6 (6.3 configuration management; 6.9 protection against unauthorised software), not to the section 9 cryptography requirements. At NIS2 Art. 21(2)(h) the relationship is addresses.

Signed memory loads and authenticated block transfers are cryptographic mechanisms that prevent chosen-byte writes at chosen addresses via legitimate transfer mechanisms, but they do not cover direct memory tampering by an adversary with write access, where the operative control is memory protection and access control. The CIR (EU) 2024/2690 Annex assigns those system-integrity and access controls to section 6, not to the section 9 cryptography requirements. At NIS2 Art. 21(2)(h) the relationship is addresses.

Integrity-protected payload products and signed metadata detect in-place upstream tampering, but they do not prevent onboard tampering by an adversary with write access, where the operative control is data integrity and access control rather than communications cryptography. Under the strict bar the cryptographic control detects tampering but does not interdict the defining onboard vector, so at NIS2 Art. 21(2)(h) the relationship is addresses.

Anti-replay counters and timetag validation under cryptography policy at Art. 21(2)(h) depend on a stable, authenticated time base; the obligation requires that time-distribution services be integrity-protected against the bias attack the technique describes.

Art. 21(2)(h) is an organisational cryptography-policy obligation and does not reach the external GNSS/PNT signal spoofing that dominates this technique, which is interdicted at the signal layer (GNSS signal authentication such as Galileo OSNMA/PRS), not by the operator's crypto policy. It relates to the entity's cryptographic posture but neither mitigates nor governs signal spoofing.

Art. 21(2)(h) requires cryptography policies and procedures covering authenticated time distribution; it addresses time spoofing by mandating those measures, while the deployed authenticated time sources and integrity-protected disciplining, not the policy article, are what defeat the time-bias attack.

Art. 21(2)(h) obliges cryptography policies and procedures that can extend to bus message authentication; it addresses bus-traffic spoofing by requiring those measures where the bus supports them, while the deployed MACs and per-publisher key separation, not the policy article, are what reject forged frames with otherwise-valid identifiers.

NIS2 Art. 21(2)(h) cryptography policy is relevant to the crypto material targeted, but does not interdict physical side-channel or fault-injection extraction; the operative mitigation is physical hardening, shielding and masking. Mapped as addresses (domain relevance).

Art. 21(2)(h) requires cryptography policies and procedures covering anti-replay; it addresses replay-to-exfiltrate by mandating those measures, while the deployed anti-replay state and MAC-bound counters, not the policy obligation, are what prevent re-sent commands from inducing a repeat downlink of previously dumped data.

Art. 21(2)(h)'s policy on the use of cryptography is domain-relevant, but a crypto-use policy does not interdict physical-byproduct (power, EM, timing) extraction of secrets; the actual mitigation is implementation and physical side-channel resistance such as masking and shielding.

Art. 21(2)(h) crypto policy does not interdict power-analysis key recovery; side-channel-resistant implementation (power masking, hiding) is hardware/implementation hardening, not use-of-cryptography policy. Addresses (domain relevance).

Art. 21(2)(h) crypto policy does not interdict EM-emanation key recovery; the operative mitigation is TEMPEST shielding and emission control, not use-of-cryptography policy. Addresses (domain relevance).

Art. 21(2)(h) encryption protects content but does not interdict traffic-flow analysis, which infers aggregator nodes and activity from metadata patterns; the operative control is traffic padding and emission management. Addresses (domain relevance).

Art. 21(2)(h)'s policy on the use of cryptography is domain-relevant, but a crypto-use policy does not mandate the constant-time implementation that defeats a timing side-channel; the interdicting control is an implementation property, not a policy on cryptography use.

Art. 21(2)(h) crypto policy does not interdict thermal-imaging extraction; the operative mitigation is thermal and emission design, not use-of-cryptography policy. Addresses (domain relevance).

Art. 21(2)(h) obliges the entity to maintain cryptography and, where appropriate, encryption policies covering mission traffic; it addresses signal interception by requiring those measures, while the deployed end-to-end encryption, not the policy article, is what reduces interception to traffic-analysis surface only.

Art. 21(2)(h) requires cryptography and encryption policies covering the uplink; it addresses uplink exfiltration by mandating those measures, while the deployed uplink confidentiality and integrity, not the policy obligation, are what keep telecommand content from an unauthorised receiver.

Art. 21(2)(h) obliges cryptography and encryption policies covering the downlink; it addresses downlink exfiltration by requiring those measures, while the deployed downlink confidentiality, not the policy article, is what reduces an interception campaign to traffic-analysis surface only.

Art. 21(2)(h) encryption defends against external eavesdroppers, but here the adversary is the emitter exfiltrating over a secondary link; the operative control is link monitoring, egress control and segmentation. Addresses (domain relevance).

Art. 21(2)(h) crypto policy does not interdict proximate collection of unintended emissions; the operative mitigation is physical EMSEC, shielding and emission control. Addresses (domain relevance).

Art. 21(2)(h) crypto policy does not interdict a covert downlink created by link reconfiguration or steganographic embedding; the operative control is emission monitoring and egress control. Addresses (domain relevance).

Art. 21(2)(h) crypto policy does not interdict SDR covert subcarrier, pilot or puncturing channels; the operative control is emission monitoring and signal-configuration control. Addresses (domain relevance).

Art. 21(2)(h) crypto policy does not interdict exfiltration routed out through payload communication channels by an onboard implant; the operative control is channel segregation and egress monitoring. Addresses (domain relevance).

Stolen signing keys are the named attack path; cryptography policy under Art. 21(2)(h) is the obligation that governs key-pair generation, HSM custody, attestation, and rotation — directly limiting the blast radius of any single key compromise.

Signed waveform and bitstream profiles defeat rogue DSP and framing loads into the software-defined radio, but they do not cover the broad SDR-compromise scope, including covert command-and-control waveforms that are not cryptographically interdicted, where the operative control is supply-chain and configuration integrity. The CIR (EU) 2024/2690 Annex assigns those to sections 5 and 6 (6.3 configuration management), not to the section 9 cryptography requirements. At NIS2 Art. 21(2)(h) the relationship is addresses.

Authenticated crosslink protocols, fresh nonces, and per-peer key separation under cryptography policy at Art. 21(2)(h) defeat traffic that merely 'appears to originate' from a trusted neighbour.

Authentication parity defeats forged-command injection on a weakly-authenticated alternate path, but it does not stop exploitation of the alternate path itself, where the operative control is consistent access control across paths. Under the strict bar the cryptographic control covers the forgery vector but not the dominant cross-path access-control residual, so at NIS2 Art. 21(2)(h) the relationship is addresses.

Authentication parity on the backup receive chain interdicts command forgery, and unlike the Sprint D encryption-only ENISA excerpt, NIS2 Art. 21(2)(h) does span authentication, so that earlier ruling does not control here. Even so, under the strict bar the dominant residual is consistent cross-path access control, as for the parent technique IA-0004: cryptography interdicts the forgery vector but not exploitation of the alternate path. The relationship at 21(2)(h) is therefore addresses, the strict bar resolving the item against its own authentication-scope counter.

Art. 21(2)(h) crypto key governance limits the value of leaked key material but does not interdict the side-channel extraction of keys, counters or protocol state from emanations; the operative mitigation is physical shielding and masking. Addresses (domain relevance).

Art. 21(2)(h) requires cryptography policies and procedures covering update integrity and image signing; it addresses compromise of on-orbit updates by mandating those measures, while the deployed image signing, integrity-protected manifests, and monotonic counters, not the policy obligation, are what defeat substitution and rollback.

Art. 21(2)(h) obliges cryptography policies and procedures covering uplink and crosslink authentication; it addresses rogue external commanding by requiring mutual authentication, while the deployed authentication, not the policy article, is what stops a syntactically valid transmission from an unauthorised platform being acted on as a telecommand.

Art. 21(2)(h) requires cryptography policies and procedures covering uplink authentication; it addresses rogue-ground-station commanding by mandating those measures, while the deployed uplink authentication, not the policy obligation, is what defeats a rogue station's syntactically valid traffic.

Art. 21(2)(h) obliges cryptography policies and procedures covering crosslink authentication; it addresses impersonation by a rogue spacecraft by requiring those measures, while the deployed crosslink authentication, not the policy article, is what defeats spoofed acquisition, time-distribution, and routing messages.

Art. 21(2)(h) crypto policy does not interdict initial access timed to a relaxed safe-mode acceptance posture; the operative control is recovery-posture hardening, not cryptography. Addresses (domain relevance).

Authenticated telemetry and uplink make telemetry mimicry and falsified-source communications visible at receipt, but they do not cover the dominant scope of broad deception through falsification and TTP mimicry, where the operative control is integrity-monitoring and access control. Under the strict bar the cryptographic control covers the message-authenticity vector but not the defining deception scope, so at NIS2 Art. 21(2)(h) the relationship is addresses.

Art. 21(2)(h) requires cryptography and, where appropriate, encryption policies covering payload and mission data; it addresses theft of mission data by mandating encryption in transit and at rest, while the deployed confidentiality controls, not the policy obligation, are what actually deny the adversary the content.

Art. 21(2)(h) obliges cryptography policies and procedures covering crosslink authentication and key separation; it addresses constellation hopping by requiring those measures, while the deployed authentication and per-peer keys, not the policy article, are what defeat hop-by-hop spread that relies on appearing to come from a trusted neighbour.

Secure boot, signed images, anti-rollback and authenticated table loaders are cryptographic mechanisms, but the operative control against copy-on-boot and altered-loader persistence is boot-chain integrity and protection against unauthorised software, which the CIR (EU) 2024/2690 Annex assigns to section 6 (6.9; 6.4 change management of software in operation), not to the section 9 cryptography requirements (cryptography policy, algorithm and cipher selection, and key management). At NIS2 Art. 21(2)(h) the relationship is addresses; the mitigation sits at the section-6 control.

PER-0004 installs attacker-chosen keys and algorithm profiles via rekey and key-loading procedures, desynchronizing anti-replay and stranding operators; NIS2 21(2)(h) policies on cryptography and encryption including key management govern this risk.

Cryptography policy under Art. 21(2)(h) is the precise obligation that defines key generation, storage, transport, loading, KEK hierarchy, and rotation — depriving an adversary of stable key material to acquire.

Here cryptography is the subject of reconnaissance (algorithms, key handling, parameters gathered from specifications, logs and hardware); Art. 21(2)(h) does not interdict the information gathering, which is countered by information protection and OPSEC. Addresses (domain relevance).

Art. 21(2)(h) crypto policy does not hide RF and networking posture (bands, modulation, polarization, ground stations), which is observable regardless of encryption; the operative control is EMSEC and OPSEC. Addresses (domain relevance).

Art. 21(2)(h) crypto policy is part of the commanding-scheme design being studied; it does not interdict reconnaissance of command formats, authorization and sequencing from dictionaries and specifications, which is countered by information protection and OPSEC. Addresses (domain relevance).

Cryptographic key management deprives an adversary of usable key material, but it covers only the crypto-key-material subset of this technique, not its dominant scope of broad credential discovery across accounts and tokens via phishing and repositories, where the operative control is identity and access management and information protection. Under the strict bar the cryptographic control covers a subset but not the defining scope, so at NIS2 Art. 21(2)(h) the relationship is addresses.

Art. 21(2)(h) requires cryptography and, where appropriate, encryption policies covering TT&C and payload links; it addresses eavesdropping by mandating link encryption, while the deployed encryption, not the policy obligation, is what reduces wideband recordings to traffic-analysis surface only.

Uplink confidentiality + authentication under Art. 21(2)(h)'s cryptography-policy obligation prevents reconstruction of telecommand framing, authentication fields, and anti-replay behaviour from captured emissions.

Art. 21(2)(h) obliges cryptography and encryption policies covering the downlink; it addresses downlink intercept by requiring those measures, while the deployed telemetry encryption, not the policy article, is what prevents intercepts from yielding mission state and operator annotations.

Art. 21(2)(h) crypto policy does not interdict proximity emanations and side-channel observation; the operative mitigation is physical shielding and segregation. Addresses (domain relevance).