Cyber Resilience Act: New Obligations for Manufacturers of Products with Digital Elements

TL;DR

The Cyber Resilience Act (CRA) is an EU regulation that entered into force in December 2024 and will be fully applicable from September 2027. Vulnerability reporting obligations apply from June 2026.
The CRA covers all products with digital elements placed on the EU market: hardware with software, pure software, and remote data processing as part of a product.
Manufacturers must ensure cybersecurity throughout the entire product lifecycle: security by design, vulnerability management for at least 5 years, and security updates for users.
Actively exploited vulnerabilities must be reported to ENISA within 24 hours. Serious incidents likewise.
Non-compliance can result in fines of up to EUR 15 million or 2.5 percent of global annual turnover.

What is the Cyber Resilience Act?

Connected products are everywhere: smart door locks, industrial sensors, routers, smartwatches, software applications, firmware in machine controllers. Many of these products are developed with minimal security measures and never receive security updates after sale. The result: millions of devices with known vulnerabilities that serve as entry points for cyberattacks.

The Cyber Resilience Act (CRA) is the European Union's answer to this problem. Regulation (EU) 2024/2847 was published in the Official Journal of the EU on November 20, 2024, and entered into force on December 10, 2024. It establishes, for the first time, binding cybersecurity requirements for manufacturers of products with digital elements placed on the EU market.

The CRA pursues two central objectives: First, products with digital elements should be secure by design from the outset. Second, manufacturers should remain responsible for the cybersecurity of their products throughout the entire lifecycle — for at least five years or the expected useful life, whichever is shorter.

Timeline: When does what apply?

The CRA has a staggered application timeline:

December 10, 2024: The regulation enters into force
June 11, 2026: Reporting obligations for vulnerabilities and incidents apply (Article 14)
December 11, 2026: Requirements for conformity assessment bodies apply
September 11, 2027: All requirements are fully applicable (Annexes I and II)

This means: if you manufacture products with digital elements, you have until September 2027 to implement the full requirements. But the reporting obligations for vulnerabilities apply as early as June 2026. That's an ambitious timeline, especially if you don't yet have structured vulnerability management in place.

Which products are affected?

The CRA deliberately defines "products with digital elements" broadly. Affected are:

Hardware products with software components: Routers, firewalls, IoT devices, smart home products, industrial controls, medical devices (to the extent not covered by sector-specific regulation), toys with digital functions, network devices, smart cards, and similar products.

Pure software products: Operating systems, firmware, application software, mobile apps, libraries and SDKs, desktop applications, and server applications.

Remote data processing solutions: If a product relies on remote data processing (for example, a cloud component required for core functionality), that component also falls under the CRA.

What is exempt?

Certain product categories are exempt from the CRA because they are covered by other regulation:

Medical devices (Regulation (EU) 2017/745 and 2017/746)
Vehicles (Regulation (EU) 2019/2144)
Aviation products (Regulation (EU) 2018/1139)
Products for national security and defense
Open-source software that is not commercially provided (with limitations)

The exception for open-source software deserves a closer look: non-commercial open-source projects are exempt. But if a company uses open-source software commercially and distributes it as part of a product, it bears CRA responsibility as the manufacturer. And "open source stewards" — foundations and organizations that coordinate open-source projects — have reduced obligations, particularly in the area of vulnerability management.

Product categories and conformity assessment

The CRA distinguishes three risk categories of products that require different conformity assessment procedures.

Standard products (default category)

The majority of products with digital elements fall into the standard category. For these products, a self-assessment by the manufacturer is sufficient (conformity assessment under Module A). The manufacturer verifies whether their product meets the requirements of Annex I, prepares the technical documentation, and affixes the CE marking.

Important products (Class I and Class II)

Higher-risk products are classified as "important" and divided into two classes:

Class I includes, among others: browsers, password managers, VPN software, network management systems, SIEM systems, boot managers, firewalls for private use, routers for private use, and microprocessors with security-relevant functions.

