Annex I, Part II, (1)

AI/ML training-data poisoning via third-party component pipelines (primary mapping: Art. 13(5)) requires SBOM-grade documentation of training data and model artifacts; (1)'s component-and-vulnerability-identification obligation extends to ML pipeline components.

mitigates DOWNGRADE: SBOM/component documentation under Part II (1) is domain-relevant for tracing which modules exist, but does not interdict coordinated multi-component collusion since each component is benign in isolation; the operative defenses are runtime behavioral monitoring and integrity verification.

Component identification at hardware/firmware granularity surfaces the population that hardware-firmware-corruption attacks ride through; SBOM-style hardware inventories are the manufacturer's traceability control.

Manufacturer obligation to identify and document vulnerabilities in components covers design flaws and errata in supplied silicon, board and programmable logic.

Component and vulnerability identification (including SBOM) gives the manufacturer the visibility needed to surface code-flaw classes in flight, ground or library code.

Component identification covers OS-layer components (kernels, schedulers, device drivers); the manufacturer's vulnerability inventory must include these primitives.

Component identification (SBOM) is what gives the manufacturer the visibility needed to map known vulnerabilities to deployed products before adversaries do.

ML-model exploitation (primary mappings: Part II, (3) + Art. 13(5)) triggers (1)'s SBOM/component-documentation obligation for ML pipeline components and model dependencies.

Manufacturer obligation to identify and document components (including via SBOM) is the upstream visibility discipline that surfaces compromised components before they ship in the product, the reverse of the asymmetry adversary supply-chain compromise exploits.

Software dependencies and dev-tool components must be enumerated in the manufacturer's component identification and SBOM under Annex I, Part II, (1); poisoned dependencies are surfaced by the same SBOM discipline that documents legitimate ones.

Software-supply-chain compromise (primary mappings: Part II, (7) + Art. 13(5) + Art. 13(8)) makes (1)'s SBOM obligation foundational — the manufacturer cannot exercise due diligence on third-party software without a documented component inventory.

Component identification at hardware granularity (lot, configuration, test history) underpins the lifecycle traceability and tamper-detection workflows that resist hardware-supply-chain compromise.

FPGA bitstreams, software flowgraphs and waveform packages are components that must be enumerated in the manufacturer's component identification under Annex I, Part II, (1).

Trusted-relationship initial-access exploitation (primary mapping: Art. 13(5)) implies SBOM-grade documentation of partner-provided components and access paths under (1).

This technique abuses artifacts and components that collaborators deliver into mission workflows across institutions with differing toolchains, and the article requires identifying and documenting the vulnerabilities and components in products with digital elements, including a machine-readable software bill of materials covering at least top-level dependencies. That component and dependency documentation gives the prime visibility into which partner-supplied elements enter its products, which addresses the technique without blocking the injection path itself.

Because the Vendor technique turns vendor-delivered firmware, bitstreams, and patches into an attack path, the requirement to identify and document vulnerabilities and components, including an SBOM covering at least top-level dependencies, makes those vendor-supplied components and their known weaknesses enumerable rather than opaque. This documentation addresses the technique by giving the operator a tracked inventory of the vendor dependencies an attacker would have to subvert, though it does not by itself control the vendor's access routes.

Assembly/test/launch-operation trusted-relationship initial-access (primary mapping: Art. 13(5)) requires SBOM documentation of integrated test-equipment and ATLO-tooling components under (1).

Component identification at hardware granularity supports lifecycle traceability needed to detect hardware-backdoor classes at delivery and during operations.

Software-backdoor persistence (primary mappings: Part II, (3) + Art. 13(5)) requires SBOM-grade documentation under (1) so persistent third-party-derived modules are visible to the manufacturer.

Firmware reconnaissance harvests vendor reference packages, evaluation-board firmware and bootstrap materials to construct exploit catalogs. CRA Annex I, Part II, (1) requires manufacturers to identify and document components and vulnerabilities (including via SBOM), which is the upstream discipline that surfaces the same component knowledge to the manufacturer's vulnerability-handling pipeline before adversary recon is converted into operational use.

Manufacturer obligation to identify and document components (SBOM) is what makes supply-chain visibility complete on the manufacturer side; reconnaissance against the same chain produces a less-asymmetric picture when the manufacturer maintains its own component inventory.

Hardware reconnaissance enumerates components, screening, test history and configuration state; manufacturers under Annex I, Part II, (1) must identify and document those same components in an SBOM-style inventory, which is the procedural lever that makes lifecycle traceability and tamper-detection workflows operationally viable.

Software-factory reconnaissance enumerates source location, dependencies and signing pipelines; manufacturers under Annex I, Part II, (1) must identify and document software components (SBOM), which is the same surface, owned by the manufacturer and used to drive vulnerability handling rather than adversary planning.

Manufacturer obligation to identify and document vulnerabilities and components is precisely what closes the gap an adversary's known-vulnerability reconnaissance attempts to exploit: when the manufacturer's vulnerability inventory is current, the adversary's recon yields no asymmetric advantage.

Open-source-software reconnaissance (primary mapping: Art. 13(5)) implies (1)'s SBOM obligation as the primary artifact OSS reconnaissance targets — the manufacturer's defense relies on having documented OSS components.