The product ships.
The responsibility continues.

The CRA concerns products with digital elements made available on the EU market. Its scope includes relevant hardware and software, including components marketed separately and certain remote-processing functions integral to the product. The precise offering and applicable exclusions need to be assessed.

A UK manufacturer cannot settle the question by noting that its head office is outside the EU. Establish the market route, whose name the product is sold under and the responsibilities of manufacturer, importer and distributor. A business buying components for its own offering needs to understand what those dependencies mean for its product.

The regulation does not mean that every internal IT system, every cloud service or every item of open-source software automatically falls into the same category. Write down the scope decision and obtain advice where the product boundary or sector-specific regime is uncertain.

A component list becomes useful when an advisory can be connected to a version and an engineer who can assess it. A test result becomes useful when the product team understands its scope and the changes made since the test. The file should support decisions, rather than accumulate documents nobody can reconcile.

Prepare the support commitment alongside the release plan. The business needs people, tools and a distribution route to receive reports, produce fixes and communicate with customers. A long support promise without operating capacity is a future liability, not a complete security strategy.

A separate team may own support, but the engineering feedback loop must remain intact. A serious vulnerability should be able to reopen design assumptions, supplier questions and release priorities.

As of this October 2026 review, reporting under Article 14 is already applicable. It addresses actively exploited vulnerabilities and severe incidents affecting product security. Establish who recognises the trigger, obtains the necessary facts and can submit through the relevant process.

For the wider conformity programme, establish the product category and permitted assessment route, the documentation and the declaration and CE-marking requirements relevant to the offering. A generic certificate or a promise from a component supplier does not automatically establish conformity for your finished product.

The detailed reporting clocks and support rules are covered in our fuller CRA lifecycle briefing. Use this article as the UK supplier’s starting point and keep the product-specific interpretation current.

The UK’s Cyber Security and Resilience Bill concerns a different regulatory framework around network and information-system resilience. Government material still describes it as a Bill at this review. Do not treat proposed duties as already commenced, or assume that compliance with one framework settles the other.

A firm operating across both markets should separate the obligations while sharing useful evidence. Product inventory, incident contacts, supplier information and testing can support more than one programme, provided the team understands which requirement each piece of evidence answers.

• Assign a product owner and an accountable sponsor across engineering, support and compliance.
• Inventory versions, components and customer-facing support commitments.
• Test vulnerability intake, escalation and update delivery.
• Review the intended conformity route and missing evidence.
• Bring unresolved supplier, skills or support costs into the commercial plan.

Repeat the review when the offering changes. A new remote function, a new component or a substantial product modification can change the assumptions behind an earlier assessment. Keep the programme attached to the product lifecycle rather than a one-off launch checklist.