Cyber Resilience Act: The Complete Compliance Guide (2026)

The EU Cyber Resilience Act (CRA) is the most consequential product cybersecurity regulation ever passed. Published as Regulation (EU) 2024/2847 on 10 December 2024, it imposes mandatory cybersecurity requirements on every product with digital elements placed on the EU market — hardware, software, and connected devices from consumer IoT to industrial controllers. For manufacturers, importers, and distributors, it changes what it means to ship a digital product in Europe.

With the first mandatory obligations applying from 11 September 2026, less than five months away as of this article, the window for preparation has narrowed sharply. This guide covers what the CRA is, who is in scope, what the essential requirements are, how conformity assessment works, and how penetration testing fits into a credible compliance programme.

What the CRA Is and Why It Matters Now

The Cyber Resilience Act is the first EU-wide regulation setting mandatory cybersecurity requirements for products with digital elements (PDEs). It entered into force on 11 December 2024. Its reporting obligations apply from 11 September 2026, and the full regulation — including the essential cybersecurity requirements and conformity assessment procedures — applies from 11 December 2027.

The September 2026 date is the one manufacturers should have circled in red. From that point, any actively exploited vulnerability and any severe incident having an impact on the security of a product with digital elements must be reported to ENISA within specific tight timelines: an early warning within 24 hours, a notification within 72 hours, and a final report within 14 days of a corrective measure being made available. For a manufacturer that has not yet built the internal processes to support this, September 2026 is going to arrive uncomfortably.

The full application date of 11 December 2027 is when the rest of the regulation bites: conformity assessments must be in place, CE marking must reflect CRA compliance, technical documentation must be complete, and the essential cybersecurity requirements in Annex I must be demonstrably met.

Who Is In Scope

The CRA applies to manufacturers, importers, and distributors of products with digital elements placed on the EU market. A product with digital elements is any software or hardware product and its remote data processing solutions — including logical and physical interfaces — whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.

This is an intentionally broad definition. It covers consumer IoT devices, smart home products, connected industrial equipment, network infrastructure, operating systems, desktop and mobile applications, firmware, libraries, and development tools. Cloud-hosted software delivered as a service (SaaS) is generally outside scope on the grounds that it is covered by the NIS 2 Directive, although there are important edge cases where SaaS functions are tied to a device.

There is a carve-out for open source software developed in a non-commercial context. Hobbyist open source contributors are largely out of scope. However, the regulation introduces the concept of the open source software steward — a legal entity that systematically develops or contributes to open source software used in commercial activities. Stewards have lighter-touch obligations than full manufacturers but are not exempt.

Importers and distributors have meaningful obligations too. They must verify that products they place on the market carry CE marking, come with required documentation, and originate from compliant manufacturers. For products from outside the EU, the importer effectively takes on a checkpoint role.

The Three Product Categories

The CRA classifies products into three categories of increasing risk, each with proportionately stronger conformity requirements.

Default category: this is where roughly 90 percent of products sit. Consumer IoT, standard applications, most connected devices. Default products can use self-assessment against harmonised standards to demonstrate conformity. No third-party body is required.

Important products — Class I: password managers, VPNs, network management systems, SIEMs, physical network interfaces, and similar. Class I products can still self-assess if the manufacturer fully applies harmonised standards. If they do not, an internal procedure referenced in Module B of the CRA must be followed.

Important products — Class II: firewalls, intrusion detection and prevention systems, tamper-resistant microprocessors, secure elements, hardware security modules, operating systems, smart meters, and a defined set of other products. Class II products require third-party conformity assessment by a notified body, regardless of whether harmonised standards exist.

Critical products: smart meter gateways within smart metering systems, smartcards, and secure cryptographic hardware. For critical products, the Commission can require a European cybersecurity certification scheme under the Cybersecurity Act. This is the highest scrutiny tier.

The full list of important and critical products is set out in Annex III and Annex IV of the regulation. The Commission can amend these lists through delegated acts, which means the boundaries of the more heavily regulated categories may shift over time.

Essential Cybersecurity Requirements from Annex I

