Cyber Resilience Act Compliance: A Practical Guide for IoT Product Manufacturers

The Cyber Resilience Act emerged as a response to persistent cybersecurity issues across the market's connected products. Previously, including cybersecurity in a product was an additional competitive advantage. Right now, it is a mandatory requirement.

Agreed upon by the European Commission in 2024, the CRA deadlines are approaching. From September 2026, manufacturers must report vulnerabilities and incidents; and from December 2027, the CRA’s main requirements will apply.

In this article, we highlight how to understand whether your product falls under the CRA and how to implement its requirements. 

Please take into account that this is not legal advice, but educational content. For decisions about your specific case, contact a qualified legal expert and check regulatory texts.

What is the Cyber Resilience Act (CRA)?

Developed by the European Commission, the Cyber Resilience Act (CRA) is a cybersecurity policy that aims to make products with digital components safe to use by addressing security gaps. Once the main obligations become applicable, manufacturers must follow mandatory CRA requirements across the entire product lifecycle — from planning and design to development, maintenance, and decommissioning. 

In addition, the CRA requires manufacturers to maintain a proper vulnerability management process and take appropriate measures promptly if issues arise. To prove compliance, there are different conformity routes (depending on product category): some can be assessed by manufacturers and some by notified bodies. After a successful compliance check, products will bear the CE marking, which approves them for sale on the EU market. 

Cyber Resilience Act timeline: What are the key deadlines?

To support a smooth preparation process, the Cyber Resilience Act is divided into phases with several key dates to follow. Manufacturers must focus on December 11, 2027, as it is the time when the CRA's requirements become applicable to products that are in scope. However, most standards that set technical specifications to clarify the implementation path are not yet final. Until harmonized standards that provide a presumption of conformity are released, manufacturers must show how their products meet the CRA’s Annex I requirements.

Starting in September 2026, manufacturers must already comply with certain obligations, such as vulnerability and severe-incident reporting. Also, until the final December deadline, companies should rearrange their development and post-market processes and prepare proper documentation as proof of the CRA compliance.
Penalties for non-compliance can result in fines of up to €15 million or 2.5% of global annual turnover, and removal from the EU market.  

Here is a table with key dates worth keeping in mind:

Process and vulnerability handling standards are expected in October 2026, while a catalog of security controls will be published approximately in October 2027. CEN-CENELEC and ETSI will also release product-specific, vertical standards in October 2026.

Which products fall under the Cyber Resilience Act scope, and which are out of it?

The scope of the Cyber Resilience Act covers all hardware and software products with digital elements that have a data connection either via direct (Wi-Fi, Bluetooth, Ethernet, cellular methods) or indirect (another device) methods. Meanwhile, it excludes products already regulated by specific industry standards or those not intended for commercial use. 

If your device transmits electrical signals, like voltage or current, to another device or network — it is out of scope because the CRA applies only to data that can be interpreted on the other side.

The majority of the following products are in scope:

• Standalone software: mobile/desktop apps, firmware sold separately, programs which can be downloaded on the device
• Hardware with embedded software (IoT): smart thermostats, industrial sensors, wearables, EV chargers, smart locks, connected appliances
• Standalone hardware: circuits, motherboards 
• Hardware and software combinations with digital elements

Important to know that if you designed a cloud backend and a device’s functionality depends on it, the cloud part is considered part of the product and falls under the scope of the CRA.  

At the same time, the CRA sets a clear list of product categories that are outside of the scope. Among them are the following:

• Products regulated by industry requirements, such as medical and in-vitro diagnostic devices (under the MDR and IVDR), automotive, marine, and avionics solutions
• Products built specifically for national security and defense
• Non-commercial products, like open-source software
• Pure web services and SaaS platforms that are not part of a physical or software product (covered by NIS2)

The quick self-check below will help you determine whether the CRA applies to your product or not — answer simple questions to find out.

Is a device with a one-way connection covered by the CRA?

Under the Cyber Resilience Act, what matters is whether the device communicates data that can be interpreted by another device or system. If the device exchanges such data, the CRA may apply, regardless of whether the connection is one-way or two-way.

Do USB and Bluetooth connections count under the CRA?

As for USB and Bluetooth connections, they can be under the CRA scope if they are used to carry data. If USB or Bluetooth is involved only for occasional device configuration, they are out of scope. 

