Security obligations
follow the product.

The CRA concerns hardware and software products with digital elements made available on the EU market, including separately marketed components. Remote processing integral to a product’s functions can be included. It is too simple to say that every cloud service is covered, or that being delivered through the cloud puts a product outside the regime.

Start with the actual offering: what is supplied, by whom, under whose name, into which market and with which connected functions? A manufacturer, importer and distributor have different responsibilities. A business that integrates third-party components still needs to understand the security consequences for its own product.

Check exclusions and sector-specific regimes against the product rather than relying on a broad sector label. For open-source software, the commercial context matters; the CRA also defines a tailored role for certain open-source software stewards. “All open source is exempt” is not a reliable scoping rule.

The practical deliverable is a written scope decision that an engineer, product owner and compliance lead can use. Record unresolved questions and who will settle them. A spreadsheet marked “CRA” without a defined product boundary leaves the difficult decisions until later.

A software bill of materials helps identify included components. It is a working input to vulnerability handling, not proof that the product is secure. The value appears when a component advisory can be connected to affected versions, responsible engineers, an assessment and a supported customer update.

Set the support commitment deliberately. The CRA normally requires at least five years unless the expected product use is shorter; expected use and the relevant factors can require longer. A released security update must remain available for at least ten years after issue or the remaining support period, whichever is longer. Update availability and the period for producing new fixes are different commitments.

Budget the people, distribution mechanisms and evidence retention behind that commitment. A sales promise about years of support is not credible if nobody owns the vulnerability inbox, signing and release process, supported-version inventory or customer communication.

Security updates are generally to be provided without charge, subject to the regulation’s specific exception for certain custom-made business products. Review the precise terms for the offering rather than repackaging ordinary security fixes as a paid premium feature.

Article 14 covers actively exploited vulnerabilities and severe incidents affecting product security. Establish who identifies the reporting trigger, who can make a submission and how the team reaches the required information out of hours. A general corporate incident procedure may not answer those product-specific questions.

Reporting sources: European Commission CRA reporting and legislative summary. Article 14 also applies to relevant products placed on the market before 11 December 2027.

Keep timestamps and decisions in the product incident record: awareness, severity or exploitation assessment, notification, available mitigation and follow-up. Do not wait for complete root-cause analysis before considering an early report. Use subsequent reporting to clarify what was uncertain.

The customer communication and update process needs equal attention. A notification does not fix an exposed product, and a published update does not show that users have been able to obtain or apply it. Connect the regulatory workflow to engineering and support so that it advances the response rather than becoming a separate administrative queue.

Determine whether the product falls within the ordinary, important or critical categories, including the Class I/Class II distinction in Annex III and the critical categories in Annex IV. That decision affects the available assessment route. Do not assume that every product can self-assess, or that every product needs the same external certification.

CE marking and the declaration of conformity sit within the CRA market-access process. A cybersecurity certificate may contribute only where the applicable scheme, scope and legal conditions allow. An existing ISO certificate or a generic “EU compliant” statement does not settle the product’s CRA obligations.

EU cooperation and certification initiatives can support the wider ecosystem, but they should not be confused with the manufacturer’s own duty to evidence the product. Focus the programme on the obligations that apply to the actual offering, then use relevant standards and schemes where they help demonstrate them.

This is an organising plan, not a grace period. Duties already applicable, including reporting, need to be addressed immediately. Run urgent work in parallel and use the 100-day review to expose gaps rather than postponing them.

Give procurement a practical role too. Ask suppliers about supported versions, update availability, vulnerability coordination and component evidence. A buyer’s questionnaire should help the product team resolve a real dependency, not just collect a reassuring answer for a file.