Annex I of the CRA sets out the essential cybersecurity requirements every product must meet. These fall into two parts: requirements relating to the properties of the product, and requirements relating to vulnerability handling processes.

On product properties, manufacturers must ensure that products are delivered without known exploitable vulnerabilities, that they are delivered with a secure-by-default configuration, and that they provide a means to protect against unauthorised access through appropriate control mechanisms including authentication, identity or access management. Products must protect the confidentiality of stored, transmitted or otherwise processed data through encryption where appropriate. Integrity of data, commands, programmes and configuration must be protected. Only data that is adequate, relevant and limited to what is necessary for the product's intended use may be processed. Availability of essential functions must be protected against denial-of-service attacks. Products must minimise their negative impact on the availability of services or devices connected to them. They must be designed, developed and produced to limit attack surfaces, including through external interfaces. They must provide security-related information logging, and support the possibility for users to remove data and settings in a secure manner.

On vulnerability handling, Annex I Part 2 requires manufacturers to identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials (SBOM) in a commonly used and machine-readable format covering at the very least the top-level dependencies. Vulnerabilities must be addressed and remediated without delay, including by providing security updates. Regular testing and review of the security of the product with digital elements is required. Information about fixed vulnerabilities must be publicly disclosed after a security update has been made available. A coordinated vulnerability disclosure policy must be enforced. Manufacturers must facilitate the sharing of information about potential vulnerabilities in their products and in third-party components, including by providing a contact address for reporting. Mechanisms must be in place to distribute updates securely and promptly, including free security updates for the support period, which is typically at least five years.

These are substantial obligations. Meeting them credibly requires product security engineering from the start of the development lifecycle, not at the end.

Vulnerability Handling Obligations from Annex II

Annex II covers the information that must accompany the product — the technical documentation, instructions for use, and information on how to securely configure and use the product. The SBOM is referenced here alongside Annex I.

Most consequentially, Articles 14 and 15 set out the reporting obligations that apply from 11 September 2026. Manufacturers must notify ENISA and the relevant CSIRT of actively exploited vulnerabilities in their products within 24 hours of becoming aware, with a follow-up notification within 72 hours and a final report within 14 days of a corrective measure. Similar timelines apply to severe incidents having an impact on security of products. These obligations are not contingent on the rest of the regulation being fully in force — they apply from September 2026.

This means that any manufacturer selling in the EU needs a vulnerability intake process, a triage process, a reporting process, and the internal coordination to make 24-hour, 72-hour and 14-day timelines achievable. For many manufacturers this is a meaningful operational programme to build from scratch.

Conformity Assessment Procedures by Category

How conformity is demonstrated depends on the product category.

For default and Class I products using harmonised standards, the manufacturer conducts internal production control (Module A). The manufacturer draws up technical documentation, carries out the assessment, and issues the EU declaration of conformity. No external involvement is required, though the manufacturer remains fully liable.

For Class I products not fully applying harmonised standards, a full internal assessment under Module B is required.

For Class II products, third-party conformity assessment is required. This means engaging a notified body designated by an EU member state to review the technical documentation, assess the manufacturer's processes, and issue the conformity certificate. The notified body pathway typically uses Module B (EU-type examination) combined with Module C (internal production control based on type), or Module H (full quality assurance).

For critical products subject to a European cybersecurity certification scheme, conformity is demonstrated through certification under the scheme. The Cybersecurity Act framework applies.

Across all categories, the CE mark must be affixed once conformity is established and the EU declaration of conformity must be available.

Timeline and Key Dates

11 December 2024: Entry into force.

11 June 2026: Notifying authorities and notified bodies must be designated by member states (Article 67).

11 September 2026: Reporting obligations for actively exploited vulnerabilities and severe incidents begin (Articles 14 and 15).

11 December 2027: Full application. Conformity assessment, CE marking, and all essential cybersecurity requirements become mandatory.

Products placed on the market before 11 December 2027 are largely grandfathered unless they undergo substantial modifications that could impact their cybersecurity properties.

Penalties