Can two devices be covered by the CRA if they communicate with each other without an internet connection?

If two devices communicate without Internet access, they still fall within the CRA scope if they transmit data that can be interpreted on the other device.

If software or hardware is developed for internal use to provide services to customers, but is not placed on the market, does the CRA cover it?

The Cyber Resilience Act applies to products that are placed on the market, so if internally developed software or hardware is used only to provide a service and is not itself available on the market, it is outside of the CRA’s scope. 

How is an IoT product classified under the CRA?

The Cyber Resilience Act divides connected products into different classes, depending on their core functionality. There are default, important (Class I and II), and critical categories. The difference between them lies in whether the product provides general digital functionality or has some complex security-related features. This, in turn, affects the scale of harm a cybersecurity compromise can cause to end users and other systems. What is important is that the classification category doesn’t change the fact that you need to implement cybersecurity measures and change your development process; the only difference between product classes is the conformity route.

In cases when the product combines functionalities of different classes, its classification still depends on the concept of core functionality. If your product’s core functionality falls under Class I, but it also has one or two features that fall under Class II, you would generally classify the product as Class I. However, according to DEKRA (a notified body), if a Class II feature is the main functionality for users, the product may instead be classified as Class II.

Here is a more detailed overview of the devices and their assigned categories, but the full list you can find in the CRA Annex III, in addition to the CRA 2025/2392 product classification. 

What are the CRA requirements for IoT device manufacturers?

During development, manufacturers must ensure the product meets the core cybersecurity requirements outlined in Annex I. This includes:

• Secure-by-design & by default architecture;
• Access control and identity management;
• Protection of data in transit and at rest;
• Resilience and attack surface reduction;
• Security monitoring & user control.

Before release, you should clearly understand the class of your product and proceed with the conformity assessment required for that class. Apart from that, manufacturers need to maintain a machine-readable Software Bill of Materials (SBOM) with a list of third-party components used in the product. Before placing a product on the market, it must be checked for any known vulnerabilities and fixed to meet the CRA requirements.

After the product is released and reaches end users, manufacturers must still monitor the product and its components for emerging threats. First of all, there should be a Coordinated Vulnerability Disclosure (CVD) policy with a defined process for receiving, assessing, and addressing vulnerabilities discovered after release. Manufacturers should also define the product’s expected support period in a Lifecycle and Support Statement to ensure all required security updates are received, while technical documentation stays up to date as the product and its cybersecurity state change. 

How to know when a supplier updates a vulnerable library or software component?

The CRA doesn’t specify how often manufacturers should monitor components; however, it states that before and after release you need to be sure there are no issues with your components. What we can recommend is to define your own monitoring plan, for example, at each release or at least every three or six months.

What are the CRA SBOM requirements?

For manufacturers, keeping a software bill of materials (SBOM) is one of the crucial requirements, as it helps to keep all the product components, including libraries, dependencies, and packages. The inventory list must meet the following requirements:

• SBOM must be presented in a machine-readable format (the CRA doesn’t specify the exact format style).
• SBOM must be up to date with every product release and cover top-level components. The CRA doesn’t demand the presentation of deeper dependencies.
• SBOM is an important part of the technical documentation and must be provided to the authorities on demand. However, the CRA doesn’t demand that the SBOM be publicly accessible.

How does CRA compliance change the product development lifecycle?

The Cyber Resilience Act demands to adjust IoT product development lifecycle, so all security work moves earlier in the process and becomes traceable. For teams, that means keeping the CRA requirements alongside the product requirements to make cybersecurity part of the process instead of a separate checklist. All cybersecurity risks must be assessed early to implement proper security measures into the product architecture, verify them during development, and have evidence for the technical documentation. 

When it comes to handling the delivery process, we recommend following the Waterfall methodology with elements of the V-model, as they suit processes that have many dependencies and demand rigorous verification. While the CRA process standards are still under development and waiting to be approved by the EU, we would recommend using an IEC 62443-4-1 standard as a reference for the secure development lifecycle.

A CRA-compliant project takes about 25% more effort than a typical one, mostly because of documentation.

Here is a table that shows what activities the CRA adds to the traditional flow of the development lifecycle at each stage.

Cyber Resilience Act checklist: How to prove compliance?