For Class I products, the manufacturer can either apply a harmonized standard (and then self-assess) or must have an assessment carried out by a notified body.

Class II includes, among others: firewalls and intrusion detection systems for industrial use, routers and switches for industrial use, hypervisors and container runtime systems, secure elements, hardware security modules (HSMs), smart card readers, and robotics devices.

For Class II products, assessment by a notified body is generally required.

Critical products

A third category for "critical products" can be defined through delegated acts. For these products, European cybersecurity certification under the Cybersecurity Act (CSA) would be required.

The requirements in detail

Product security requirements (Annex I, Part I)

The CRA defines fundamental security requirements that every product with digital elements must meet:

Security by design. Products must be designed, developed, and manufactured to ensure an appropriate level of cybersecurity. This includes: no known exploitable vulnerabilities at the time of market placement, secure default configuration (secure by default), protection against unauthorized access, protection of the confidentiality and integrity of stored and transmitted data, minimization of the attack surface, and limitation of the impact of a successful attack.

Authentication and access control. Products must provide mechanisms for authentication and authorization. Default passwords must be changed during initial setup or be unique for each device.

Security updates. Products must provide the ability to install security updates automatically or manually. Updates must be provided free of charge.

Data protection and data minimization. Products may only process data that is necessary for their intended use.

Vulnerability management requirements (Annex I, Part II)

In addition to the product requirements, manufacturers must operate comprehensive vulnerability management:

Documentation. Manufacturers must create and maintain a Software Bill of Materials (SBOM) that documents all components and dependencies of the product.

Vulnerability handling. Manufacturers must identify, document, and promptly fix vulnerabilities. Security updates must be provided free of charge and without unnecessary delay.

Coordinated disclosure. Manufacturers must have a policy for coordinated vulnerability disclosure and provide a contact address for reporting vulnerabilities.

Continuous monitoring. Manufacturers must actively monitor the cybersecurity of their products throughout the entire support period, including monitoring for vulnerabilities in third-party components.

Reporting obligations (Article 14)

The reporting obligations apply from June 2026 and include:

Actively exploited vulnerabilities. When the manufacturer becomes aware that a vulnerability in its product is being actively exploited, it must report this to ENISA within 24 hours. An updated report with further details follows within 72 hours.

Serious incidents. Incidents that affect the security of a product with digital elements must be reported on the same timeline.

Informing users. The manufacturer must inform users about the vulnerability and available countermeasures.

What does the CRA mean for manufacturers?

If you manufacture products with digital elements, you need to fundamentally adapt your development and support processes.

Introduce a secure development lifecycle

Cybersecurity must be integrated into the development process from the concept phase to end-of-life. A secure development lifecycle includes: threat modeling in the design phase, secure coding practices, code reviews and static analysis, security testing (fuzzing, penetration tests), dependency management and monitoring of third-party components.

Create a Software Bill of Materials

The SBOM is a new mandatory document. It must list all software components of the product, including open-source libraries and their versions. The SBOM must be kept up to date and made available to the supervisory authority upon request.

Define and communicate the support period

Manufacturers must define a support period for their product during which they provide security updates. This period must be at least five years or correspond to the expected useful life, whichever is shorter. The support period must be clearly communicated before purchase.

CE marking and declaration of conformity

Products that meet the CRA requirements receive the CE marking. The manufacturer prepares an EU declaration of conformity and keeps the technical documentation available for market surveillance authorities.

What does the CRA mean for operators and users?

Although the CRA primarily targets manufacturers, there are implications for operators and users:

Adapt procurement criteria. Operators should verify whether the manufacturer is CRA-compliant when procuring products with digital elements. From September 2027, only CRA-compliant products may be placed on the EU market.

Apply security updates. Manufacturers provide free security updates. Operators are obligated to apply them promptly, especially if they themselves are subject to regulatory requirements (NIS2, DORA, ISO 27001).

Use SBOMs for your own risk management. The SBOMs that manufacturers provide can be integrated by operators into their own vulnerability management. When a critical vulnerability in a widely used library becomes known, operators can use the SBOMs to quickly determine which of their products are affected.

