The Flow Down - How CRA Reaches Component Vendors

SECURITY BRIEF: We look at the CRA impact to component vendors and what it means for OT device suppliers.

The Cyber Resilience Act names one primary obligor: the manufacturer who places a product with digital elements on the EU market under its own name. Read narrowly, that puts the compliance burden on the device maker — the relay vendor, the RTU manufacturer, the drive OEM — and leaves the supply chain beneath them untouched. That narrow reading is already failing in practice, for two reasons. First, the regulation itself reaches deeper than the final product: components placed separately on the market are in scope in their own right, and Annex III explicitly classifies security-relevant silicon. Second, and faster-moving, the device makers’ obligations are being converted into contract terms and pushed down the bill of materials — to MCU vendors, FPGA suppliers, RTOS licensors, and protocol-stack maintainers — ahead of any regulatory deadline that binds those suppliers directly. This paper maps the transmission mechanism, the evidence that the cascade has already started, and the frictions that make silicon the place where flow-down clauses will be hardest to draft and hardest to honour.

The Transmission Mechanism

Three provisions convert a manufacturer-facing regulation into a supply-chain cascade.

•    Component due diligence. Article 13 obliges the manufacturer to exercise due diligence when integrating components sourced from third parties, and Annex I requires that the product be free of known exploitable vulnerabilities at the time it is placed on the market. A device maker cannot discharge either duty by inspection alone; it needs disclosure commitments from the component vendor — which means contract clauses. Alternatively the device vendor needs to ensure "due dligence" in assessing the risks of integrating these components into their products.

•    The SBOM requirement. Manufacturers must identify and document product components in a machine-readable software bill of materials. An SBOM assembled to conformity-assessment depth requires component-level inputs the integrator does not possess: the RTOS vendor’s dependency tree, the silicon vendor’s bundled firmware and driver stack, the versioning of ROM’d boot code. The SBOM duty is formally the integrator’s; the data is the supplier’s.

•    The upstream notification duty. As covered in “The Reporting Clock,” a manufacturer that identifies a vulnerability in an integrated third-party component must notify the component’s maker or maintainer. The duty presumes a functioning channel: a security contact that answers, an intake process that triages, and a contractually obligated supplier to deliver vulnerability resolutions.

The point is sharper than it first appears: the regulation does not require compliant components — it requires diligent integrators. The Commission’s own FAQ confirms that manufacturers are not obliged to integrate only CE-marked components, and that the inability to verify a component’s CRA status during the transition does not prevent its integration — due diligence through other means is the mechanism. The corollary cuts both ways. Component non-compliance is no bar to design-in, and component compliance is no discharge of the integrator’s duty: the Article 13(5) obligation is the integrator’s and non-delegable, assessed against the product’s intended and reasonably foreseeable use, and evidenced in the integrator’s own technical file. An attestation is evidence within due diligence, never a substitute for it. This is precisely why the obligation converts into contract — the integrator cannot outsource the duty, only the information needed to meet it.

Each conduit terminates in the same place: the master supply agreement. The CRA’s architects did not need to regulate component vendors directly; they needed only to make the integrator’s conformity depend on information and behaviour that integrators can obtain solely by contract. The market is doing the rest.

The CRA’s architects did not need to regulate component vendors directly. Non-compliant components can be used to build product outside of the EU. That said, the device supplier conformity depend on information that can be obtained solely by contract... or accept that risk themselves via execution of due diligence in assessing the security risks of integration of that component within their own applications. In the end, it is the obligation of the device supplier to ensure compliance for sales into the EU.

The Cascade Has Already Started

This is not a forecast. Tier-1 OT vendors are already amending supplier terms. Honeywell’s published supplier requirements for the EU Cyber Resilience Act instruct suppliers to provide CRA compliance attestations — or detailed compliance roadmaps — by Q4 2026 for all products and components supplied for integration into Honeywell products destined for the EU market, with reporting-process readiness expected by the September 2026 milestone and full compliance by December 2027. Note the dates: the attestation demand lands more than a year before the CRA’s essential requirements bind the integrator, and it binds suppliers who may face no direct CRA deadline at all for the specific part supplied. The contractual clock runs ahead of the regulatory one — which is precisely how flow-down always works. Component vendors who wait for “their” regulatory deadline will discover that their commercial deadline arrived first, set unilaterally in their customers’ procurement portals.

We expect equivalent language in the supplier terms of the other tier-1 automation vendors within two procurement cycles; several are understood to be circulating CRA questionnaires through their supplier-quality organisations now. For component vendors, the practical consequence is that the first CRA document most will sign is not a declaration of conformity — it is a customer’s attestation template, drafted by the customer’s counsel, scoped to the customer’s risk.

Silicon Is Not Out of Scope

