The Cyber Resilience Act: CRA Compliance Checklist for IoT Devices

The EU Cyber Resilience Act (CRA) is reshaping how manufacturers of IoT products must think about cybersecurity. The CRA introduces a groundbreaking set of requirements that apply across the entire lifecycle of a product with digital elements, from design and development to updates and end-of-life.

Two key dates define the timeline for compliance. From 11 September 2026, manufacturers will already be obliged to report actively exploited vulnerabilities and severe incidents in their products. From 11 December 2027, the full set of CRA requirements will apply, covering essential cybersecurity measures, vulnerability handling, documentation, and conformity assessment procedures.

For IoT manufacturers, this means that cybersecurity is now a compliance obligation, not a choice. Meeting these requirements will not only be crucial for obtaining CE marking, market access in the EU and avoiding financial penalties, but will also help build long-term trust with customers and partners. To help navigate these obligations, we have distilled the key CRA requirements into a practical checklist tailored for IoT products.

For a deeper dive into other areas of the Cyber Resilience Act, explore our CRA Knowledge Hub for more insights.

7 Key Milestones for IoT Manufacturers to Meet CRA Compliance

The following checklist translates the CRA’s requirements into concrete steps that IoT products and their manufacturers need to fulfill. It covers everything from cybersecurity risk assessments to essential and vulnerability handling requirements, documentation, and conformity assessment procedures. Use it as a guide to evaluate whether your devices and processes are aligned with the new regulatory expectations and to identify areas where you may need to strengthen your security practices.

1. Product classification

The first step toward CRA compliance is to determine how your product is categorized under the regulation. Each IoT product falls into one of four categories — default products, important products Class I, important products Class II, or critical products. This classification defines the type of conformity assessment procedure that applies, with higher-risk categories such as critical products expected to undergo more detailed and rigorous assessments than default or important products.

However, classification does not change the baseline security obligations. All products covered by the CRA must comply with the 13 essential cybersecurity requirements and the 8 vulnerability handling requirements, regardless of which category they fall into. The classification only determines the assessment pathway, not whether the requirements themselves apply.

2. Cybersecurity Risk Assessment

The CRA requires manufacturers to take a structured approach to identifying potential threats before a product reaches the market. A well-executed risk assessment helps ensure that security considerations are integrated from the beginning, covering both expected usage scenarios and possible misuse. Because the threat landscape evolves over time, the assessment must be treated as a living process that adapts throughout the product’s lifecycle.

• Carry out a cybersecurity risk assessment before market placement, addressing intended use, foreseeable misuse, and operational environment.

• Review and update the assessment regularly during the product’s support period.

3. Mandatory Reporting of Vulnerabilities and Incidents

Starting 11 September 2026, manufacturers of products with digital elements must comply with mandatory reporting duties. This requires reporting any actively exploited vulnerabilities and severe security incidents affecting their products to the relevant authorities. To meet this obligation, companies need to have processes in place for continuous monitoring, detection, assessment, and timely notification of critical issues. Although the broader set of CRA requirements does not take effect until December 2027, preparing for these reporting duties early is essential to avoid penalties and ensure trust in the market.

4. Essential Cybersecurity Requirements

Manufacturers must ensure their IoT products fulfills the 13 essential cybersecurity requirements by 11 December 2027. These requirements must be implemented based on the outcomes of the cybersecurity risk assessment, which guide the selection of appropriate technologies and controls. The risk assessment also provides the foundation for justifying how each requirement has been addressed and documented:

(a) No known exploitable vulnerabilities: Products must not be released if there are known security issues that could be exploited. A vulnerability assessment and appropriate mitigation must be done before the product reaches the market.

(b) Secure by default configuration: Devices must come with secure settings enabled by default and offer a way to reset to a secure state. Exceptions are only allowed if explicitly agreed between the manufacturer and business user.

(c) Security updates and opt-out: The product must support timely security updates, including automated updates by default. Users must be clearly informed about updates and given the ability to delay or opt out.

(d) Protection against unauthorized access: Appropriate access controls must be implemented to prevent unauthorized interaction with the product. This includes user authentication, identity management, and reporting of suspicious access.

(e) Confidentiality of data: Sensitive data must be protected during storage and transmission using state-of-the-art encryption and other technical safeguards. This applies to both personal and non-personal data.

(f) Integrity of data and functions: The system must protect against unauthorized manipulation of data, commands, programs, and configurations. It must detect and report corruption or tampering.

