If your company builds software or hardware with digital elements and sells into the EU, the EU Cyber Resilience Act now sets a legal floor for how secure that product has to be. It is not a voluntary framework. It is a regulation, with fines attached, and its first real deadline lands in a matter of weeks.
TL;DR
- The CRA is Regulation (EU) 2024/2847. It sets mandatory cybersecurity requirements for products with digital elements sold in the EU.
- Products fall into one of four classes – Default, Important (Class I or II), or Critical – and the class determines how you prove compliance.
- Four obligations sit at the center: secure-by-design engineering, a software bill of materials (SBOM), vulnerability handling, and incident reporting.
- Reporting obligations start 11 September 2026. Full application follows on 11 December 2027.
- Penalties reach €15 million or 2.5% of global annual turnover, whichever is higher.
- ControlMonkey supports all the CRA Requirements
What Is the EU Cyber Resilience Act (CRA)?
The Cyber Resilience Act is the first EU-wide law that makes cybersecurity a market-access requirement for products with digital elements. It is not an optional best practice. In one sentence: if your product has digital elements and reaches the EU market, it must be designed, built, and maintained to a defined cybersecurity standard, and you have to be able to prove it.
The regulation shifts responsibility onto the organizations that place products on the market, rather than leaving security to the end user. It covers hardware and software across their full lifecycle, from initial design through end-of-life support. Compliance is demonstrated through a conformity assessment, a signed EU declaration of conformity, and the CE marking already familiar from other EU product regulations.
The CRA complements the NIS2 Directive rather than replacing it – NIS2 governs the cybersecurity of critical-infrastructure operators, while the CRA governs the products those operators (and everyone else) buy and run. ControlMonkey’s own cloud compliance overview covers how NIS2, DORA, and other frameworks fit together for DevOps teams.
Who the CRA Applies To
The CRA’s scope is intentionally broad. It covers any product with digital elements whose intended or reasonably foreseeable use includes a direct or indirect data connection. That includes connected devices, business hardware, desktop and mobile applications, operating systems, libraries, and components.
Obligations are distributed across the supply chain:
- Manufacturers carry the primary duties: secure design, technical documentation, conformity assessment, and vulnerability handling.
- Importers may only place compliant products on the market and must verify the manufacturer’s obligations were met first.
- Distributors must act with due care and confirm that CE marking and documentation are present before selling a product on.
Location does not create an exemption. A company established outside the EU that sells into the Union is still in scope, and it must ensure an EU-based economic operator is responsible for the relevant duties. Remote data-processing services that a product needs in order to function are treated as part of that product and fall under the same rules.
A few categories sit outside the CRA: products already governed by sector-specific rules, such as medical devices, motor vehicles, and civil aviation equipment, and non-commercial open-source software developed outside a commercial activity, which carries a lighter, tailored set of duties instead.
When Your DRaaS Plan Doesn't Cover the Full Stack
Most DRaaS models protect data and VMs. ControlMonkey extends recovery to infra config, IAM, networking, and 30+ third-party platforms – so your failover environment matches production.
CRA Product Classes and Conformity Routes
Not every product faces the same compliance bar. The CRA sorts products into four classes based on their core functionality, and the class determines the conformity route a manufacturer must follow.
| Class | Examples | Conformity route |
|---|---|---|
| Default | Most products with digital elements | Self-assessment |
| Important – Class I | Password managers, VPNs, network management tools | Harmonised standards or third-party assessment |
| Important – Class II | Operating systems, firewalls, microprocessors | Mandatory third-party assessment |
| Critical | Smart meters, smart cards, secure elements | Mandatory certification |
Where a product could plausibly fit more than one class, the stricter class applies. Getting this classification right early matters, because it decides whether your team can self-assess or needs to budget time and cost for a notified body.
Key Obligations Under the CRA
The essential requirements sit in Annex I of the regulation, and they split roughly into properties the product must have and processes the manufacturer must run continuously.
Secure by Design and Default
Products must ship with a secure configuration out of the box and a minimized attack surface, and they must be free of known exploitable vulnerabilities at the point of sale.
Vulnerability Handling and Security Updates Under the CRA
Manufacturers need a standing process to identify, document, remediate, and disclose vulnerabilities, plus free and timely security updates for the product’s defined support period – generally at least five years unless the product’s expected use is shorter.
CRA Software Bill of Materials (SBOM) Requirement
Manufacturers must maintain a machine-readable SBOM covering the product’s components, so that both the manufacturer and, when needed, regulators can see exactly what is inside a given release.
Incident and Vulnerability Reporting
From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA and the relevant national CSIRT through a single reporting platform, on a defined clock: a 24-hour early warning, a fuller 72-hour notification, and a 14-day final report once the issue is resolved.
Conformity Assessment, CE Marking, and Technical Documentation
Demonstrating compliance follows a set sequence, and which route applies depends on the product’s class. Manufacturers compile technical documentation as evidence, retained for ten years after the product reaches the market, then carry out the conformity assessment appropriate to their class – self-assessment for Default products, harmonised standards or a notified body for Important products, and mandatory certification for Critical ones.
Once that’s done, the manufacturer draws up a signed EU declaration of conformity and affixes the CE marking, the visible signal to buyers and market surveillance authorities that the product meets the CRA’s requirements. For the full mechanics of each route, cyberresilienceact.eu’s CRA explainer walks through the article-by-article detail.
CRA Timeline and Penalties
The CRA is already in force. Its obligations phase in on a fixed schedule:
- 10 December 2024 – entered into force
- 11 June 2026 – Chapter IV applies, allowing conformity-assessment bodies to be notified ahead of full application
- 11 September 2026 – reporting obligations apply
- 30 August / 30 October 2026 – core harmonised-standards and product-classification dates fall due
- 11 December 2027 – full application; most provisions apply
That standards timeline is still actively moving. On 13 August 2026, ETSI opened a Public Enquiry on 17 draft vertical product standards written for the CRA, covering categories from password managers and VPNs to routers, operating systems, and smart-home security products. None of them currently confers the “presumption of conformity” a harmonised standard grants under Article 27 – that only follows once a standard is formally cited in the EU’s Official Journal, and the Commission has already pushed the delivery deadline for these drafts to 31 December 2026. In practice, manufacturers will be designing against draft requirements for a while yet, and the gap between a draft and its final wording is a risk companies carry themselves in the meantime.
Non-compliance carries real financial weight. Fines can reach €15 million or 2.5% of total worldwide annual turnover, whichever is higher, for breaches of the essential requirements or manufacturer obligations, with lower ceilings for lesser infringements. The European Commission’s own CRA policy page confirms the same figures and dates independently.
What This Means for Your Cloud and DevOps Environment
The CRA’s obligations are not a one-time filing. Vulnerability handling and incident reporting under Articles 13 and 14 are ongoing duties that a manufacturer has to sustain for years after a product ships, and that ongoing work runs on infrastructure: the CI/CD pipelines that build and sign releases, the identity providers that gate who can push a patch, and the network and security policy configuration that keeps those systems reachable during an incident.
To be clear, ControlMonkey does not perform CE marking, conformity assessment, or SBOM generation – that work belongs to your compliance and engineering teams. What ControlMonkey does is make the cloud and SaaS configuration behind that operational backbone recoverable. If a misconfiguration, drift, or an incident takes out the identity, network, or CI/CD configuration your team relies on to patch and report, sustaining your CRA obligations gets a lot harder, independent of whether the product’s code itself is compliant. That is the same disaster-recovery gap ControlMonkey closes for DORA compliance – restoring not just data, but the configuration layer required to operate.
Make Your Cloud Configuration Recoverable
Data recovery is only part of resilience. ControlMonkey helps you recover the cloud, identity, network, and SaaS configurations required to operate.
Cyber Resilience Act – Frequently Asked Questions
Does the Cyber Resilience Act apply to my product?
The Cyber Resilience Act likely applies to your product if it contains software or firmware, is placed on the EU market, and has a direct or indirect data connection. Key exceptions include certain sector-specific products, such as medical devices, vehicles, and aviation equipment, as well as non-commercial open-source software.
When does the Cyber Resilience Act take effect?
The Cyber Resilience Act entered into force on 10 December 2024, with requirements being phased in over time. Reporting obligations apply from 11 September 2026, while the majority of CRA obligations become applicable from 11 December 2027.
What is the difference between default, important, and critical products under the CRA?
The CRA classifies products by cybersecurity risk, with different conformity requirements for each category. Default products can generally be self-assessed, important products (Class I and II) face stricter assessment requirements, and critical products require mandatory third-party certification. When multiple classifications apply, the stricter category takes precedence.
Do I need a Software Bill of Materials (SBOM) under the CRA?
Yes. The Cyber Resilience Act requires manufacturers to identify and document the components contained in their products, including by creating a machine-readable Software Bill of Materials (SBOM). This forms part of the CRA’s cybersecurity requirements under Annex I.
What are the penalties for non-compliance with the CRA?
Non-compliance with the Cyber Resilience Act can result in significant financial penalties. Breaches of essential cybersecurity requirements or manufacturer obligations can lead to fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher.
Getting Ready Before December 2027
Full application feels distant, but the sequencing works against anyone who waits. Reporting obligations land first in September 2026, and they depend on infrastructure and processes that take months to stand up properly – vulnerability tracking, an SBOM pipeline, and a tested path to ENISA’s reporting platform.
A 30-min meeting will save your team 1000s of hours
A 30-min meeting will save your team 1000s of hours
Author
