Art. 21(2)(d)

Detector training corpora (telemetry archives, RF-fingerprint datasets, command-semantic logs) often ride supplier and service-provider data flows; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework around those sources.

SDA partner data flows (radar/optical sensor networks, ephemeris exchanges, fusion partners) ride supplier and service-provider relationships; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework around those sources.

Coordinated multi-component compromise originates in the supply-chain process (multiple modules from multiple vendors compromised together); Art. 21(2)(d)'s supplier-relationship security obligation is the central control over that origin.

Hardware/firmware corruption frequently originates with component or IP-block suppliers (boot ROMs, vendor MCUs, FPGA cores); Art. 21(2)(d)'s supplier-relationship security obligation governs that trust framework.

Design flaws originate at hardware and IP-block suppliers; Art. 21(2)(d)'s supplier-relationship security obligation governs how the entity tracks supplier errata and disclosure cadence.

Defects in commercial software components and FOSS libraries ride supplier and service-provider relationships; Art. 21(2)(d)'s supplier-relationship security obligation covers the trust framework around those COTS/FOSS dependencies.

Standard libraries, crypto/compression libraries, protocol stacks, FITS/CCSDS parsers, and vendor SDKs ride supplier and service-provider relationships; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework around those COTS/FOSS components.

Training corpora, fine-tuning sets, calibration/ground-truth products, and simulated scenes ride supplier and service-provider data flows; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework around those data products.

Compromise of contractor or partner development/integration environments (where source, test vectors, and ATLO artefacts live) is a textbook software supply-chain failure; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework over those environments.

Commercial ground stations, relay networks, and data-processing partners with mission feeds are direct service providers; supplier-relationship security under Art. 21(2)(d) governs the trust framework around their data flows and cross-organisation distribution mechanisms.

Payload comms channels often run through customer/experimenter networks under separate operational control; supplier-relationship security under Art. 21(2)(d) covers the boundary the technique exploits to route host-bus data into payload-side downlinks.

IA-0001 inserts malicious code through the product supply chain (vendor updates, dependencies, build and integration pipelines); NIS2 21(2)(d) supply chain security governs the supplier and provider relationships this technique abuses.

Dependency confusion, typosquatting, poisoned base images, malicious IDE plugins, and compromised compilers all ride supplier and service-provider relationships (registries, container registries, IDE vendors); Art. 21(2)(d)'s supplier-relationship security obligation is what constrains the trust framework.

Software-distribution suppliers (mirrors, CDNs, signing services) are direct service providers; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework around the promotion pipeline this technique abuses.

Hardware Trojans, modified bitstreams, and counterfeit substitutions enter via direct hardware suppliers (board fabs, FPGA IP vendors, peripheral ICs); Art. 21(2)(d) governs those supplier relationships as supply-chain security.

SDR vendors and their update-channel operators are direct suppliers; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework through which waveforms and patches arrive.

Crosslinked partner spacecraft (especially in mixed-operator constellations) are service providers in the entity's trust graph; Art. 21(2)(d)'s supplier-relationship security obligation governs the segmentation expectations across that trust boundary.

Standby commercial stations and contingency-chain operators are direct service providers; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework around backup-path operator accounts, scheduler/orchestration, and modem profiles.

OSAM/servicing vehicle operators are direct service providers connecting via high-trust mechanical/electrical interfaces; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework, key management, and procedure separation across the dock.

Hosted-payload operators are direct service providers sharing the host bus and frequently a parallel ground infrastructure; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework across that boundary.

The technique is precisely the supplier-relationship security obligation in Art. 21(2)(d): formal interconnections with partners, vendors, and user communities (VPNs, jump hosts, API keys, automated file drops) all sit on direct supplier and service-provider trust.

Universities, science operations centres, and international partners with delegated authority over instrument commanding tools and data portals are direct service providers; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework around those collaboration paths.

