Art. 21(3)

Primary mapping to Art. 21(2)(d) covers supplier-relationship security for the AI/ML training-data pipeline. Art. 21(3) extends that obligation to the supplier-quality assessment itself (vulnerabilities of direct suppliers, secure development procedures), which is exactly the procedural lever needed to detect and remediate poisoned training data flowing from upstream data brokers, annotation services, and pretrained-model vendors.

Primary mapping to Art. 21(2)(d) governs supplier security for SDA/SSA telemetry feeds. Art. 21(3) procedurally extends that to vulnerability assessment and secure-development scrutiny of the SDA vendor, which is where the corruption-or-overload pre-conditions are introduced.

Cross-supplier coordination of cooperative implants is the kind of supplier-specific vulnerability Art. 21(3) requires the entity to consider when sizing reliance on combinations of vendors whose products co-resident on the same vehicle.

Primary mapping to Art. 21(2)(d) addresses the supplier of the affected hardware/firmware. Art. 21(3) procedurally extends that to assessment of the supplier's secure-development practices and known vulnerabilities, since hardware/firmware corruption typically exploits weaknesses introduced during the supplier's manufacturing or build pipeline.

Primary mapping to Art. 21(2)(d) covers the upstream silicon/board vendor. Art. 21(3) procedurally extends to assessment of the supplier's secure-design practices, since design flaws are introduced by suppliers and must be evaluated as part of supplier-quality scrutiny rather than only at the entity's integration boundary.

Primary mapping to Art. 21(2)(d) covers code-flaw exposure via the software supplier relationship. Art. 21(3) procedurally extends to assessment of that supplier's vulnerability-handling practices and secure-development quality, the lever the entity uses to drive upstream remediation.

Patch cadence, advisory quality, and vulnerability-disclosure practice vary dramatically by COTS/FOSS supplier; Art. 21(3) requires the entity to take those supplier-specific vulnerabilities into account when sizing its component reliance.

Primary mapping to Art. 21(2)(d) covers the data-supplier relationship for AI/ML training inputs. Art. 21(3) extends that obligation to the supplier's overall security quality, since the training-data poisoning surface depends on the data broker's secure-development discipline more than on the entity's own controls.

Primary mapping to Art. 21(2)(d) covers compromised developer-site exposure via contractor and integrator relationships. Art. 21(3) procedurally extends to assessment of those suppliers' secure-development environments and vulnerability-management practices, since compromised dev sites are an attribute of supplier security quality.

The technique exploits varying segmentation and monitoring across partner sites — supplier-specific cybersecurity quality is exactly what Art. 21(3) requires entities to consider when relying on third-party infrastructure for TT&C and payload feeds.

Primary mapping to Art. 21(2)(d) covers the payload-vendor relationship that supplies the implanted code or controls the gateway. Art. 21(3) extends to scrutiny of that vendor's secure-development practices and vulnerability handling, the procedural mechanism for catching covert exfil paths planted upstream of integration.

The technique exploits trust assumed at where each supplier hands off to the next; Art. 21(3) is the obligation that requires the entity to consider supplier-specific vulnerabilities and the overall quality of supplier cybersecurity practices when sizing that trust.

Vulnerability profile of CI runners, registries, and IDE plugin ecosystems varies dramatically by supplier; Art. 21(3) requires the entity to take those supplier-specific vulnerabilities into account when relying on third-party tooling.

Maturity of the signing service, version-rollback policy, and update-metadata integrity vary by supplier; Art. 21(3) requires the entity to consider those supplier-specific vulnerabilities when sizing software-supply-chain risk.

Counterfeit-screening posture, fuse-policy maturity, and golden-image custody differ by supplier; Art. 21(3) requires the entity to consider those supplier-specific vulnerabilities when sizing hardware-supply-chain risk.

Primary mapping to Art. 21(2)(d) covers the SDR vendor relationship. Art. 21(3) extends procedurally to assessment of that vendor's secure-build and vulnerability-handling practices, since SDR compromises typically ride trojanized waveform updates or vendor configuration profiles delivered through the supplier channel.

Primary mapping to Art. 21(2)(d) covers the constellation-partner relationship that supplies the trusted neighbor. Art. 21(3) extends to assessment of that partner's secure-development practices and disclosure procedures, the procedural instrument the entity uses to verify cross-link counterparties.

Primary mapping to Art. 21(2)(d) covers the commercial ground-station-as-a-service supplier. Art. 21(3) procedurally extends to assessment of that supplier's secure-operations and vulnerability-handling practices, the lever the operator uses to enforce cybersecurity quality on the GSaaS provider.

Servicing-vehicle operator's segmentation, key-loading discipline, and procedure rigour vary by supplier; Art. 21(3) requires the entity to take those supplier-specific vulnerabilities into account when authorising OSAM contact.

Differences in keying, procedures, and scheduling between the payload operator and the bus operator are exactly the supplier-specific vulnerabilities Art. 21(3) requires the entity to consider when hosting third-party payloads.

A compromised partner inheriting approved routes is the canonical scenario Art. 21(3) covers: vulnerabilities specific to each direct supplier (and the variable quality of their cybersecurity practices) propagate into the entity's enclaves through trusted channels.