Fines are structured in three tiers. Non-compliance with the essential cybersecurity requirements in Annex I and the vulnerability handling obligations can be fined up to €15 million or 2.5 percent of total worldwide annual turnover of the preceding financial year, whichever is higher. Non-compliance with other obligations (such as conformity assessment procedural breaches) can be fined up to €10 million or 2 percent of turnover. The provision of incorrect, incomplete or misleading information to notified bodies and market surveillance authorities can be fined up to €5 million or 1 percent of turnover. SMEs face the same percentages but with reduced flat-fee maxima in some member state implementations.

These penalty levels sit alongside NIS 2 and DORA in the most serious tier of EU cybersecurity enforcement. For manufacturers operating on thin margins, a full fine is existential.

How Penetration Testing Fits

The CRA does not use the phrase penetration testing explicitly, but Annex I Part 2 requires manufacturers to apply effective and regular tests and reviews of the security of the product. In practice, this means penetration testing — and for the more heavily regulated categories, comprehensive penetration testing across multiple vectors.

A CRA-scoped pen test typically covers the product itself, including firmware, application layer, and hardware interfaces where relevant. The update mechanism needs testing — both the integrity of updates in transit and the installation process on the device. Any back-end or cloud services that the product depends on fall within scope. The vulnerability disclosure process should be tested end-to-end, including the intake path, triage, and notification chain. And the SBOM needs to be validated against what is actually shipping in the product.

For Class I products where self-assessment is used, pen testing is the primary evidence of testing and review. For Class II products where a notified body is involved, the notified body will want to see a recent penetration test report with full methodology disclosure, tester credentials, and a mapping of findings to Annex I requirements. For critical products, penetration testing will be part of a broader certification exercise.

Typical scope for a Class I product pen test runs 15 to 30 tester-days and costs €15,000 to €40,000. Class II products, which often involve hardware analysis, firmware reverse engineering, and more complex cloud back-end testing, typically run €30,000 to €80,000 or more. Critical product certification work starts at significantly higher price points.

Documentation matters as much as execution. The pen test report needs to be available to notified bodies and market surveillance authorities on request, clearly scoped, and mapped to the essential requirements it tested.

Preparation Roadmap for Manufacturers

If you ship a product with digital elements in the EU, the following sequence will put you in a credible position by December 2027.

First, classify your products. Determine whether each product sits in the default, Class I, Class II or critical category. This single decision drives everything else.

Second, build the vulnerability handling programme before September 2026. Vulnerability intake, triage, ENISA reporting, SBOM generation, coordinated disclosure, and secure update distribution need to be operational. This is the part that trips up manufacturers because it is an operational build, not a one-off compliance check.

Third, map product architecture against Annex I requirements. Every requirement should have a corresponding design decision, test, and piece of documentation. Gaps need to be remediated through the product roadmap.

Fourth, commission a pen test aligned to CRA scope. This is the evidence of testing and review. It also de-risks the subsequent conformity assessment by surfacing issues before a notified body does.

Fifth, for Class II and critical products, engage a notified body or certification authority early. Lead times will lengthen considerably as 2027 approaches. Engaging in 2026 rather than 2027 is substantially easier.

Sixth, prepare technical documentation. The CRA specifies what needs to be included in Annex VII. This documentation needs to be ready and maintained for a decade after the product is placed on the market.

Seventh, train the management body. Responsibilities attach at board level, and senior leadership in many jurisdictions will bear personal liability for systemic failures.

Next Steps

Our compliance page at /compliance/cyber-resilience-act lists penetration testing providers with CRA-relevant experience, alongside required services and industry-specific guidance. For a comparison of the CRA with NIS 2, see our companion article on /blog/cra-vs-nis-2-regulations-differences. For practical scoping guidance on a CRA pen test, see our manufacturer's checklist at /blog/penetration-testing-cyber-resilience-act-checklist.

The CRA is the most ambitious product cybersecurity regulation ever passed. The good news is that the requirements are largely sensible, the timeline gives a runway, and the industry ecosystem — notified bodies, penetration testing providers, SBOM tooling, vulnerability management platforms — is maturing fast. The bad news is that September 2026 is close, and most manufacturers have barely started. The organisations that begin now are the ones that will avoid a scramble in 2027.