(g) Data minimization: Only data that is strictly necessary for the intended function of the product may be collected or processed. Irrelevant or excessive data usage is not permitted.

(h) Resilience and availability: Basic functions must remain available even after a security incident. This includes measures to defend against denial-of-service and ensure operational resilience.

(i) No harm to connected systems: The product must not interfere with or degrade the availability of other devices or services in the network. This includes limiting unnecessary traffic or unstable behavior.

(j) Limited attack surface: The product must minimize points of exposure, such as unused interfaces or open ports. Reducing complexity and access paths lowers the chance of exploitation.

(k) Mitigation of incident impact: Appropriate technical mechanisms must be in place to reduce the impact of successful attacks. This includes defensive coding practices like sandboxing and memory protection.

(l) Logging of security-relevant activity: Internal security events, such as data access or configuration changes, must be recorded. Users must have the option to disable this logging if needed.

(m) Secure deletion and data portability: Users must be able to permanently delete all personal data and settings. If data is transferred to other systems, this must happen securely and without risk.

5. Vulnerability Handling & Reporting

By 11 December 2027, manufacturers must fulfill the following 8 vulnerability handling requirements:

(1) Identify and Document Vulnerabilities: Manufacturers must identify and document vulnerabilities and list all key software components in their products by drawing up a Software Bill of Materials (SBOM).

(2) Risk Management & Security Updates: Identified vulnerabilities must be handled according to their risk, and depending on that updated in a timely manner.

(3) Security Testing: Products must be regularly tested for security flaws, not just during development, but also after release, to ensure they stay protected against new threats.

(4) Notification for Security Updates & Vulnerability Disclosure: Users must be clearly informed when security updates are available. The notification must explain what was fixed and how users can stay protected.

(5) Coordinated Vulnerability Disclosure (CVD) Policy: Manufacturers must have a clear process for working with researchers and users who report security flaws. Both sides cooperate to fix issues before making them public.

(6) Vulnerability Sharing & Reporting: A contact method must be available for reporting security issues. This includes vulnerabilities in the product itself or in any third-party components used.

(7) Security Update Distribution: Products must include a secure system for receiving updates. 7Updates must be sent safely and reliably so users can fix security problems quickly.

(8) Provide and Retain Security Updates: Security updates must be provided without delay and free of charge. The updates must come with clear instructions.

6. Documentation Obligations

Manufacturers must draw up and keep the following documents for their IoT products:

• Technical Documentation: Includes the cybersecurity risk assessment and a technical description how the CRA requirements are fulfilled. (Read our blog post here)

• EU Declaration of Conformity: Signed statement by the manufacturer ensuring compliance and describing the chosen conformity assessment procedure. (Read our blog post here)

• User Information & Instructions: Provide in paper/electronic form, covering secure installation/use, vulnerability reporting channel, update policy, support period, and instructions for secure product usage.

7. Conformity Assessment

Choose and execute the right conformity assessment procedure according to the product categorization of your IoT products:

• For default category products: Internal self-assessment (Module A).

• For important products (Class I & II): Third-party assessment (Modules B+C or H).

• For critical products: European cybersecurity certification or third-party assessment.

While third-party assessment is not mandatory for many products, we anticipate that many companies will still choose it because of the high consequences that come with the CRA. An external audit or assessment by a notified body can reduce the risk of non-compliance, provide stronger assurance of meeting CRA requirements, and build additional trust with customers and regulators. In practice, at least a third-party audit may also be required through RFP processes when companies make significant investments into connected products, as buyers increasingly demand verified assurance of cybersecurity compliance.

This content piece is one of many unpacking the CRA in detail, find the full overview in our CRA Guide.

From Obligation to Opportunity

The CRA marks a turning point in the way digital products are placed on the European market. For IoT manufacturers, it creates both a challenge and an opportunity: a challenge to embed cybersecurity consistently into products and processes, and an opportunity to differentiate by demonstrating resilience and trustworthiness.

By working through this checklist, manufacturers can prepare for compliance while also improving the security and reliability of their products. In doing so, they not only avoid regulatory penalties but also strengthen their position in a market where security is increasingly a deciding factor for customers.

Curious how our expertise and technology can simplify compliance? Discover how the Tributech Middleware supports IoT manufacturers in meeting CRA requirements in our detailed article: How Tributech helps achieve CRA compliance.

If you want to dive deeper into the Cyber Resilience Act and how it affects your IoT products, we’re happy to share our knowledge and expertise. Book a call with us and let’s explore how you can prepare your products and processes for compliance, and turn security into a business advantage.