The EU Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, sets mandatory cybersecurity requirements for hardware and software products sold in the EU. It entered into force on December 10, 2024. Manufacturers will have to design products to a set of essential security requirements, handle vulnerabilities for a support period of generally at least five years, produce a software bill of materials (SBOM), and put a CE mark on compliant products. Reporting of actively exploited vulnerabilities and severe incidents starts on September 11, 2026, and most other obligations apply from December 11, 2027. If you build, import or sell connected products or software, the clock is already running.
What is the Cyber Resilience Act and when does it apply?
The CRA is a horizontal law: rather than regulating one sector, it covers almost any product with a digital component. It was published in the Official Journal on November 20, 2024 and applies directly in every member state.
The obligations phase in over three years:
| Date | What applies |
|---|---|
| December 10, 2024 | Entry into force |
| June 11, 2026 | Rules on notifying conformity assessment bodies (Chapter IV) |
| September 11, 2026 | Reporting obligations for actively exploited vulnerabilities and severe incidents (Article 14) |
| December 11, 2027 | All remaining obligations, including the essential requirements and CE marking |
The reporting date deserves attention. Article 14 will apply to all products with digital elements on the market from September 2026, including products placed on the market before December 11, 2027. The other obligations apply to older products only if they're substantially modified after that date.
What counts as a product with digital elements?
A product with digital elements is any software or hardware product, and its remote data processing solutions, including components placed on the market separately. That covers a wide range: smart home devices, routers, industrial controllers, desktop and mobile apps, operating systems, firmware and software libraries supplied commercially.
Some products are out of scope because other EU laws already cover them, including medical devices, motor vehicles, civil aviation and marine equipment. Products developed exclusively for national security or defense purposes are also excluded.
Software as a service is generally outside the CRA. Remote data processing only counts where the manufacturer designed it and the product can't perform one of its functions without it, such as the cloud backend for a connected device.
Most obligations fall on manufacturers: anyone who develops or manufactures a product, or has it made, and markets it under their own name. Importers and distributors must check for the CE marking and required documentation. Substantially modifying a product and placing it on the market can make you a manufacturer.
How are products categorized under the CRA?
Every product must meet the same essential requirements. What changes by category is how you prove it.
| Category | Examples | How conformity is assessed |
|---|---|---|
| Default | Most products, such as many apps and simple connected devices | Self-assessment (internal control) is allowed |
| Important, Class I (Annex III) | Identity management and privileged access software, browsers, password managers, VPN products, SIEM systems, operating systems, routers and switches, smart home security products | Self-assessment only if you fully apply harmonized standards, common specifications or a European certification scheme; otherwise third-party assessment |
| Important, Class II (Annex III) | Hypervisors and container runtimes, firewalls, intrusion detection and prevention systems, tamper-resistant microprocessors and microcontrollers | Third-party assessment, or a European certification scheme at assurance level "substantial" or higher |
| Critical (Annex IV) | Hardware devices with security boxes, smart meter gateways, smartcards and secure elements | European cybersecurity certification may be required; otherwise the Class II procedures |
A product is important or critical when its core functionality matches a listed category. Integrating a listed component doesn't by itself move the whole product into that class. The Commission must adopt an implementing act describing each category technically by December 11, 2025.
Free and open-source products in the important categories get some relief. If the technical documentation is made public, they can use the internal control procedure.
What are the Annex I essential requirements?
Annex I has two parts. Part I covers the product's security properties, and Part II covers how the manufacturer handles vulnerabilities.
Product security requirements (Part I)
Products must be designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks. Based on a documented cybersecurity risk assessment, they must, among other things:
- Be placed on the market without known exploitable vulnerabilities
- Ship with a secure-by-default configuration, including the ability to reset to the original state
- Be able to receive security updates, including automatic updates enabled by default where applicable, with a clear opt-out
- Protect against unauthorized access with appropriate authentication, identity and access management
- Protect the confidentiality and integrity of stored, transmitted and processed data, for example through encryption
- Process only the data needed for the intended purpose
- Protect the availability of essential functions, including resilience against denial-of-service attacks
- Limit attack surfaces, including external interfaces
- Use exploitation mitigation mechanisms to reduce the impact of incidents
- Record and monitor relevant internal activity, with a user opt-out
- Let users securely remove all their data and settings
Vulnerability handling requirements (Part II)
Manufacturers must:
- Identify and document vulnerabilities and components, including by drawing up an SBOM
- Address and remediate vulnerabilities without delay, including through security updates, separately from feature updates where technically feasible
- Test and review product security regularly
- Publicly disclose information about fixed vulnerabilities once an update is available
- Put a coordinated vulnerability disclosure policy in place
- Provide a contact address for reporting vulnerabilities
- Distribute updates securely
- Make security updates available without delay and, unless otherwise agreed for tailor-made products, free of charge, with advisory messages
How long must manufacturers support products?
Article 13 requires manufacturers to set a support period that reflects how long the product is expected to be in use. During that period, they must handle vulnerabilities in line with Annex I Part II.
The support period must be at least five years. The exception is a product expected to be in use for less than five years, where the support period must match the expected use time. Each security update must also remain available for at least 10 years after it's issued, or for the rest of the support period if that's longer.
Buyers must be told the support period's end date, at least the month and year, at the time of purchase. That's a useful new data point for IT lifecycle planning.
What does the CRA require for SBOMs?
Annex I Part II requires manufacturers to draw up an SBOM "in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products." The SBOM forms part of the technical documentation and must be available to market surveillance authorities on request. The CRA doesn't require you to publish it.
Article 13 also requires due diligence when you integrate third-party components, including open-source ones, so that they don't compromise the product's security. If you find a vulnerability in a component, you must report it to whoever maintains that component.
How does the CRA treat open-source software?
Free and open-source software developed or supplied outside the course of a commercial activity isn't in scope. The CRA's obligations are aimed at those who place products on the market commercially, including manufacturers who build open-source components into their own products.
The CRA also creates a new role, the open-source software steward. A steward is a legal person, other than a manufacturer, that systematically and sustainably supports the development of free and open-source products intended for commercial activities. Foundations are the typical example. Under Article 24, stewards must document a cybersecurity policy that encourages vulnerability reporting and cooperate with market surveillance authorities. Some reporting obligations apply to them as well. Stewards can't be fined under the CRA.
What are the CRA's reporting obligations?
From September 11, 2026, manufacturers must notify actively exploited vulnerabilities and severe incidents affecting the security of their products. Notifications go simultaneously to the CSIRT designated as coordinator and to ENISA, through a single reporting platform that ENISA is to set up.
| Stage | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | Within 24 hours of becoming aware | Within 24 hours of becoming aware |
| Notification | Within 72 hours of becoming aware | Within 72 hours of becoming aware |
| Final report | Within 14 days after a corrective or mitigating measure is available | Within one month after the incident notification |
Manufacturers must also inform impacted users about the vulnerability or incident and, where necessary, about mitigation and corrective measures. Voluntary reporting of other vulnerabilities, threats and near misses is also possible.
How does CE marking work under the CRA?
After the applicable conformity assessment, the manufacturer draws up an EU declaration of conformity and affixes the CE marking before placing the product on the market. The marking must be visible, legible and indelible. For software, it can appear on the declaration of conformity or the accompanying website. Where a notified body was involved, its identification number follows the marking.
What are the penalties under the CRA?
Article 64 sets maximum administrative fines:
- Essential requirements and the obligations in Articles 13 and 14: up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher
- Most other obligations: up to €10 million or 2%, whichever is higher
- Incorrect, incomplete or misleading information to notified bodies or market surveillance authorities: up to €5 million or 1%, whichever is higher
Micro and small enterprises can't be fined for missing the 24-hour early warning deadlines, and open-source software stewards can't be fined at all.
Frequently asked questions
Does the CRA apply to products already on the market?
Partly. The reporting obligations in Article 14 will apply to them from September 11, 2026. The other requirements apply to products placed on the market before December 11, 2027 only if they're substantially modified afterward.
Does the CRA cover software we build only for internal use?
Generally not. The CRA applies to products made available on the EU market in the course of a commercial activity, and internal tools you never supply to anyone aren't.
We don't make products. Does the CRA matter to us?
Yes, as a buyer. From December 2027, products you purchase should come with a stated support period, security updates and a vulnerability contact. Build those expectations into procurement now.
Next steps
- Inventory your products and roles. List what you place on the EU market, flag likely important or critical products, and confirm where you're manufacturer, importer or distributor.
- Run a gap assessment against Annex I. Compare your secure development and vulnerability handling practices with Parts I and II.
- Get SBOMs in place. Generate machine-readable SBOMs in your build pipeline, starting with top-level dependencies.
- Decide support periods. Base them on expected use time, and check you can fund five or more years of updates.
- Prepare for September 2026 reporting. Build the process to spot actively exploited vulnerabilities and report within 24 hours.
- Plan conformity assessment. For important or critical products, budget for third-party assessment in case harmonized standards aren't ready in time.
This post explains the Regulation and isn't legal advice. Confirm how it applies to your products with counsel.