Variations in process rigour, identity proofing, and toolchains across collaborator institutions are the canonical supplier-specific vulnerabilities Art. 21(3) requires the entity to consider when relying on cross-org pipelines.

Compromise of a vendor's enterprise/build environment escalates directly into mission systems via approved consoles and managed SaaS — the canonical supplier-specific vulnerability Art. 21(3) requires the entity to factor in.

Primary mapping to Art. 21(2)(d) covers the user-segment supplier relationship. Art. 21(3) extends to assessment of those user-segment suppliers' secure-development practices and disclosure obligations, since user-segment compromises propagate from supplier-side weaknesses into the operator's environment.

Primary mapping to Art. 21(2)(d) covers the auxiliary-device vendor relationship (e.g. EGSE, calibration tooling, external storage). Art. 21(3) procedurally extends to scrutiny of those vendors' secure-development quality, since auxiliary-device compromise rides through supplier-side firmware and software pipelines.

Primary mapping to Art. 21(2)(d) covers the AIT facility and integrator relationships at the launch site. Art. 21(3) procedurally extends to assessment of those suppliers' secure-development and operations practices — the lever applicable to cleanroom operators, EGSE vendors, and pad integrators where ATLO compromises happen.

Host SV's segmentation and onboard-network discipline vary by operator; Art. 21(3) requires the payload's parent entity to consider those host-specific vulnerabilities when riding the bus.

Payload-provider segmentation maturity and key-management discipline vary by supplier; Art. 21(3) requires the entity to take those payload-specific vulnerabilities into account when riding the host bus.

Primary mapping to Art. 21(2)(d) covers the visiting-vehicle operator (cargo, OSAM servicer, crewed visitor) as a supplier of the docking interface. Art. 21(3) extends to assessment of that operator's secure-development practices and vulnerability handling, the procedural mechanism that constrains rendezvous and proximity-operations counterparties.

Primary mapping to Art. 21(2)(d) covers the launch-vehicle provider as a supplier of the integration-period interface. Art. 21(3) procedurally extends to scrutiny of the launch provider's secure-development practices for its dispenser and avionics, the lever the spacecraft operator uses for pre-separation interface assurance.

Rideshare-partner isolation maturity (data-bus partitioning, deployer-controller segmentation, common-logger boundaries) varies by partner; Art. 21(3) requires the entity to take those partner-specific vulnerabilities into account when its payload shares infrastructure pre-separation.

Hardware suppliers vary widely in scan-chain hardening, fuse policy, and FPGA-IP integrity; Art. 21(3) requires the entity to take those supplier-specific vulnerabilities into account when relying on third-party silicon.

Primary mapping to Art. 21(2)(d) covers the software-supply-chain origin where the backdoor is planted. Art. 21(3) procedurally extends to assessment of the supplier's secure-development practices and disclosure procedures, the only lever for catching backdoors that ship signed and provenance-clean from the supplier's build environment.

Vetting strength, multi-tenant isolation, and management-plane hygiene at the commercial ground-network provider are the supplier-specific vulnerabilities Art. 21(3) requires the entity to consider when relying on third-party RF infrastructure.

Multi-tenant configuration bleed, weak vetting that admits front companies, and provider-portal exposure are exactly the supplier-specific vulnerabilities Art. 21(3) requires the entity to take into account when reliant on third-party ground services.

Cross-organisation segmentation and key-management practices at the third-party operator are the supplier-specific vulnerabilities Art. 21(3) requires the entity to consider when its mission rides shared infrastructure.

Primary mapping to Art. 21(2)(d) covers the supplier relationship that exposed the cryptographic-key material (key-management vendor, COMSEC custodian, HSM/CA provider). Art. 21(3) procedurally extends to assessment of that supplier's secure-development and key-handling quality, the procedural instrument addressing supplier-side key compromise.

Primary mapping to Art. 21(2)(d) covers third-party tooling and exploit-acquisition supply paths the adversary leverages. Art. 21(3) procedurally extends to assessment of those tooling suppliers' secure-development practices, since the entity's operational tooling and uplink chain inherit the supplier's vulnerability-management discipline.

Primary mapping to Art. 21(2)(d) covers the firmware-vendor relationship that leaks reference packages and evaluation board firmware. Art. 21(3) procedurally extends to assessment of those vendors' secure-handling practices for engineering artefacts, the procedural mechanism that constrains how such artefacts move between integrators.

The technique highlights waiver-driven and depot-relaxed control points; supplier-specific vulnerability assessment and consideration of the overall quality of supplier cybersecurity practices under Art. 21(3) is the obligation that requires those weak points be triaged.

Counterfeit screening thresholds, golden-bitstream handling, and stepping/lot-specific weaknesses are the kind of supplier-specific vulnerability profile Art. 21(3) requires the entity to consider when relying on a hardware supplier.

Primary mapping to Art. 21(2)(d) covers the software-supplier relationship that exposes module names, API surfaces, and version metadata via reconnaissance. Art. 21(3) procedurally extends to assessment of that supplier's vulnerability-handling and disclosure procedures, since the recon surface mirrors what the supplier publishes about itself.

Cross-domain trust bridges (shared SSO/IdP providers, service accounts spanning enclaves) and vetting weaknesses in low-tier suppliers are exactly the supplier-specific vulnerability profile Art. 21(3) requires the entity to factor in when sizing its third-party reliance.