CRA supply chain requirements: what to ask vendors and suppliers
The Cyber Resilience Act makes you responsible for components you did not write. Here is what to ask vendors and how to document what you find.
Most Cyber Resilience Act guidance focuses on what you build. Just as much of the regulation's practical burden sits in what you buy: the microcontroller, the cellular module, the licensed protocol stack, the open-source library, all of it becomes part of your product's attack surface whether or not your team wrote a line of it.
TL;DR: Under the CRA, the manufacturer is responsible for the security of the finished product, including every third-party and open-source component inside it. That means asking vendors for current component inventories and vulnerability-disclosure commitments, but it does not mean you can outsource the obligation itself, you still need your own SBOM and monitoring regardless of what a supplier promises.
Which CRA requirements apply to my supply chain?
The core obligation is straightforward to state and harder to operationalise: as the manufacturer, you must ensure that components you integrate into your product, whether a purchased radio module, a licensed protocol stack, or an open-source library, do not introduce vulnerabilities that make your finished product non-compliant. Regulation (EU) 2024/2847 places this responsibility on you regardless of whether the component was built in-house or sourced externally. Your product's Software Bill of Materials is the document that makes this obligation concrete, it names every component you are responsible for tracking.
What questions should I actually ask a vendor?
Four questions cover most of what matters. First, can they provide a current SBOM or accurate component and version list for whatever you are integrating, without one you cannot include their component in your own SBOM accurately. Second, what is their vulnerability disclosure process, do they have a defined channel and timeline for reporting known issues. Third, how quickly do they typically issue fixes once a vulnerability is confirmed, this tells you how much lag to expect between a CVE and a usable patch. Fourth, will they commit to notifying you directly within a defined window when something affecting their component is found, rather than expecting you to monitor public CVE feeds and hope you catch it. See our supply chain and vendor evaluation coverage for how this extends to evaluating compliance partners specifically.
Can I rely entirely on a vendor's compliance claims?
No, and this is the point teams most want to be true and least should rely on. A vendor's cooperation genuinely reduces your workload and risk, a supplier that maintains a clean SBOM and discloses promptly is worth real weight in a vendor selection decision. But the CRA's obligations attach to the manufacturer of the finished product, meaning you, not to any individual supplier. If a vendor's component turns out to have an undisclosed vulnerability, the reporting and remediation obligation for your product is still yours to meet, regardless of how the vendor behaved. Treat vendor assurances as an input to your own process, not a substitute for it.
How is this different from a one-time vendor audit?
A one-time audit answers "was this component clean when we integrated it." The CRA's actual requirement is closer to continuous awareness, a component that was clean at integration can have a new CVE disclosed a year later, and your obligation to know about it and act does not expire after the initial vendor vetting. This is why an SBOM tied to live vulnerability monitoring matters more than a supplier questionnaire completed once during procurement. Our CVE-to-patch pipeline walks through what that ongoing monitoring loop looks like end to end.
Does this apply differently to hardware components versus software components?
The underlying obligation is the same, know what you are shipping and whether it is currently exploitable, but the practical mechanics differ. Software and firmware components are covered directly by SBOM tooling, see our ESP-IDF SBOM walkthrough for a concrete example. Hardware components, chips, modules, and subassemblies, are harder to monitor for vulnerabilities through the same tooling and usually depend more heavily on the vendor's own disclosure commitments, which is exactly why the vendor-questions list above matters more for hardware suppliers than for open-source software, where you can often inspect the code yourself.
What should I document for a conformity assessment?
At minimum: a current SBOM naming every component and version in the product, evidence that the SBOM is actively monitored against vulnerability data rather than a static document, records of any vendor communications about known issues affecting components you use, and your own internal process for turning a supplier-reported or independently discovered vulnerability into a shipped fix. Whether you are pursuing self-assessment or a notified-body assessment, see our self-assessment versus notified body guide, this documentation trail is what an assessor or auditor will actually ask to see.
What about open-source components specifically?
Open-source components sit inside this same supply-chain obligation, but they carry their own nuance around who is responsible for what. We cover that distinction, and where the CRA's "open-source software steward" category fits in, separately in how the CRA treats open source software.
Where Scadable fits
Scadable builds and maintains the SBOM across your entire supply chain, hardware, firmware, open source, and licensed components alike, and watches it continuously against live vulnerability data so you are not depending on a vendor to tell you first. When something in your supply chain becomes exploitable, it flags it, helps get the fix built and backported, and tracks the reporting clock. If your product depends on components you did not write and you want real visibility into that risk, book a walkthrough.
Last reviewed: July 1, 2026.
Frequently asked questions
Which CRA requirements apply to my supply chain? As the manufacturer, you are responsible for ensuring that components you integrate, whether purchased chips, licensed software modules, or open-source packages, do not introduce vulnerabilities into your finished product. The obligation sits with you even though you did not write every component yourself.
What cybersecurity questions should I ask a vendor about CRA compliance? Ask for a current SBOM or component list for anything you integrate, their vulnerability disclosure and notification process, how quickly they issue fixes for known exploitable vulnerabilities, and whether they will commit to notifying you within a defined window when a vulnerability affecting their component is found.
Can I rely entirely on a vendor for CRA compliance? No. Vendor cooperation reduces your risk and workload, but the manufacturer of the finished product retains the CRA obligations for that product regardless of how much a supplier contributes. You need your own visibility into what components you use, not just a promise from a supplier.
Do I need to re-verify every component every time I ship? You need continuous monitoring, not a one-time check. A component that was clean at integration time can have a new vulnerability disclosed at any point in its lifecycle, so the requirement is an ongoing process tied to your SBOM, not a single supplier audit before launch.
What should I document about my supply chain for an assessment? A current SBOM identifying every component and version, evidence of vulnerability monitoring against that SBOM, records of vendor communications about known issues, and your own process for how a supplier-reported vulnerability turns into a fix for your fielded product.