Cyber Resilience Act (CRA): what changes for digital products

The Cyber Resilience Act (CRA) is the EU regulation that sets mandatory cybersecurity requirements for almost every connected hardware and software product sold in the European Union. Manufacturers must design secure products, fix their vulnerabilities throughout the support period and report them to the authorities. Reporting has been mandatory since 11 September 2026; from 11 December 2027, CE marking will depend on compliance with the whole text.

Regulation (EU) 2024/2847 of 23 October 2024, known as the Cyber Resilience Act, entered into force on 10 December 2024. It is the first European law to set a minimum level of cybersecurity for products themselves, rather than for the organisations that use them. Its purpose fits in one idea: a digital product must no longer be placed on the market with known flaws, nor abandoned by its manufacturer once the sale is made.

The text starts from something CISOs know well: many connected products ship with default passwords, outdated components and no commitment to updates, and users have no way of knowing how long they will be maintained. The CRA shifts the burden: the manufacturer must demonstrate the security of its product, just as it already demonstrates electrical safety or electromagnetic compatibility.

A "New Legislative Framework" regulation

The CRA follows the logic of EU product safety regulations: essential requirements defined in the text (Annex I), harmonised standards that give a presumption of conformity, a conformity assessment proportionate to risk, an EU declaration of conformity and CE marking. Market surveillance authorities in each Member State check products and can have them withdrawn. As a regulation, it applies directly in France without transposition; only some national adaptation measures are still being drafted according to ANSSI.

The regulation covers products with digital elements: any hardware or software product, and its remote data processing solutions, whose intended use involves a direct or indirect connection to a device or network. The scope is therefore very broad: connected camera, router, watch, industrial controller, smart card, but also standalone software, mobile app, operating system or video game.

CRA and software: what is in and what is out

For software, two points matter. First, services delivered entirely online (SaaS) are not products under the CRA; they generally fall under NIS 2. Only "remote data processing" without which a product could not perform one of its functions is covered, for example the online service that controls a camera. Second, free and open-source software developed or distributed outside any commercial activity is not covered; once open-source software is monetised, however, its manufacturer is subject to the CRA. The Commission guidance published on 27 July 2026 details these boundaries with many examples.

Exclusions

Products already covered by equivalent sector-specific cybersecurity rules stay outside the CRA, along with a few special cases:

• medical devices and in vitro diagnostic devices, governed by EU Regulations 2017/745 and 2017/746: an important point for healthcare providers, whose biomedical equipment stays outside the CRA, unlike their routers, workstations and management software;
• motor vehicles, civil aviation equipment and marine equipment;
• products developed exclusively for national security or defence, or to process classified information;
• identical spare parts supplied by the manufacturer to replace a component of an existing product.

Default, important and critical products

All products must meet the same essential requirements, but how this is demonstrated depends on their sensitivity. Annex III lists important products (class I and II) and Annex IV critical products. Their precise technical description was set by Implementing Regulation (EU) 2025/2392 of 28 November 2025, in force since 21 December 2025.

The CRA divides obligations among supply chain actors, following the model of other product regulations. Most of the burden falls on the manufacturer.

• The manufacturer (Article 13) designs the product or has it designed and markets it under its name. It performs the cybersecurity risk assessment, meets the essential requirements, handles vulnerabilities, draws up the technical documentation, carries out the conformity assessment, affixes the CE marking and reports exploited vulnerabilities. A manufacturer established outside the EU may appoint an authorised representative.
• The importer (Article 19) only places compliant products on the market: it checks that the assessment was done, that documentation exists, that the CE marking is affixed and that the manufacturer has provided a contact point for vulnerabilities.
• The distributor (Article 20) checks the CE marking and the presence of user information, and stops selling a product it knows to be non-compliant.
• The open-source software steward (Article 24), for example a foundation that provides sustained support to a project used commercially, has a lighter regime: a documented cybersecurity policy, cooperation with authorities and certain reporting obligations. It cannot be fined.

Watch out for requalification: an importer or distributor that sells a product under its own name, or anyone who makes a substantial modification to a product already on the market, becomes the manufacturer and takes on all its obligations (Articles 21 and 22). An organisation that heavily modifies purchased software and then resells it, or makes it available to other entities in the course of a commercial activity, should ask itself the question.