CRA and other regulations: The interplay

The CRA fits into a growing web of European cybersecurity regulation.

CRA and NIS2. NIS2 addresses the security of operators' networks and information systems. The CRA addresses the security of the products used in those networks. Both regulations complement each other: NIS2 ensures that operators secure their infrastructure. The CRA ensures that the products in that infrastructure are secure from the start.

CRA and DORA. For the financial sector, DORA requirements for ICT products apply. The CRA can additionally be relevant if a financial entity itself manufactures products with digital elements (for example, banking apps or payment terminals).

CRA and AI Act. High-risk AI systems that fall under the AI Act must also meet CRA requirements if they are products with digital elements. Conformity assessment under the AI Act will be recognized as sufficient for the CRA in these cases, provided the cybersecurity aspects are covered.

Penalties for non-compliance

The CRA provides for significant fines:

Up to EUR 15 million or 2.5 percent of global annual turnover (whichever is higher) for violations of the fundamental security requirements
Up to EUR 10 million or 2 percent of turnover for other violations
Up to EUR 5 million or 1 percent of turnover for providing false or incomplete information

Additionally, market surveillance authorities can order the recall or prohibition of a non-compliant product.

Practical implementation: The biggest challenges

Software Bill of Materials (SBOM)

The SBOM requirement is new territory for many manufacturers. An SBOM documents all software components of a product, including open-source libraries, frameworks, and their versions. For a typical software product, this can mean hundreds of dependencies — direct and transitive.

The good news: there are established formats (SPDX, CycloneDX) and tools that can automatically generate SBOMs from build processes. The challenge lies less in the technical creation than in ongoing maintenance: with every update, with every new version, the SBOM must be updated. And you must actively monitor the components in the SBOM for known vulnerabilities — not just once at creation, but continuously throughout the entire support period.

Vulnerability management throughout the entire lifecycle

The CRA requires manufacturers to actively manage vulnerabilities in their products throughout the entire support period (at least five years). This means: you need a process that identifies, assesses, and fixes vulnerabilities in your own components and in third-party components and delivers the fixes as security updates to users.

For companies that have previously developed products on a "release and forget" basis, this is a paradigm shift. You must plan resources for long-term maintenance — and not just for new features, but explicitly for security updates. This has implications for product pricing, because five years of security support must be factored into the product price.

Coordinated Vulnerability Disclosure

The CRA requires manufacturers to establish a process for coordinated vulnerability disclosure. This means: you need a publicly reachable contact address (typically security@your-company.com) where security researchers can report vulnerabilities. You need an internal process that receives, assesses, and promptly handles these reports. And you need a policy that describes how you handle vulnerability reports and how disclosure is coordinated.

Many mid-market manufacturers don't yet have such a process. Setting it up requires not only technical measures (secure communication channels for vulnerability reports) but also organizational preparation (Who handles the reports? How quickly must a response be given? Who decides on publication?).

Secure by default

The "secure by default" requirement means that products must be secure in their default configuration. No open ports that aren't needed. No default passwords that are the same for all devices. No enabled debug interfaces in the production version. Encryption enabled by default where technically possible.

For hardware manufacturers, this can mean that the initial setup must include a step where the user sets an individual password before the device is usable. For software manufacturers, it can mean that installation defaults to the most restrictive configuration and the administrator must consciously enable features that create additional attack surface.

What you should do now

If you manufacture products with digital elements, start preparing now — even though the full requirements don't apply until September 2027. The reporting obligations come as early as June 2026, and adapting development processes, introducing SBOM management, and building vulnerability management take time.

The first step: inventory your products and classify them according to the CRA categories (standard, Class I, Class II). The second step: conduct a gap analysis against the requirements of Annex I. The third step: prioritize the gaps and create an implementation plan with realistic milestones. In ISMS Lite, CRA requirements can be mapped as controls and implementation progress tracked.