The Cyber Resilience Act explained.

The CRA applies to products with digital elements: software or hardware whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network (Art. 2(1), Art. 3(1)). It also covers remote data processing, if the manufacturer designed it for the product and the product could not perform one of its functions without it (Art. 3(2)).

The product must be made available on the EU market in the course of a commercial activity, whether for payment or free of charge (Art. 3(22)). It is therefore not limited to selling.

According to the Commission's 2026 guidance, software that runs remotely and that you only open in a browser is not a product on that basis alone. Websites are not products either. Cloud services designed and developed outside the responsibility of a product manufacturer are outside the CRA (recital 12); the NIS2 Directive applies to them. Cloud functions that a manufacturer builds to make its own product work are in scope. Software that you download or install, including browser extensions, is a product.

Sectors with their own rules are excluded: medical devices and in vitro diagnostic devices, motor vehicles, civil aviation and marine equipment (Art. 2(2) to (4)). Products developed exclusively for national security or defence are excluded as well (Art. 2(7)). Products that a public administration develops or modifies exclusively for its own use are not made available on the market (recital 16).

• In scope: software you install or run on your own devices, connected hardware, and the cloud functions a manufacturer builds to make its own product work.
• Usually out of scope: web applications you use only through a browser, and websites that do not support a product's functionality.
• Out of scope by sector: medical devices, in vitro diagnostics, motor vehicles, civil aviation, marine equipment.
• Products placed on the market before 11 December 2027 fall under the CRA only after a substantial modification (Art. 69(2)). The reporting duty in Art. 14 does apply to all in-scope products (Art. 69(3)).

Manufacturers carry most of the obligations (Art. 13). They must design products according to Annex I, carry out and document a cybersecurity risk assessment, and keep it up to date during the support period.

Importers and distributors check that the CE marking, the EU declaration of conformity and the user information are present before they supply a product (Art. 19, Art. 20). Anyone who supplies under their own name or trademark, or substantially modifies a product, is treated as a manufacturer (Art. 21 and 22).

By default a manufacturer assesses conformity itself (internal control, Art. 32(1)). Stricter routes apply to important products (Annex III) and critical products (Annex IV). Class I, for example operating systems, password managers, VPN products and routers, may use self-assessment only if harmonised standards, common specifications or certification are applied in full. Class II, for example hypervisors, firewalls and intrusion detection systems, and critical products need assessment or certification by a third party (Art. 32(2) to (4)).

Breaching Art. 13 or Art. 14 can lead to fines of up to EUR 15 million or 2.5 % of worldwide annual turnover, whichever is higher (Art. 64(2)). Member States set and enforce the penalty rules.

• Secure by design and by default (Annex I, Part I): no known exploitable vulnerabilities when made available, a secure default configuration, protection against unauthorised access, protection of data, and the ability to receive security updates.
• Vulnerability handling (Annex I, Part II): a coordinated vulnerability disclosure policy, a contact address for reports, fixing vulnerabilities without delay, an SBOM (software bill of materials) covering at least the top-level dependencies, and security updates free of charge, unless agreed otherwise for tailor-made products (point 8).
• Support period (Art. 13(8)): based on the expected period of use and at least five years, unless the product is expected to be used for less. The end date, at least month and year, is stated clearly at the time of purchase (Art. 13(19)). Each security update stays available for at least 10 years, or for the rest of the support period if that is longer (Art. 13(9)).
• Conformity: conformity assessment, technical documentation, EU declaration of conformity, CE marking (Art. 13, 28 and 30) and user information according to Annex II.
• Reporting (Art. 14), since 11 September 2026: an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available (vulnerabilities) or within one month after the incident notification (severe incidents). Reports go through the single reporting platform to the CSIRT designated as coordinator and to ENISA at the same time. The manufacturer also informs affected users (Art. 14(8)).

From 11 December 2027 the obligations in the previous section apply to in-scope products placed on the market. They usually do not apply to SaaS you use only through a browser, nor to products placed on the market earlier unless they are substantially modified. Use the points below in tenders, questionnaires and contracts.

