A regulation for manufacturers, an effect on everyone
Read the Cyber Resilience Act on its own terms and it looks like somebody else's problem. Regulation (EU) 2024/2847 sets duties for manufacturers, importers and distributors of products with digital elements. If your organisation buys firewalls, deploys connected devices, runs vendor firmware and integrates third-party software, you are none of those things. There is no CRA obligation pointing at you as a user.
That reading is correct and it is also not the whole picture, for three reasons.
The first is that from 11 December 2027, CRA conformity becomes a hard prerequisite for placing a product with digital elements on the EU market, expressed through the conformity assessment and the CE marking. Products that cannot demonstrate it cannot legally be sold to you. Supplier viability is now a security question with a legal deadline attached.
The second is that if you are an essential or important entity under NIS2, you already carry supply-chain security duties covering the security-related aspects of your relationships with direct suppliers and service providers (Art. 21(2)(d)). The Directive goes further than a policy requirement: when deciding which measures are appropriate, you must take into account the vulnerabilities specific to each direct supplier and the overall quality of their products and cybersecurity practices, including their secure development procedures (Art. 21(3)). That last clause is the one that matters here, because a supplier's CRA posture is among the cleanest available evidence of exactly what it asks about.
The third is the uncomfortable one. Many organisations that think of themselves as buyers are manufacturers under the CRA without having noticed. See who the CRA applies to.
Three ways CRA exposure reaches an organisation that does not think of itself as a manufacturer
You put your name on it. The CRA places the manufacturer obligations on the entity that places the product on the EU market under its own name or trademark. If you buy white-label hardware or an OEM component and sell or supply the finished product under your brand, you are the manufacturer for CRA purposes, whoever built the underlying technology. The regulatory burden follows the brand on the box.
You integrate somebody else's components. Manufacturers integrating components sourced from third parties are required to exercise due diligence so those components do not compromise the cybersecurity of the product, and that duty extends explicitly to free and open-source components that were never placed on the market commercially (Art. 13(5)). If you build a product with digital elements at all, your supply chain is inside your own obligation, not adjacent to it.
You buy and deploy. Here you have no CRA duty. You have a NIS2 duty, a DORA duty if you are a financial entity, and a commercial interest in not buying a product that becomes unsellable and unsupported in 2027. Those are enough.
One exception worth knowing if you are a public body. Article 5(2) requires Member States to ensure that, where in-scope products are procured, compliance with the Annex I essential requirements and the manufacturer's ability to handle vulnerabilities effectively are taken into consideration in the procurement process. That is an obligation on Member States rather than on you directly, but if you procure under public procurement rules it will reach your tender criteria. Article 5(1) also preserves Member States' freedom to impose additional cybersecurity requirements for specific procurement or use purposes, including national security and defence.
Work out which of the three describes each product line before you write a single supplier question, because the answer changes whether you are exercising a legal obligation or a procurement preference. Both are legitimate. They are not the same conversation.
What you can legitimately ask today, and what you cannot
This is where most CRA supplier outreach goes wrong, and it goes wrong in a way that damages your credibility with vendors.
You cannot ask a supplier today for a CRA declaration of conformity or a CE marking on CRA grounds. Those obligations apply from 11 December 2027. A vendor that produces one now is either confused or telling you something that is not true, and a questionnaire that demands one signals that you have not read the regulation.
You can ask about the two things that are already real. Reporting obligations that apply from 11 September 2026, which means a manufacturer's ability to detect and report an actively exploited vulnerability is a present-tense capability, not a future commitment. And you can ask about readiness for the 2027 obligations, which is a legitimate question about a supplier's trajectory rather than their current legal status.
The distinction matters commercially. A question set that separates "what is true today" from "what is your plan for 2027" gets substantive answers. One that treats every CRA obligation as already in force gets defensive boilerplate.
The supplier question set
Ten questions. Scoped to what is answerable in August 2026, ordered so the early answers tell you whether the later ones are worth asking.
| # | Question | What a useful answer looks like |
|---|---|---|
| 1 | Do you consider this product to be a product with digital elements in scope of the CRA, and on what basis? | A reasoned yes or no citing the intended use and data connection, not a one-word answer. A supplier who cannot answer this has not started. |
| 2 | Who is the manufacturer for CRA purposes, and do you place this product on the EU market under your own name or trademark? | Clarity on whether your counterparty carries the obligation or is passing it upstream. |
| 3 | If you are established outside the EU, who is your authorised representative or responsible economic operator in the Union? | A named legal entity with a written mandate. |
| 4 | What is your process for meeting the Article 14 reporting obligations that apply from 11 September 2026? | A named owner, an escalation path with out-of-hours coverage, and a routing decision on which national CSIRT coordinates. |
| 5 | Will you notify us directly when you report an actively exploited vulnerability affecting a product we operate, and on what timeline? | The CRA routes reports to authorities, not to you. Customer notification is a contractual matter and you have to ask for it. |
| 6 | Do you maintain a software bill of materials for this product, in what format, and will you share it? | A machine-readable format, kept current per release. "On request, in PDF" is a soft no. |
| 7 | What is the declared support period for this product, and what does it cover? | A stated duration with a defined scope of free security updates. Under the CRA the support period reflects how long the product is expected to be in use, and is generally expected to be at least five years unless the product's expected use is shorter (Art. 13(8)). |
| 8 | What is your product classification under the CRA, and which conformity route follows from it? | Default, important class I, important class II or critical, with the reasoning. This tells you how much work the supplier is facing before 2027. |
| 9 | What is your plan and timeline for conformity assessment ahead of 11 December 2027? | A dated plan. "We are monitoring developments" in August 2026 is a risk signal for a product you intend to still be running in 2028. |
| 10 | What is your coordinated vulnerability disclosure process, and where do we send a finding? | A published contact and a stated response commitment. |
Questions 1 to 5 are the ones with present-tense answers. If a supplier stumbles on those, questions 6 to 10 will not save them.
The clauses worth having now
Contract language is the only mechanism that converts a supplier's regulatory posture into something you can rely on. The CRA does not give you rights against your vendor. Your contract does.
Direct customer notification. Article 14 routes reports to ENISA and the coordinating national CSIRT. Nothing in that mechanism tells you, the operator of the affected product, that it happened. If you want to know inside the same 24 to 72 hour window your supplier is working to, write it into the contract with a stated deadline.
SBOM delivery and currency. Delivery on each release, in a machine-readable format, not on request.
Support period commitment and end-of-support notice. A declared support period with a minimum notice before it ends, so a product going unsupported becomes a planned replacement rather than a discovery.
Security update commitment. Free security updates for the duration of the support period, with a stated remediation target for critical issues.
Conformity milestone. For products you expect to still be operating after 11 December 2027, a commitment to conformity assessment with a date, and a remedy if it is missed.
Audit or evidence right, proportionate. The right to see the technical documentation or a summary of it, scoped so it is actually negotiable.
Three of these are worth their own line in a renewal even if you drop everything else: direct notification, SBOM delivery, and end-of-support notice.
Reading the answers
The answers are more informative than the scores. A few patterns worth recognising.
A supplier who answers question 1 with a confident no and a reasoned basis is often in better shape than one who answers a vague yes. Scope analysis is work, and the ones who have done it can explain it.
A supplier who names a person for question 4 is telling you something real. A supplier who describes a process without naming anyone has a document, not a capability, and the 24-hour clock does not read documents.
A supplier who declines to share an SBOM on confidentiality grounds is making a defensible commercial argument and a weak security one. It is a negotiating position, not a dead end.
A supplier whose 2027 plan is a monitoring statement should be assumed to be at the back of the queue for notified body capacity if their products fall into the important or critical classes. That is a supply risk, not just a compliance one.
When the supplier is out of scope
Plenty of your vendors are genuinely outside the CRA and will say so correctly.
Standalone software-as-a-service that operates independently of a physical product sits outside scope. A cloud service is caught only where it qualifies as a remote data-processing solution, meaning the physical product functionally depends on that remote processing to perform a core function and the remote software is developed by or under the responsibility of the manufacturer. If the product calls a cloud service for an incidental feature, the cloud component is not in scope. If the product cannot function without it, it is.
Products already governed by sector-specific rules, including medical devices, motor vehicles and civil aviation, are excluded. Non-commercial open-source software developed outside a commercial activity sits largely outside scope, though the CRA creates a distinct category of open-source software steward with its own lighter duties, and commercial integrators who ship that code in a product remain fully liable for it.
An out-of-scope answer is not the end of the conversation, it just moves the conversation back to your existing framework. Your NIS2 supply-chain duty does not have a CRA carve-out. A SaaS vendor outside the CRA is still inside your third-party risk programme.
Run this once, not once per framework
The failure mode here is predictable. CRA supplier questions get sent as a new questionnaire, from a new owner, to a supplier list that already received a NIS2 supply-chain questionnaire six months ago and a DORA register request before that. The vendor answers the third one worse than the first. Your evidence sits in three spreadsheets with three refresh dates and no shared view of which supplier is failing which obligation.
The CRA questions above are not a separate assessment. They are additional dimensions on a supplier record you already keep. Question 7 is a support-period field. Question 6 is a document you either hold or do not. Question 4 is a capability attestation with a review date.
In Acuna, this is a third-party risk exercise rather than a compliance project. The questions run as an assessment campaign against the supplier records you already maintain, and the answers attach to the vendor rather than to a spreadsheet, in the same place as the campaigns and audit trail you already run for NIS2, DORA and ISO 27001. The supplier record stays one record, whichever regime prompted the question.
That is the argument for treating the CRA as another set of requirements on one control set. The enemy here is the silo, not the vendor.
Regulatory References