Cyber Resilience Act (CRA)

What is the EU Cyber Resilience Act?

The EU Cyber Resilience Act is a Euro­pean regu­la­tion that defines cyber­se­cu­rity require­ments for prod­ucts with digital elements across their entire life­cycle. It applies directly in all member states, without national trans­po­si­tion. The CRA addresses two prob­lems the Euro­pean Union iden­ti­fied: many connected prod­ucts reach the market with known vulner­a­bil­i­ties, and manu­fac­turers often stop providing secu­rity updates long before customers stop using the product.

The CRA is part of a wider package of EU cyber­se­cu­rity legis­la­tion. The NIS2 Direc­tive regu­lates the cyber­se­cu­rity of orga­ni­za­tions that operate crit­ical services. The CRA regu­lates the prod­ucts those orga­ni­za­tions buy. Together they cover both sides of the supply chain: the oper­ator and the manu­fac­turer.

Who needs to comply with the Cyber Resilience Act?

The scope of the CRA is broad. The EU CRA applies to manu­fac­turers, importers and distrib­u­tors of prod­ucts with digital elements made avail­able on the EU market. A product with digital elements, or digital product for short, is any hard­ware or soft­ware product whose intended use includes a data connec­tion to a device or network, including remote data processing solu­tions that belong to the product. That covers a broad range of indus­trial prod­ucts:

• PLCs, drives, sensors, gate­ways and edge devices
• machines and produc­tion equip­ment with embedded soft­ware
• HMI, SCADA, MES and engi­neering soft­ware
• firmware, apps and soft­ware compo­nents sold on their own

Manu­fac­turers outside the EU have to comply with the CRA as soon as their prod­ucts are sold in the EU, and there is no general exemp­tion for small and medium-sized enter­prises. Importers and distrib­u­tors must check that prod­ucts bear the CE marking and that the manu­fac­turer meets its oblig­a­tions.

What are the excep­tions?

Prod­ucts already covered by sector-specific EU rules with equiv­a­lent secu­rity require­ments are excluded, for example medical devices, motor vehi­cles, civil avia­tion and marine equip­ment. Prod­ucts devel­oped exclu­sively for national secu­rity or defense are out of scope. Free and open-source soft­ware that is not supplied in the course of a commer­cial activity is not covered, while open-source soft­ware stew­ards that support commer­cial use get lighter oblig­a­tions. Pure soft­ware as a service falls under NIS2 rather than the CRA, unless it is a remote data processing solu­tion of a product.

When does the Cyber Resilience Act take effect?

The reporting dead­line in September 2026 is the first one that affects every manu­fac­turer directly. It applies to all prod­ucts on the market, not only to new ones. From December 2027, prod­ucts without CRA compli­ance can no longer be sold in the EU.

What are the main CRA require­ments for manu­fac­turers?

Annex I of the regu­la­tion lists the essen­tial cyber­se­cu­rity require­ments. Each require­ment applies to the product as a whole, and they fall into two groups.

Secu­rity prop­er­ties of the product

• no known exploitable vulner­a­bil­i­ties at the time the product is placed on the market
• secure default config­u­ra­tion, with the option to reset to the orig­inal state
• protec­tion against unau­tho­rized access through authen­ti­ca­tion and access control
• protec­tion of the confi­den­tiality and integrity of data
• a mini­mized attack surface and limits on the impact of inci­dents
• secu­rity updates, auto­matic where appro­priate, and logging of secu­rity-rele­vant events

Vulner­a­bility handling

• a soft­ware bill of mate­rials (SBOM) that lists at least the top-level depen­den­cies in a machine-read­able format
• handling and fixing vulner­a­bil­i­ties without delay, including through secu­rity updates
• regular secu­rity testing and reviews
• a coor­di­nated vulner­a­bility disclo­sure policy and a contact point for reports
• secure distri­b­u­tion of updates, free of charge for the support period

Manu­fac­turers must define a support period that reflects how long the product is expected to be used, at least five years unless the product is meant for a shorter use. They perform a cyber­se­cu­rity risk assess­ment, keep tech­nical docu­men­ta­tion, issue an EU decla­ra­tion of confor­mity and affix the CE marking.

Product cate­gories and confor­mity assess­ment

Most prod­ucts fall into the default cate­gory, for which manu­fac­turers can assess confor­mity them­selves. Prod­ucts listed as impor­tant (classes I and II) or crit­ical face stricter proce­dures: they must apply harmo­nized stan­dards or undergo assess­ment by a noti­fied body, and for crit­ical prod­ucts a Euro­pean cyber­se­cu­rity certi­fi­ca­tion may become manda­tory. The cate­gory depends on the secu­rity func­tion of the product, so manu­fac­turers should check the annexes early.

What are the CRA reporting oblig­a­tions?

From that date, manu­fac­turers must report actively exploited vulner­a­bil­i­ties and any severe secu­rity inci­dent that affects their prod­ucts. Reports go through the single reporting plat­form run by ENISA to the national CSIRT acting as coor­di­nator:

• an early warning within 24 hours of becoming aware
• a noti­fi­ca­tion with more detail within 72 hours
• a final report within 14 days after a fix is avail­able for a vulner­a­bility, or within one month for a severe inci­dent

Manu­fac­turers must also inform affected users about the inci­dent and about correc­tive measures. Meeting these dead­lines requires a working process for moni­toring vulner­a­bil­i­ties in all compo­nents, which is why the SBOM matters so much.

Why the SBOM is at the center of CRA compli­ance

A modern indus­trial product contains dozens or hundreds of soft­ware compo­nents, many of them open-source libraries. When a vulner­a­bility becomes public in one of them, a manu­fac­turer has to know within hours which of its prod­ucts and versions are affected. Without an up-to-date soft­ware bill of mate­rials, that is guess­work. With an SBOM per product version, it becomes a data­base query.

The OI4 Indus­trial Cyber Secu­rity work­group has published two white papers on this topic, on vulner­a­bility manage­ment using SBOMs and on vulner­a­bility manage­ment for soft­ware-driven machinery, avail­able in the OI4 down­loads. A further OI4 guide covers secu­rity for the Asset Admin­is­tra­tion Shell, which can carry soft­ware version infor­ma­tion as part of a product’s digital twin.

What the CRA means for machine builders and compo­nent suppliers

For indus­trial manu­fac­turers, the CRA turns secu­rity into a life­cycle oblig­a­tion. A machine builder is respon­sible for the soft­ware in the machine, including compo­nents from suppliers. That makes supplier data a compli­ance topic: machine builders need SBOMs, vulner­a­bility infor­ma­tion and update commit­ments from their suppliers, ideally in a struc­tured, machine-read­able form. The new EU Machinery Regu­la­tion, which applies from January 2027, adds safety-related cyber­se­cu­rity require­ments on top.

The prac­tical response to this require­ment is Cyber Resilience Act compli­ance built into everyday engi­neering, with secu­rity processes that scale: an SBOM gener­ated auto­mat­i­cally in the build pipeline, a vulner­a­bility moni­toring process, a defined update channel and clear support periods. OI4 members working on soft­ware-defined automa­tion plan to harden their deploy­ment stack for CRA-compliant oper­a­tion, because container­ized, centrally managed appli­ca­tions make updates far easier than manu­ally main­tained controllers. See also OT secu­rity for the oper­a­tional side.

Frequently asked ques­tions