Art. 21(2)(e)

Ground-software integrity, secure development of telemetry processors and dashboards, and disclosed-vulnerability handling on those services fall under Art. 21(2)(e)'s network-and-information-systems acquisition/development/maintenance obligation.

Detector model training/packaging/promotion is part of the network-and-information-systems development/maintenance pipeline Art. 21(2)(e) governs, including disclosed-weakness handling on label-flipping and clean-label backdoor attacks.

Kernel-syscall integrity, separation-kernel hardening, and FSW-API tamper detection are squarely Art. 21(2)(e)'s network-and-information-systems development/maintenance + vulnerability-handling obligation.

Bootloader integrity, image-selection logic, device-tree handling, and recovery-mode images are network-and-information-systems development/maintenance artefacts; Art. 21(2)(e), including disclosed-vulnerability handling on the boot chain, is the obligation that governs them.

SDA software/ML-pipeline integrity (fusion/association code, detection models, ingest validators) is part of Art. 21(2)(e)'s network-and-information-systems development/maintenance + vulnerability-handling obligation, including disclosed weaknesses in those services.

Detection of cooperative-multi-component behaviour requires assurance disciplines (cross-component static analysis, behavioural fuzzing, integration-level vulnerability handling) Art. 21(2)(e)'s secure development/maintenance + disclosure obligation is meant to cover.

Patches to flight binaries, hot-patches in memory, and command-handler hooks are the integrity failures Art. 21(2)(e)'s secure development/maintenance and vulnerability-handling/disclosure obligation is meant to prevent and detect.

Bootloaders, OTP fuses, boot configuration words, and non-volatile boot images are network-and-information-systems development/maintenance artefacts; Art. 21(2)(e), including disclosed-vulnerability handling on those mechanisms, is the obligation that governs their integrity.

Firmware images, programmable-logic bitstreams, and configuration blobs in non-volatile memory are squarely within Art. 21(2)(e)'s network-and-information-systems acquisition/development/maintenance and vulnerability-handling obligation — particularly the disclosure of below-OS weaknesses traditional endpoint tooling misses.

Errata, undocumented test modes, and counter/timer rollovers are exactly the kind of disclosed-or-disclosable weaknesses Art. 21(2)(e)'s vulnerability handling and disclosure obligation requires the entity to track and remediate within its N+IS dev/maintenance posture.

EX-0009 abuses coding defects and known component vulnerabilities to execute on-board; NIS2 21(2)(e) security in acquisition, development and maintenance including vulnerability handling governs this defect class.

EX-0009.01 exploits flight-software implementation flaws to execute code or alter persistent parameters; NIS2 21(2)(e) security in development and maintenance including vulnerability handling governs this defect class.

EX-0009.02 exploits operating-system weaknesses and exposed management consoles for kernel-level execution; NIS2 21(2)(e) security in development and maintenance including vulnerability handling governs this risk.

Vulnerability handling and disclosure under Art. 21(2)(e) is the precise obligation that requires the entity to track CPE/CVE matches against components on-board, monitor vendor advisories, and close the disclosure-to-patch lag the technique exploits.

Native binaries, scripts, shellcode, and 'data payloads' delivered via update paths, file-transfer services, table loaders, or maintenance consoles all ride the network-and-information-systems acquisition/development/maintenance pipeline Art. 21(2)(e) governs, including disclosed-vulnerability handling on the parsers and loaders involved.

Separation-kernel/hypervisor integrity, syscall-hooking detection, and firmware-driver assurance are squarely Art. 21(2)(e)'s network-and-information-systems development/maintenance + vulnerability-handling obligation — including disclosed weaknesses in any of those layers.

Bootloader integrity, image-selection logic, and recovery-mode handling are network-and-information-systems development/maintenance artefacts; Art. 21(2)(e), including disclosed-vulnerability handling on the boot chain, is the obligation that governs them.

Model training, packaging, and uplink as routine updates are part of the network-and-information-systems acquisition/development/maintenance pipeline Art. 21(2)(e) governs, including disclosed-weakness handling for clean-label backdoors and label-flipping attacks.

Hardening of SDR/FPGA pipelines, bootloaders, and bus controllers against fault injection is part of secure development and maintenance under Art. 21(2)(e), including disclosed-vulnerability handling on the side-channel/fault surface.

Hardening of crypto modules, SDR/FPGA pipelines, bus controllers, and bootloaders against side-channel leakage and fault injection is part of secure development and maintenance under Art. 21(2)(e), including disclosed-weakness handling on the side-channel surface.

SDR DSP-chain modifications shipped as legitimate update profiles are a maintenance-pipeline attack; secure acquisition/development/maintenance and vulnerability handling under Art. 21(2)(e) cover the channel through which the change reaches the radio.