A persistent assumption in the component tier is that the CRA is someone else’s regulation — that silicon is an input, not a product. The regulation says otherwise. Products with digital elements include components placed separately on the market, and Annex III assigns security-relevant silicon to conformity classes with real procedural consequences: microprocessors and microcontrollers with security-related functionalities sit in Important Class I; tamper-resistant microprocessors and microcontrollers in Class II, where external assessment applies; smartcards and secure elements in the Critical category, where certification schemes apply. Harmonised standards for the semiconductor entries are under development in CENELEC’s semiconductor and trusted-chips working group. A silicon vendor selling a secure-boot MCU into EU distribution is a CRA manufacturer for that part, with its own risk assessment, documentation, update, and reporting obligations — including the ten-year minimum availability of security updates under Article 13(9).

That baseline matters for the negotiation to come, because it defines what the silicon vendor already owes the world before any customer asks for more. The flow-down fight is not about whether the component vendor has CRA obligations. It is about the gap between the obligations the vendor owes for the component as placed on the market and the obligations the integrator’s attestation template asks it to assume.

The Silicon-Specific Frictions

Flow-down clauses drafted for software suppliers transplant poorly to silicon. Four frictions recur.

Errata are not CVEs

Silicon vendors have run a disclosure regime for decades — the errata sheet — and it evolved to serve functional correctness, not security. Errata are published on vendor timelines, sometimes under NDA, frequently without severity characterisation, and almost never cross-referenced into vulnerability databases. Yet an erratum in a memory-protection unit or a debug-access lock is, in CRA terms, a potential vulnerability — and Annex I’s requirement that products ship free of known exploitable vulnerabilities makes the integrator responsible for clearing the errata sheet at placement. A flow-down clause must therefore bridge two disclosure cultures: it needs the silicon vendor to assess errata for security impact and disclose on a cadence the integrator’s conformity process can consume.

ROM’d code is unpatchable by construction

Mask-ROM boot code, immutable first-stage loaders, and fused configuration cannot be corrected in fielded parts. Where a vulnerability lands in ROM, the vendor’s only remedies are a new silicon revision and mitigation guidance — and the integrator inherits a permanent, documented residual risk in every fielded unit. Contracts drafted around “supplier shall remediate” language have no sensible application here; what the integrator actually needs is early disclosure, credible mitigation engineering, and revision-availability commitments.

Bitstreams and provenance

FPGA-based designs add a layer the CRA’s drafters plainly did not contemplate: the configuration bitstream, generated by vendor toolchains, sometimes encrypted, and dependent on IP cores of mixed and occasionally opaque origin. As argued in “The Provenance Problem,” provenance is becoming a supply-chain discipline of its own; the SBOM duty forces the question of whether a bitstream’s constituent cores are enumerable at all, and licence terms for third-party IP cores frequently prohibit exactly the disclosure the integrator now needs.

EOL silicon and the last-time buy

The sharpest collision is with practices we examined in “Rationed by the Boom” and “The Bridge and the Redesign.” A last-time buy converts a discontinued part into years of production inventory — and, under the CRA, into a long-tail liability with a vanishing counterparty. Devices built from LTB stock will be placed on the EU market for years after the silicon vendor has sunset the part, its support organisation, and possibly its security contact. The integrator’s reporting and update duties persist; the upstream relationship those duties assume does not. Flow-down clauses negotiated today are the only instrument that can extend disclosure and support past discontinuance — which makes EOL terms, historically a procurement afterthought, a conformity-critical clause.

The Attestation Asymmetry

Attestation templates now circulating ask component vendors to warrant “CRA compliance” without specifying compliance with what, for which part, in which use. The asymmetry is structural: the silicon vendor’s own CRA obligations attach to the component as placed on the market — its intended and reasonably foreseeable use, its declared support period, its documentation. The integrator’s template typically reaches further: application-specific assurances the vendor cannot give (the vendor does not know the part is running a SIL 2 dosing loop), support horizons matched to the integrator’s 15-to-20-year device commitments rather than the vendor’s declared window, SBOM depth and refresh cadences beyond the vendor’s publication practice, and warranty coverage for parts that reached the integrator through distribution or brokerage channels the vendor never saw.

For component vendors, the negotiating posture we recommend mirrors the concede-then-contest structure we use elsewhere: concede the baseline — the component’s own conformity, errata-security assessment, notification channels, update availability within the declared support period — and contest the constraint, refusing application-level warranties and open-ended support horizons while offering the integrator what it actually needs for conformity: disclosure, documentation, and dated commitments. For integrators, the symmetric advice: an attestation the supplier cannot honour is not risk transfer, it is risk concealment. A narrower attestation that is true is worth more at conformity assessment than a broad one that is aspirational.