We Speak Supply Chain
We Speak Supply Chain
Most explanations of the Cyber Resilience Act are written for the company that ships the finished product. If you supply components into that product, those explanations tend to leave you with the impression that this is somebody else’s problem.
It isn’t, and the reason is fairly simple. The regulatory duty sits with the manufacturer who places the product on the EU market. The evidence that satisfies that duty has to come from everyone upstream of them. If you sell libraries, SDKs, modules, chipsets with firmware, middleware or embedded components, you are sitting inside somebody else’s conformity file. In practice, they will want your cooperation to support their due-diligence and compliance activities, and are likely to ask for it.
The timing is closer than it looks
Full application of Regulation (EU) 2024/2847 arrives on 11 December 2027. Before that, on 11 September 2026, the Article 14 reporting obligations kick in for actively exploited vulnerabilities and severe incidents.
December 2027 sounds comfortable until you think about design cycles. An industrial controller, a drone, a smart watch, or a network appliance being designed now will reach the market well after the regulation applies. The component decisions for those products are being taken today, and the procurement requirements are being written today too. In a lot of cases you are already being evaluated, quietly, and nobody has told you.
Are you a manufacturer, or are you in someone else’s file?
Worth settling this early, because it changes what you owe and to whom.
Article 3(1) defines a product with digital elements to include software or hardware components placed on the market separately. So a component sold as its own commercial offering is a product in its own right. If that describes what you do, you are probably a manufacturer under the CRA, and you must meet the relevant obligations: Annex I essential requirements, Annex VII technical documentation, an EU Declaration of Conformity, CE marking, a declared support period and Article 14 reporting. The specific conformity assessment route is determined by your product’s classification.
If you supply components intended only for integration into another product, you may not be the party ‘placing the product on the market’ as defined by the CRA; furthermore, the Regulation provides specific accommodations for tailor-made products agreed between a manufacturer and a business user, particularly regarding secure-by-default configurations and security update delivery. That is a narrower relief than it sounds. Your customer still carries Article 13(5), the duty to exercise due diligence on the third party components they integrate. The way they discharge it is by asking you for things and then writing those things into the contract.
What they are going to ask for
This checklist is forming across European procurement right now, but it is more useful to read it as a requirements specification than as a compliance list.
Artefact | Legal hook | What it means for you |
|---|---|---|
Machine-readable SBOM | Annex I, Part II(1) | Documentation of top-level dependencies, at minimum, in a commonly used and machine-readable format. |
Declared support period | At least five years unless the expected lifetime is shorter. Stated, not implied. | |
End-of-support date | Your customer has to tell their users. If you are vague, their chain breaks. | |
Coordinated vulnerability disclosure policy | Annex I, Part II | A published policy and a contact point that answers. |
Security updates, free and separate | Annex I, Part II | Fixes cannot sit behind a paid tier or a feature upgrade. |
Secure default configuration | Annex I, Part I | Shipped secure rather than hardened later by the integrator. |
A way to receive reports from your customer | When they find a vulnerability in your component they must report it to you, and share any fix they wrote. | |
EU Declaration of Conformity and CE mark | Where the component is itself in scope. Increasingly a condition of the purchase order. |
None of this is really too exotic, but the difficulty is that most suppliers can produce about half of it, and only with a few weeks of notice.
The part that will change your contracts
Article 14 gives a manufacturer 24 hours to send an early warning to the relevant Computer Security Incident Response Team (CSIRT) and the European Union Agency for Cybersecurity (ENISA) once they become aware of an actively exploited vulnerability in their product. A fuller notification follows within 72 hours, and a final report within 14 days of a corrective measure being available.
Now put the vulnerability inside your component, inside their product.
They cannot hold a 24 hour clock if your security team replies in ten working days. They cannot describe the fix if you have not told them one exists. They cannot assess exploitation if you triage monthly. So they are not going to rely on goodwill. They are going to put a notification service level into the supply agreement, with hours rather than weeks, advance notice of embargoed fixes, and consequences if you are late.
That clause is coming. It is a lot cheaper to be ready for it than to renegotiate it later, with a customer who has just missed a statutory deadline because of you.
The flip side is worth saying plainly: A supply agreement drafted by your customer’s counsel will allocate the risk to you, and it will do so generously. Terms written before the CRA existed are the other half of the exposure. They will say nothing about SBOM delivery, notification windows, support periods, end-of-support notice or what happens when a component is designed out.
Open source in your stack
If your component bundles open source, you have inherited the exposure without inheriting anyone to hand it to.
The CRA is reasonably gentle here at the upstream end. Article 24 gives open source stewards a lighter regime, and genuinely non-commercial development sits outside scope entirely. That is good news for the project. It does not help you, because when you monetise a product that embeds that project, you are the commercial actor in the chain, and your customer’s due diligence stops at your door.
In practice this comes down to knowing what you ship. An SBOM you cannot generate on demand is not really an SBOM. A transitive dependency nobody has looked at is a vulnerability you will hear about from a customer, on a Friday, with the clock already running.
A reasonable order to do this in
- Work out, per component, whether you are a manufacturer under Article 3(1) or a supplier inside a customer’s file. Check Annex III and Annex IV, because the important and critical classifications raise the bar considerably.
- Generate SBOMs in the build pipeline rather than by hand.
- Decide on a support period and an end-of-support date, and publish them.
- Stand up a vulnerability intake that can receive reports from customers under Article 13(6) and from researchers under your disclosure policy.
- Build triage and notification that can work in hours, since your customers are on a 24 hour clock.
- Assemble Annex VII technical documentation, or at least the evidence pack that lets your customer assemble theirs.
- Review your supply contracts and standard terms before your customer rewrites them for you. Notification windows, SBOM delivery, support and end-of-support, and liability all need to be dealt with explicitly.
The commercial side
There is a slightly cynical reading of all this, which is sadly also the correct one. Every integrator in Europe is currently looking at a bill of materials and working out which suppliers will make conformity straightforward and which will turn it into a project. That assessment is happening whether or not anyone tells you the result.
Suppliers in the first column tend to keep the socket. Suppliers in the second column get designed out at the next refresh, without much of a conversation about it.
We speak supply chain
Comply.Land works on the CRA at the level where it is actually written, in the harmonised standards, the essential requirements and the technical documentation. We know what your customers are going to ask for, partly because we also help them write the questions.
If you supply components into the EU market, we can tell you where you sit in the obligation set, what is going to land on your desk, and what it takes to answer in a week rather than a quarter.
We also review supply contracts. That means reading what you have signed against what the regulation now requires, working out where the risk has quietly been moved onto you, and adapting the terms so that the obligations you accept are ones you can actually meet.
Notification windows, SBOM and evidence delivery, support periods, end-of-support notice, upstream reporting under Article 13(6), liability and indemnities. All of it is negotiable while the customer is still drafting. Much less so once they have signed twenty other suppliers to the same paper.
Get a supply chain readiness assessment
General information on Regulation (EU) 2024/2847, not legal advice. Article and Annex references are to the Cyber Resilience Act as published. What actually applies to you depends on your product, its classification and your role in the chain.