CRA: the EU regulation for product cybersecurity.

What the CRA is

The Cyber Resilience Act (Regulation (EU) 2024/2847) is the first EU-wide law to set mandatory cybersecurity requirements for products with digital elements, covering both hardware and software across their whole lifecycle (Art. 1).

It moves responsibility for a product's security onto the organisation that places it on the market, rather than the user. In practice a product with digital elements may only be made available in the EU if it meets the essential requirements in Annex I and the manufacturer has completed the obligations attached to it, shown through a conformity assessment, an EU declaration of conformity and the CE marking. For a security or compliance team the CRA is best read not as a new standard to adopt from scratch but as a set of product-level duties that sit alongside the organisational duties you already carry under NIS2 and, for financial entities, DORA.

Who the CRA applies to

The CRA applies to manufacturers, importers and distributors of products with digital elements whose intended or reasonably foreseeable use includes a direct or indirect data connection (Art. 2, 3).

Manufacturers carry the primary obligations: secure design, technical documentation, conformity assessment and vulnerability handling. Importers may place only compliant products on the market and must verify the manufacturer's duties were met; distributors must act with due care and check that the CE marking and documentation are present. The regulation is extraterritorial: a company established outside the EU that sells into the Union is in scope and must ensure a responsible economic operator exists in the EU. Remote data-processing solutions that are necessary for the product to perform its functions are treated as part of the product and are covered too. Products already governed by sector-specific rules, such as medical devices, motor vehicles and civil aviation, are excluded, and non-commercial open-source software developed outside a commercial activity sits largely outside the scope.

Standalone Software-as-a-Service sits outside scope where it operates independently of a physical product. Cloud components are regulated only when they qualify as Remote Data Processing Solutions -- meaning the physical product functionally depends on that remote processing to execute a core function, and the remote software is developed by or under the explicit responsibility of the manufacturer. If your 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.

The CRA also creates a specific legal category of open-source software steward: an entity that systematically supports open-source products intended for commercial use. Stewards must maintain a cybersecurity policy, cooperate with market surveillance authorities, and report actively exploited vulnerabilities, but they are explicitly exempt from the administrative fines in Article 64. For contributors who monetise through gated features or whose donations exceed development costs, the non-commercial exemption does not apply.

One supply-chain nuance worth flagging: the CRA places obligations on the entity that places the product on the EU market under its own name or trademark. An upstream OEM developer that supplies components or white-label hardware to a third party is not the "manufacturer" for CRA compliance purposes unless it also markets the finished product directly. The regulatory burden follows the brand on the box -- not the origin of the underlying technology.

Product classification under the CRA

The conformity route depends on how critical the product is: most products self-assess, while higher-risk categories face stricter procedures, and where more than one category could apply the stricter one governs (Art. 6--7, Annex III--IV).

Classification follows the product's core functionality, not every feature it happens to include.

Key obligations for manufacturers

Annex I splits the essential requirements into properties the product must have and processes the manufacturer must run (Annex I).

The product must be secure by design and by default, ship free of known exploitable vulnerabilities, and be delivered with a minimised attack surface. The manufacturer must run a vulnerability-handling process, provide free security updates across a defined support period (generally expected to be at least five years unless the product's expected use is shorter), maintain a software bill of materials in a commonly used machine-readable format, and report actively exploited vulnerabilities and severe incidents (see the Reporting section below). For a team already running an ISO 27001 or NIS2 programme, the honest picture is that the vulnerability-handling, risk and evidence machinery overlaps heavily with what you have; the genuinely new work is product-level and documentary, not a second management system.

Conformity assessment and the CE marking

Demonstrating compliance follows a fixed sequence, and the route through it is set by the product class (Art. 28, 32, Annex V, VII).

Compile the technical documentation described in Annex VII and keep it for ten years after the product is placed on the market; carry out the conformity assessment (default products may self-assess, important products use harmonised standards or a notified body, critical products require certification); draw up the EU declaration of conformity to Annex V; and affix the CE marking as the visible sign that the above is complete. The CRA is, in effect, a hard prerequisite for the CE mark on products with digital elements, which is why manufacturers outside the EU that rely on the CE mark for distribution are in scope even when they never sell directly into the Union.

Reporting duties and the three-regime comparison

From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of their products to ENISA and the relevant national CSIRT, through the single reporting platform established under Article 16 (Art. 14, 16).

The clock runs in three stages: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours including any corrective or mitigating measures, and a final report within 14 days once a vulnerability is fixed or, for an incident, within one month once it is handled. This is the earliest of the CRA's major obligations to take effect.

The 24-hour early-warning clock starts when the manufacturer becomes aware and does not pause for weekends or bank holidays -- a point that matters when a vulnerability surfaces Friday evening. Teams used to DORA should note the difference: Commission Delegated Regulation (EU) 2025/301 permits certain financial entities to defer weekend initial notifications to the next working day; no equivalent deferral exists under the CRA. The duty is absolute from the moment of awareness.

Teams that already meet NIS2 and DORA reporting duties have the operational reflexes for this, but the deadlines and the recipient are not identical across the three regimes, which is where a single, well-documented incident process pays off:

Timeline and penalties

The Act is already in force and its obligations phase in through to the end of 2027, while penalties reach up to EUR 15 million or 2.5 % of worldwide annual turnover (Art. 71, 64).

It entered into force on 10 December 2024. The framework for notifying conformity-assessment bodies applies from 11 June 2026, the reporting obligations from 11 September 2026, and the bulk of the obligations from 11 December 2027. Penalty tiers are set in Article 64: breaches of the essential requirements (Annex I) or obligations under Articles 13 and 14 -- including the reporting duties -- carry fines of up to EUR 15 million or 2.5 % of total worldwide annual turnover, whichever is higher; breaches of other obligations carry up to EUR 10 million or 2 %; supplying incorrect, incomplete or misleading information carries up to EUR 5 million or 1 %. One proportionality note: micro and small enterprises are exempt from fines for missing the 24-hour early warning deadline, though all substantive obligations remain in force for them.

Products placed on the market before 11 December 2027 do not face the full conformity-assessment sequence unless they undergo a substantial modification that changes their risk profile. The Article 14 reporting obligation is different: it applies from 11 September 2026 to all products currently available on the EU market, including legacy systems that were shipped before the regulation existed. The reporting duty therefore arrives first for a class of products that was never designed with it in mind. Having a standing vulnerability-monitoring and escalation process -- rather than one assembled in the run-up to the 2027 conformity deadline -- is what makes the earlier reporting obligation manageable rather than chaotic.

How the CRA fits an existing GRC programme

If you already run a multi-framework programme, the CRA is best absorbed into it rather than run as a separate project, because its vulnerability-handling, risk and evidence duties map onto controls you almost certainly already operate.

The parts that genuinely differ are product-specific: classifying each product, maintaining the SBOM, producing the technical documentation and declaration of conformity, and wiring the 24h / 72h / 14-day reporting path to ENISA. The failure mode teams describe is not finding vulnerabilities, which scales easily, but remediating and documenting them on a defensible cadence, which does not. A regulator will not accept "we are working on it"; it expects a documented, systematic process, and spreadsheets and chat threads will not survive that test. That is the case for treating CRA reporting as one more obligation on a single control set rather than a fourth silo. See manage CRA obligations alongside NIS2 and DORA.