What is the Cyber Resilience Act?
The Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) is a European regulation that imposes binding cybersecurity requirements on all hardware and software products with digital elements placed on the EU market, throughout their entire lifecycle. Manufacturers must design their products securely, ship them without known exploitable vulnerabilities, provide free security updates for years and report actively exploited vulnerabilities. The regulation has been in force since 10 December 2024; the reporting obligation has applied since 11 September 2026 and the full set of requirements applies from 11 December 2027.
For OT, this means that suppliers of products such as PLCs, industrial routers, HMIs, engineering software or Industrial Internet of Things devices are required to develop and maintain their products securely, including updates and vulnerability management. Without CRA conformity there is no CE marking and therefore no access to the European market.
🗓️ When does the Cyber Resilience Act apply?
The Commission proposed the CRA on 15 September 2022. After the political agreement, the Council adopted it on 10 October 2024; the regulation is dated 23 October 2024 and was published in the Official Journal of the EU on 20 November 2024. A phased introduction follows:
| Date | Milestone |
|---|---|
| 10 December 2024 | Entry into force of the regulation |
| 11 June 2026 | Rules on notified bodies (conformity assessment) apply |
| 11 September 2026 | Article 14 reporting obligations apply: actively exploited vulnerabilities and severe incidents are reported via ENISA’s Single Reporting Platform |
| 11 December 2027 | Full application: essential requirements, conformity assessment, CE marking and support period |
Products placed on the market before 11 December 2027 only have to meet the essential requirements if they are substantially modified afterwards. The reporting obligation, however, also covers those products already supplied.
🧱 Which products does the CRA cover?
The CRA applies to every product with digital elements: hardware or software whose intended or reasonably foreseeable use includes a direct or indirect, logical or physical data connection to a device or network. Associated remote data processing solutions are also covered when the product cannot perform one of its functions without that cloud service. Stand-alone SaaS is not covered; in practice NIS2 applies to it.
| Example component | CRA application |
|---|---|
| PLC or RTU | Firmware must be secure, updates traceable and verified |
| Industrial router or switch | Important product class I: secure default configuration and a protected update process |
| Industrial firewall | Important product class II: always assessed by a notified body |
| SCADA software | Supplier must handle, publish and patch vulnerabilities |
| Sensor with network interface | Has a data connection, so it is a product with digital elements |
| Engineering software | Subject to documentation, logging and update requirements |
The CRA also applies to integrated components, such as Embedded operating systems, databases, open-source libraries and update agents. The final manufacturer must exercise due diligence when selecting such components and must report vulnerabilities in them to whoever maintains the component.
Excluded are products already covered by their own sectoral rules: medical devices and in vitro diagnostics (MDR and IVDR), motor vehicles (Regulation 2019/2144), certified aviation products and marine equipment. Identical spare parts and products developed exclusively for national security or defence are also outside the CRA. Free open-source software supplied outside a commercial activity is excluded; foundations that systematically support open source fall under a light regime as open-source software stewards.
🧠 Which essential requirements does the CRA set?
Annex I of the regulation has two parts. Part I concerns the security properties of the product. Based on a documented risk assessment, the product must, where applicable:
- Be placed on the market without known exploitable vulnerabilities
- Be delivered secure by default, with the possibility to reset it to its original state, so no universal default passwords
- Prevent unauthorised access with authentication and identity and access management
- Protect confidentiality and integrity of data, commands, programs and configuration, for example with encryption and signed firmware
- Safeguard the availability of essential functions, including against denial-of-service, and limit the attack surface
- Process only necessary data (data minimisation) and limit the negative impact on other devices and networks, with mechanisms that reduce the impact of an incident
- Provide logging of relevant internal activity, such as access to and modification of data and functions
- Enable security updates, automatic where applicable and with a notification to the user
Part II covers the manufacturer’s vulnerability handling: a machine-readable SBOM covering at least the top-level dependencies, prompt remediation, regular testing, public disclosure of fixed vulnerabilities, a coordinated vulnerability disclosure policy (responsible disclosure) with a contact address, and secure, timely and free distribution of patches with an advisory to users.
✅ What are the obligations of manufacturers, importers and distributors?
| Obligation | In practice |
|---|---|
| Risk assessment | Documented, applied in every phase from design to maintenance and updated during the support period |
| Support period | At least five years, unless the product is expected to be used for less; end date (month and year) visible at the time of purchase |
| Availability of updates | Each security update remains available for at least ten years after release, or for the rest of the support period if longer |
| Technical documentation | Including the risk assessment and SBOM; kept with the EU declaration of conformity for at least ten years |
| Reporting | Actively exploited vulnerabilities and severe incidents within 24 hours, 72 hours and with a final report (see CRA Reporting Obligations) |
| User information | Contact point for vulnerabilities, intended use, support period and instructions for secure installation and decommissioning |
Importers may only place products with CE marking and technical documentation on the market; distributors check that marking. Anyone who sells a product under their own name or substantially modifies it becomes the manufacturer. The CRA defines a modification as substantial when it affects compliance with the essential requirements or changes the intended purpose; the guidance the Commission published on 27 July 2026 elaborates on that concept. That is an important point for a system integrator who, for example, adds remote connectivity to an existing machine.
🔐 How does a manufacturer demonstrate conformity?
The CRA divides products into four classes. For the roughly 90% of default products, such as a PLC or sensor, self-assessment (module A) is sufficient. Important products of class I listed in Annex III, such as routers, switches and operating systems, may only be self-assessed if the manufacturer fully applies harmonised standards, common specifications or European cybersecurity certification. Class II, such as firewalls and IDS/IPS, always requires a notified body, and for critical products in Annex IV, such as smart meter gateways and secure elements, European certification may become mandatory.
Which standards apply is described in CRA Harmonised Standards. In short: CEN, CENELEC and ETSI are working under standardisation request M/606 on the EN 40000 series, product standards and OT profiles based on IEC 62443. As of early October 2026, not a single CRA standard has been cited in the Official Journal.
🔁 How does the CRA relate to other regulations?
| Regulation / standard | Relationship to the CRA |
|---|---|
| NIS2 and the Dutch Cybersecurity Act | Target the organisation that uses products; the CRA targets the product manufacturer. Together they strengthen the supply chain |
| IEC 62443 | IEC 62443-4-1 (secure development) and IEC 62443-4-2 (component requirements) align closely in substance, but do not by themselves give a presumption of conformity |
| CE Marking | The CRA becomes part of CE conformity for digital products |
| Machinery Regulation | From 20 January 2027 the Machinery Regulation also requires protection against corruption of control systems; CRA conformity helps demonstrate this |
| AI Act | A high-risk AI system that complies with the CRA is deemed to meet the cybersecurity requirements of the AI Act |
| EN 18031 and the Radio Equipment Directive | Transitional regime for wireless equipment until 11 December 2027 |
Since 1 August 2025, wireless equipment has been subject to the cybersecurity requirements of the Radio Equipment Directive (Delegated Regulation 2022/30), which manufacturers demonstrate with EN 18031. Delegated Regulation (EU) 2026/339 repeals that act with effect from 11 December 2027; after that, the CRA takes over this role entirely. The CRA goes hand in hand with existing OT security standards, but imposes legally binding requirements on product security.
🏭 How does an OT vendor prepare for the CRA?
- Inventory the portfolio - which products, firmware versions and software packages do you sell in the EU, and which class do they fall into
- Set up a secure development process - according to IEC 62443-4-1, with threat modelling, code reviews and security testing
- Build the SBOM into the pipeline - generate a machine-readable SBOM for every release and track vulnerabilities in components, including open source
- Define the support period - realistically matched to the service life; OT installations often run for 15 to 20 years, so five years is a floor
- Set up a PSIRT - reachable within 24 hours for the reporting obligation and publishing advisories in CSAF format
- Compile the technical documentation - risk assessment, applied standards, test results, SBOM and declaration of conformity
For asset owners, things change too: at purchase you will be able to demand a support period, SBOM and CE conformity. That helps with patch management, vulnerability management and limiting supply chain risk. Existing legacy systems remain outside the essential requirements, so lifecycle management stays important.
Dutch context: the bill for the Dutch CRA Implementation Act (Uitvoeringswet Cyber Resilience Act) has been before the House of Representatives since December 2025. It makes the Dutch Authority for Digital Infrastructure (RDI) the market surveillance authority and the NCSC the CSIRT that receives notifications. Fines run up to €15 million or 2.5% of worldwide annual turnover for breaching the essential requirements and the obligations in Articles 13 and 14, up to €10 million or 2% for other obligations, and up to €5 million or 1% for supplying incorrect information to authorities.
❓ Frequently asked questions
Does the Cyber Resilience Act apply to products that have already been sold?
The essential requirements of the Cyber Resilience Act only apply to products placed on the market from 11 December 2027, or to existing products that are substantially modified afterwards. The CRA reporting obligation for actively exploited vulnerabilities, however, applies to all products within scope, including the installed base.
Is a PLC covered by the Cyber Resilience Act?
Yes, a PLC is a product with digital elements and is therefore covered by the Cyber Resilience Act. Without a specific security function it is usually a default product for which self-assessment is sufficient. If the PLC has core functions such as a router or firewall, a stricter class may apply.
How long must a manufacturer provide security updates under the CRA?
The Cyber Resilience Act requires a support period of at least five years, unless the product is expected to be used for less. The period must reflect the expected time in use, which in OT is often much longer. In addition, each security update must remain available for at least ten years after release.
What is the difference between the Cyber Resilience Act and NIS2?
The Cyber Resilience Act sets requirements for products and their manufacturers, regardless of the sector or size of the customer. NIS2, implemented in the Netherlands as the Cyberbeveiligingswet, sets requirements for essential and important organisations and their own network and information systems. A drinking water company falls under NIS2, the supplier of its PLCs under the CRA.
Does the CRA apply to open-source software?
Open-source software developed and supplied outside a commercial activity is not covered by the Cyber Resilience Act. A manufacturer that integrates open source into a commercial product is, however, responsible for the security of those components. Open-source software stewards have lighter obligations and cannot be fined.
Who supervises the Cyber Resilience Act in the Netherlands?
In the Netherlands, the Dutch Authority for Digital Infrastructure (RDI) becomes the market surveillance authority for the Cyber Resilience Act under the bill for the Dutch CRA Implementation Act. The NCSC is the CSIRT that receives CRA notifications from manufacturers via ENISA’s Single Reporting Platform.
📌 In summary
The Cyber Resilience Act requires manufacturers of digital products to embed cybersecurity structurally: secure design, no known vulnerabilities, at least five years of security updates and a reporting obligation since 11 September 2026. For OT, this means that all networked components, from field sensor to SCADA server, must meet requirements for secure development, vulnerability management and long-term maintenance from 11 December 2027 in order to carry a CE marking.