The reporting duty has applied since 11 September 2026. You can already expect vendors to report actively exploited vulnerabilities and severe incidents within the Art. 14 deadlines, including for products placed on the market earlier. The CRA does not stop you from setting additional cybersecurity requirements in your own procurement (Art. 5(1), recital 13).

• CE marking: does the product carry it, and where? For software it sits on the EU declaration of conformity or on the website that accompanies the software (Art. 30(1)).
• EU declaration of conformity: where can you read it? A simplified declaration must contain the exact internet address of the full one (Art. 13(20)).
• Support period: what is the end date, at least month and year, for the version you are buying? It must be stated clearly at the time of purchase (Art. 13(19)). The minimum is five years, unless the product is expected to be used for less (Art. 13(8)).
• Security updates: are they free of charge during the support period (unless agreed otherwise for tailor-made products), and how are they delivered? (Annex I, Part II, points 7 and 8).
• Vulnerability contact: who is the single point of contact, and where is the coordinated vulnerability disclosure policy? (Art. 13(17), Annex II).
• SBOM: the vendor must keep one covering at least the top-level dependencies, and gives it to authorities on a reasoned request. Sharing it with customers is optional (Annex II, point 9), so ask for it explicitly or put it in the contract.
• Incidents: will the vendor inform you of actively exploited vulnerabilities and severe incidents, and in what form? (Art. 14(8)).
• Conformity route: for products in Annex III or IV, which assessment route was used? (Art. 32).

Free and open-source software is in scope only when it is supplied in the course of a commercial activity. Software that its authors do not monetise is not (recital 18). Financial support from manufacturers or regular releases do not by themselves make it commercial. Merely hosting code on an open repository or package manager is not making it available on the market (recital 20).

Commercial activity is broader than a price. Recital 15 names charging for technical support beyond recovering costs, an intention to monetise (for instance a platform through which other services are monetised), requiring personal data for reasons other than security, compatibility or interoperability, and accepting donations that exceed the costs. Donations without a profit intention are not a commercial activity.

An open-source software steward is a legal person, other than a manufacturer, that systematically provides support on a sustained basis for the development of open-source products intended for commercial activities (Art. 3(14)). Certain foundations, and entities that publish open source in a business context, can be stewards (recital 19). Stewards fall under a lighter regime (Art. 24).

Stewards may not affix the CE marking (recital 19) and are not subject to the administrative fines of Art. 64(3) to (9) (Art. 64(10)(b)). According to ENISA, their duties apply from 11 December 2027. According to the Commission's guidance, the same organisation can be a steward for one project and a manufacturer for another. Manufacturers that use open-source components must exercise due diligence on them (Art. 13(5)).

• A documented cybersecurity policy that fosters secure development and effective vulnerability handling.
• Cooperation with market surveillance authorities on request.
• Vulnerability reporting under Art. 14, to the extent the steward is involved in development.

The CRA and NIS2 (Directive (EU) 2022/2555) address different things. The CRA sets requirements for products and their manufacturers. NIS2 covers the services and risk management of essential and important entities.

The CRA states that existing Union cybersecurity law, including NIS2, does not directly cover mandatory security requirements for products with digital elements (recital 3). It aims to help providers of digital infrastructure meet the supply-chain requirements under NIS2, by ensuring that the products they use are developed securely and receive timely security updates (recital 24). Supply-chain measures under NIS2 can require stricter products than the CRA does (recital 13).

The two meet in reporting: the CRA uses the CSIRTs designated as coordinators, known from NIS2, as recipients of notifications (Art. 14). Whether your own organisation falls under NIS2 is a separate question that this page does not answer.

Today this page is information only. The CRA does not change the sovereignty score or the recommendations.

As a pilot, the vendors in the CMS category now show the CRA signals we found publicly, as information next to the existing data and without counting them in the score: a security.txt, a page for reporting vulnerabilities, a supported-versions policy and, for open source, the organisation behind the project. Every link was checked on the vendor's or project's own site. From 11 December 2027 we will also show the EU declaration of conformity (CE marking) once a product has one.

A CRA signal says nothing about where a vendor is established or who owns it. Digital sovereignty and product security are separate questions.