Keep in mind, the Cyber Resilience Act requirements define what cybersecurity outcomes manufacturers must achieve, but at the same time, they do not specify which methodologies, frameworks, document formats, or testing tools to use. We’ve compiled a checklist of key activities and measures to consider when preparing to demonstrate your product’s compliance:

• Secure SDLC. You should have a risk-based development process that can provide the required evidence for implementing cybersecurity measures.
• Risk assessment. We advise using a threat-modeling method to get an initial view of the product and its components; it will give your team a concrete basis for identifying cybersecurity risks.
• Testing. Use appropriate testing or evaluation methods to demonstrate that the core requirements are identified and addressed. 
• Product release without known exploitable vulnerabilities. For manufacturers, the goal isn’t to guarantee a product with zero vulnerabilities, but to address those that are known and can be exploited.
• Security controls that address the ECRs. The appropriate controls depend on the product and its risk assessment. Manufacturers need to explain their security choices and show how they implement the relevant requirements.
• Traceability. While there is no specific mapping format to follow, you must still be able to explain how product design and development decisions address the applicable cybersecurity requirements and risk controls.
• Living technical document. This file needs to contain enough information and evidence for notified bodies to review the product.
• Vulnerability reporting. The reporting obligation applies to specific events, including actively exploited vulnerabilities and severe incidents. 
• Machine-readable SBOM. For each release, you need to maintain the list of third-party components up to date.

How does the CRA apply to products already on the market?

If the product was placed on the market before December 11, 2027, the Cyber Resilience Act doesn’t require redesigning it or taking it off the market. However, manufacturers are still obliged to report vulnerabilities and severe incidents. As for technical documentation, conformity assessment, and the Cyber Resilience Act CE marking — these requirements don't apply to legacy products.

One important point is substantial changes. If an existing product undergoes significant changes to its functionality that affect its compliance with the CRA, the modified product may need to meet the applicable CRA requirements.

What roles does the CRA affect?

Depending on your role in the product’s supply chain, the CRA assigns different responsibilities. Below you can find an explanation for each category.

For manufacturers. If you develop the product or it sells under your brand name, the main responsibility for aligning the product with the CRA requirements lies on your shoulders. Your main obligations are to ensure security by design, handle documentation and conformity assessment, and set up vulnerability management and reporting.

For importers. When your job is bringing products from a non-EU country to the EU market, your responsibility is to verify with the manufacturer that the product is compliant and has all necessary documentation.

For distributors. As a retailer or reseller of the product, your task is to check whether the device has CE marking. In case you learn from users that there is a serious security issue with the product, you need to take action and contact the manufacturer.

What’s important is that if your product is developed by an outsourcing partner, you still hold the responsibility as the manufacturer. Also, if a reseller or importer modifies and rebrands an existing product, they automatically become the manufacturer and now hold the higher level of responsibility. 

How to report vulnerabilities under the Cyber Resilience Act?

Ideally, the assigned person on the team handles the vulnerability management task. If you are a mid- to large-sized company, you can assign a team of several people to handle vulnerability monitoring and response.

The CRA sets strict reporting deadlines. Starting from September 11, 2026, manufacturers must report two types of cybersecurity events — actively exploited vulnerabilities and severe incidents — to the European Union Agency for Cybersecurity (ENISA). There are different deadlines depending on the type of event: 

• Early warning within 24 hours — after becoming aware of an actively exploited vulnerability or severe incident.
• A formal notification within 72 hours — with all available information about the vulnerability or incident.
• The final notification after the actively exploited vulnerability is mitigated — reported within 14 days 
• The final notification after the severe incident is mitigated — reported within 1 month after the 72-hour notification.

Where should you start with the CRA compliance?

The earlier cybersecurity becomes part of the product, the easier it is to address risks before they turn into costly issues. As vulnerability and incident reporting obligations already apply, your team needs proper processes in place to detect actively exploited vulnerabilities and severe incidents to report them within the required deadlines. 

Before the final December deadline, you need to understand where your products stand against regulatory requirements and identify the gaps between your current practices and the CRA expectations. Focus first on secure update mechanisms, SBOMs, and long-term vulnerability handling — they are one of the hardest things to retrofit into products already in development. If you need support with the gap assessment, use CRA implementation consulting services to get an independent review of your product readiness.  

The most crucial: make security a shared duty across the team. Assign responsible people and train them, so that your team can treat CRA compliance not as a final check before release, but as an ongoing commitment to product security.