Annex I is the technical core of the regulation. It has two parts: the security properties of the product, and vulnerability handling by the manufacturer. Both are assessed on the basis of a cybersecurity risk assessment that the manufacturer must document and keep up to date.

Part I: a product secure by design

The product must be designed, developed and produced to ensure a level of cybersecurity appropriate to the risks. In practice, it must in particular:

• be placed on the market without known exploitable vulnerabilities;
• ship with a secure-by-default configuration, with the option to reset it to its original state;
• be able to receive security updates, automatic by default where relevant, with an opt-out for the user;
• protect against unauthorised access (authentication, identity and access management) and report attempts;
• protect data confidentiality (encryption at rest and in transit) and integrity;
• process only the data necessary for its intended use;
• preserve its essential functions, including against denial-of-service attacks, and limit its impact on other devices and networks;
• reduce its attack surface, including external interfaces, and limit the effects of an incident;
• log relevant internal security activity and let users delete their data securely.

Part II: handling vulnerabilities throughout the support period

The manufacturer must also run a proper vulnerability handling process:

• identify and document the product's components, in particular by drawing up a software bill of materials (SBOM) covering at least top-level dependencies; see our article SBOM: the software bill of materials required by the CRA;
• fix vulnerabilities without delay, including through security updates kept separate from feature updates where possible;
• regularly test and review the product's security;
• publish information about fixed vulnerabilities once a fix is available;
• put in place a coordinated vulnerability disclosure policy and a contact address for reporting them;
• distribute fixes securely, without delay and free of charge, with advice for users.

For a software vendor, this means formalising a secure development lifecycle and a vulnerability response process (often called a PSIRT, Product Security Incident Response Team) that existed unevenly. The requirements rest on a risk analysis: it justifies which measures are applied and how.

A support period of at least five years

The manufacturer sets a support period reflecting how long the product is expected to be used. It cannot be shorter than five years, unless the expected use is shorter (Article 13(8)). During this period it must handle vulnerabilities, and each security update issued must remain available for at least ten years or until the end of support, whichever is later. The end-of-support date must be stated clearly at the time of purchase, at least the month and year. The Commission guidance specifies that a minor fix does not restart a new five-year period.

Technical documentation and user information

The technical documentation (Annex VII) describes the product, its design, the cybersecurity risk assessment, the means used to meet the essential requirements, the SBOM and test reports. It is kept for ten years and provided to authorities on request. Users receive the information listed in Annex II: contact point for reporting vulnerabilities, intended use, known risks, end of the support period, how to install updates and how to decommission the product securely.

CRA and CE marking

Once the conformity assessment is complete, the manufacturer draws up the EU declaration of conformity and affixes the CE marking, visibly and legibly, on the product or, for software, on the declaration or website that accompanies it. From 11 December 2027, a product with digital elements without CE marking under the CRA can no longer be placed on the EU market. The harmonised standards that ease the demonstration are being drafted: CEN, CENELEC and ETSI accepted the Commission's standardisation request in 2025, covering some forty horizontal and vertical standards. As ANSSI points out, their use remains voluntary and compliance work should not wait for their publication.

The regulation applies in stages, giving manufacturers time to adapt their products and Member States time to designate their authorities. Three dates follow entry into force, all set by Article 71.

• 11 June 2026: the provisions on notifying conformity assessment bodies apply. In France, ANSSI, the notifying authority, relies on accreditation by COFRAC; it expects the first notifications around the end of 2026.
• 11 September 2026: manufacturers must report actively exploited vulnerabilities and severe incidents. This obligation also applies to products placed on the market before that date.
• 11 December 2027: all other obligations apply. Products placed on the market before that date are only subject to them if they later undergo a substantial modification.

What is settled and what is still in progress as of 23 September 2026

The table below sums up the implementing texts and tools, with the date of each piece of information.

Article 14 is the only substantive obligation already in force. As soon as it becomes aware of an actively exploited vulnerability in one of its products, or of a severe incident affecting its security, the manufacturer must send an early warning within 24 hours, a notification within 72 hours, then a final report. Reports are filed on ENISA's single reporting platform; for a manufacturer established in France, the receiving coordinating CSIRT is CERT-FR. The manufacturer must also inform affected users and tell them what to do.