Vendors with persistent remote-administration routes, IdP/license access, and patch-delivery authority are core direct service providers; Art. 21(2)(d)'s supplier-relationship security obligation is the central control over those high-trust relationships.

Where user-segment infrastructure (SATCOM terminals, customer gateways, tasking portals) shares networks with TT&C or provider management, those interconnections are supplier-relationship touchpoints Art. 21(2)(d)'s obligation governs.

Peripheral firmware integrity and removable-media provenance ride supplier and service-provider relationships; Art. 21(2)(d)'s supplier-relationship security obligation covers vendors of cables, drives, lab tooling, and pre-loaded media.

ATLO concentrates multiple suppliers and integrators on shared lab networks (test controllers, EGSE, vendor support accounts, simulators); Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework across that highly mixed environment.

When the host SV operator is the payload's service provider (rideshare, hosted-payload), Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework over the bus the payload depends on.

The host–payload boundary is a direct supplier/service-provider relationship in hosted-payload arrangements; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework around the gateway services payload traffic traverses.

Visiting-vehicle operators are direct service providers connected via high-trust mechanical and data interfaces; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework over commissioning handshakes, umbilicals, and maintenance tools.

Launch-vehicle operators, range networks, and EGSE suppliers are direct service providers sharing transient but high-trust interfaces with the payload; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework over commissioning links and shared lab networks.

Rideshare partner operators co-resident on the launch infrastructure are direct service providers; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework around shared deployer controllers, common logging/telemetry collectors, and cross-connected lab assets.

Hardware backdoors (test/scan chains, boot-strap modes, persistent JTAG/SWD/UART, FPGA/ASIC inserted logic) originate at hardware suppliers; Art. 21(2)(d)'s supplier-relationship security obligation governs the contractual and technical posture around scan-chain disablement and test-mode hardening.

Software backdoors are sometimes introduced at FSW-vendor or SDR-firmware-vendor sites; Art. 21(2)(d)'s supplier-relationship security obligation governs the vetting and assurance posture across those vendors.

Commercial ground-station-as-a-service providers are direct service providers under Art. 21(2)(d); the obligation governs the trust framework, vetting, and security expectations the entity places on those relationships, including how providers police front-company misuse.

Commercial ground stations, hosted modems, and cloud-integrated GS services are direct service providers; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework between them and the entity, including provider-portal and shared-management-plane risks.

When a hosted-payload bus operator or rideshare host is in the entity's supplier graph, Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework around weak segmentation and shared ground paths the technique exploits.

Keys flow through contractor support channels, training datasets, and key-loading procedures involving suppliers; supplier-relationship security under Art. 21(2)(d) bounds where they may be exposed.

Staging on third-party provider portals, leased ground-station file drops, and partner automation repos rides supplier and service-provider trust boundaries; supplier-relationship security under Art. 21(2)(d) governs the integrity expectations for those touchpoints.

Firmware reconnaissance leans heavily on vendor reference packages, public evaluation boards, and leaked manufacturing files; supplier-relationship security under Art. 21(2)(d) is the obligation that constrains how those artefacts move between integrators and the entity.

End-to-end supplier mapping (manufacturers, integrators, calibration houses, logistics, depot repairs, key-loading) is the very asset class Art. 21(2)(d)'s supplier-relationship security obligation governs, including the security-related aspects of those relationships.

Hardware-supplier relationships (component sources, screening houses, FPGA IP vendors, depot repair) are exactly the supplier-relationship security obligation Art. 21(2)(d) covers, including counterfeit screening and waiver-driven trust gaps.

Dependency confusion, typosquatting, and CI artefact poisoning ride supplier and service-provider relationships (registries, CDNs, COTS vendors); supply-chain security under Art. 21(2)(d) is the obligation that constrains the trust framework around them.

Mapping primes/subs, MSPs, ground-network operators, cloud tenants, and remote-access holders is the very topology Art. 21(2)(d)'s supplier-relationship security obligation requires the entity to govern.