Embedding extended logging, telemetry taps, or 'export' features in test harnesses, simulators, or flight builds is exactly the integrity attack on the development pipeline Art. 21(2)(e)'s acquisition/development/maintenance and vulnerability-handling discipline is intended to detect and prevent.

The technique targets sources, dependencies, build systems and CI/CD runners — the precise pipeline Art. 21(2)(e)'s network-and-information-systems acquisition/development/maintenance obligation governs, including handling of disclosed weaknesses in those mechanisms.

Trust-on-first-use lock-ins on tainted packages, abuse of CI secrets, and compromised compilers are paradigmatic dev-pipeline failures Art. 21(2)(e)'s network-and-information-systems development-and-maintenance + vulnerability-handling obligation is meant to detect and remediate.

Subverting update metadata, swapping signed binaries at distribution edges, and version-rollback attacks on flight tables are precisely the integrity failures Art. 21(2)(e)'s secure development/maintenance and vulnerability-handling/disclosure obligations are meant to catch.

Toolchains, out-of-tree modules, bitstream loading, and update channels for SDR waveforms are precisely the network-and-information-systems acquisition/development/maintenance pipeline Art. 21(2)(e) governs, including disclosed-vulnerability handling on the SDR stack.

IA-0007.01 substitutes or modifies update artefacts in the build, packaging and staging pipeline before transmission to the vehicle; NIS2 21(2)(e) security in acquisition, development and maintenance governs the integrity of this pipeline.

ATLO is the late-stage network-and-information-systems acquisition/development/maintenance phase before flight; Art. 21(2)(e) — including disclosed-vulnerability handling — governs late firmware loads, key/counter initialisation, and configuration freezes that the technique exploits.

Bus-controller hardening, gateway-bridge design discipline, and disclosed-weakness handling on broadcast-semantic protocols are part of Art. 21(2)(e)'s network-and-information-systems acquisition/development/maintenance + vulnerability-handling obligation.

Separation kernels, hypervisors, virtual NICs, IPC port services, and shared driver backends with IOMMU bounds are squarely within Art. 21(2)(e)'s network-and-information-systems acquisition/development/maintenance and vulnerability-handling obligation — including disclosed parser flaws and racing-management-channel weaknesses.

Boot ROM handoff, first/second-stage loaders, golden fallback partitions, configuration words, and copy-on-boot logic are network-and-information-systems development/maintenance artefacts; Art. 21(2)(e), including disclosed-vulnerability handling on the persistence surface, is the obligation that governs them.

Pre-existing service modes, debug features, and adversary-introduced backdoors are integrity failures Art. 21(2)(e)'s secure development/maintenance and vulnerability-handling/disclosure obligation is meant to catch — both in pre-flight assurance and through post-flight disclosure response.

Hardware-integrity assurance and firmware-level vulnerability handling are part of Art. 21(2)(e)'s network-and-information-systems acquisition/development/maintenance and vulnerability-handling/disclosure obligation.

Hidden command handlers, alternate-authentication checks, special user/role constructs, and procedure/script hooks are integrity failures Art. 21(2)(e)'s secure development/maintenance and vulnerability-handling/disclosure obligation is meant to catch through code review, fuzzing, and disclosure response.

Protection of source trees, binaries-with-symbols, command-handler implementations, bootloaders, and patch/update mechanisms is exactly what secure acquisition, development and maintenance under Art. 21(2)(e) requires, including vulnerability handling for the disclosed dependencies an SBOM exposes.

Firmware update images, OTA bundles, secure-boot configuration, and anti-rollback policy live inside the network-and-information-systems development and maintenance pipeline that Art. 21(2)(e) explicitly governs, including handling of disclosed weaknesses in those mechanisms.

Cradle-to-operations protection of the FSW pipeline (architecture, source, build/sign/release, integration environments, autonomy rules) is exactly the network-and-information-systems acquisition/development/maintenance obligation in Art. 21(2)(e), including vulnerability handling on disclosed weaknesses.

Hardening of cross-compilers/SDKs, container images, build systems, branch protections, and CI orchestrators is exactly the secure development and maintenance posture Art. 21(2)(e) requires the entity to maintain.

Static analysers, fuzzers, sanitisers, fault-injection rigs, and coverage gates are the assurance discipline secure development and maintenance under Art. 21(2)(e) — including disclosed-vulnerability handling — explicitly mandates.

Software-factory hardening (repositories, build containers, package registries, signing services/HSMs, promotion gates) is the network-and-information-systems acquisition/development/maintenance posture Art. 21(2)(e) explicitly governs, including handling of disclosed weaknesses in those mechanisms.

Vulnerability handling and disclosure under Art. 21(2)(e) is the precise obligation that requires the entity to track CPE/CVE matches against its components, monitor advisories, and close the disclosure-to-patch lag the technique exploits.