What these two notions cover, the information expected at each stage, the comparison with NIS 2 and the GDPR and the internal organisation to set up are detailed in our article CRA: reporting exploited vulnerabilities.

In France, the allocation of roles was confirmed by ANSSI, ANFR and DGE at an event for manufacturers on 23 September 2026:

• the French radio frequency agency (ANFR) is the market surveillance authority: it checks products, can require corrective action, restrict or prohibit market placement and order a withdrawal or recall;
• ANSSI is the notifying authority for conformity assessment bodies and provides technical support to market surveillance;
• CERT-FR, part of ANSSI, is the coordinating CSIRT that receives reports;
• the DGE (Directorate-General for Enterprise) informs and raises awareness among businesses, especially SMEs.

Article 64 sets three caps for administrative fines, the higher of the fixed amount and the percentage of worldwide annual turnover being retained:

• EUR 15 million or 2.5% for failing to meet the Annex I essential requirements or the obligations in Articles 13 (manufacturer) and 14 (reporting);
• EUR 10 million or 2% for other obligations (importers, distributors, declaration of conformity, CE marking, technical documentation);
• EUR 5 million or 1% for supplying incorrect, incomplete or misleading information to authorities.

Two mitigations: micro and small enterprises cannot be fined for missing the 24-hour early warning deadline, and open-source software stewards cannot be fined. To compare these amounts with those of other texts, see our article on NIS 2 penalties.

The three texts complement each other more than they overlap. The CRA addresses those who make and sell products; NIS 2 those who operate essential or important services; the AI Act those who provide or deploy artificial intelligence systems.

Most organisations do not make digital products, but all of them buy them. For them, the CRA is first of all good news: it sets a minimum level of security and requires manufacturers to share information that buyers often asked for in vain. It is also a tool for third-party risk management: a supplier that cannot answer these questions in 2026 will struggle to place its product on the market in December 2027.

Building the CRA into your purchasing now

• In tenders and specifications: ask for the end-of-support date, the coordinated vulnerability disclosure policy and security contact point, a commitment to provide security updates free of charge and, for deliveries from December 2027, the EU declaration of conformity. Public buyers, many of them in healthcare and local government, can include these criteria in their technical specifications.
• In your supplier assessment questionnaires: add questions on CRA readiness (product category, planned assessment procedure, notified body where relevant, reporting organisation since September 2026, existence of an SBOM). Our article on the supplier security questionnaire explains how to scale these questions to the third party's criticality.
• In your contracts: provide for the SBOM or relevant vulnerability information to be shared on request, a deadline for informing you of an actively exploited vulnerability affecting the product, and a minimum support period. For sensitive services, these clauses belong in the security assurance plan.
• In your inventory: track the end-of-support date of each deployed product. It is a simple piece of data that lets you anticipate replacements and spot unmaintained products, the first entry point for supply chain attacks.

What the CRA does not do for you

The CE marking attests that a product met the requirements when placed on the market; it says nothing about how you configure, integrate and maintain it. Products deployed before December 2027 will not be brought into compliance retroactively. And the CRA does not cover SaaS services, which you still need to assess yourself. Supplier assessment and risk analysis therefore keep their full place in your governance, risk and compliance approach.

Phinasoft does not issue CE markings and does not assess your products for you. Its platform does help you build the Cyber Resilience Act into your risk and supplier management processes:

• with the third-party risk management module, you create questionnaires from your own requirements, including those you derive from the CRA, submit them to suppliers through a dedicated portal, give them feedback (accepted or rejected non-conformities, requests for more information) and track indicators; each supplier keeps the history of its assessments, and you export the requirements to include in your security assurance plans;
• with the Risk & Compliance module, you run your risk analyses using EBIOS RM, ISO 27005 or your own method, for example on a project that integrates a connected product;
• if you are a manufacturer yourself, compliance campaigns measure the progress of your teams, sites or subsidiaries against a list of requirements you define, and drive the resulting action plans.

To see how these modules fit your situation, you can request a demo.