The Cyber Resilience Act (Regulation (EU) 2024/2847) sets mandatory cybersecurity requirements for hardware and software products with a data connection sold in the EU. It applies to manufacturers, importers, and distributors anywhere in the world, with reporting obligations starting September 11, 2026, and full requirements from December 11, 2027.
The Cyber Resilience Act is an EU regulation that sets mandatory cybersecurity requirements for products with digital elements across their entire lifecycle, from design through to end of support. Its formal name is Regulation (EU) 2024/2847, adopted on October 23, 2024, and in force since December 10, 2024.
Before the CRA, no single EU law told a manufacturer what "secure enough" meant for a connected product. Now a product may only be made available on the EU market if it meets the essential cybersecurity requirements in Annex I and carries the CE marking that proves it.
Because the CRA is a regulation rather than a directive, it applies directly in all 27 member states. Read the official text on the European Commission's Cyber Resilience Act page.
A product with digital elements is any hardware or software product with a direct or indirect data connection to a device or network. That definition could capture more of your portfolio than you think, with examples like these:
If it processes data and can connect to another device or network, assume it's in scope.
The cyber resilience vs cyber security distinction comes up constantly in CRA conversations. Cyber security describes the work of preventing attacks: hardening systems, controlling access, patching vulnerabilities, and keeping attackers out. Cyber resilience describes what happens when prevention fails, and enables an organization or a product to keep operating through an attack, contain the damage, and recover quickly.
The CRA uses the broader term, and the Act itself concentrates on product security by design. It tasks manufacturers with shipping products without known exploitable vulnerabilities and fixing problems throughout the support period. Resilience comes from that lifecycle commitment.
The CRA places obligations at every stage of the supply chain:
Manufacturers carry the heaviest load. Importers and distributors check that the CE marking, documentation, and conformity assessment are in place before a product moves.
The CRA also reaches beyond EU borders: a US software vendor with EU customers and a Singaporean IoT company shipping to European retailers are both in scope.
Yes. If a UK company places products with digital elements on the EU market, the CRA applies in full. A British manufacturer selling connected devices into Germany faces the same essential requirements, deadlines, and penalty exposure as a German one.
The practical line is simple. UK-only sales don't trigger CRA obligations, but any EU market presence does, whether you sell directly, through a distributor, or through a marketplace. Many UK vendors will also need an authorized representative established in the EU.
The CRA avoids duplicating sector-specific EU law. The following sit outside its scope:
Check exemptions product by product: a medical device manufacturer that also sells a connected fitness tracker is in scope for the tracker.
The CRA came from the 2020 EU Cybersecurity Strategy and the EU Security Union Strategy, and it complements the NIS2 Directive. NIS2 governs how organizations manage cyber risk, the CRA governs products.
The Commission identified three problems worth fixing:
The CRA aims to answer all three. It provides a floor for product security, a defined support period, and visible compliance through the CE marking.
CRA requirements fall into two groups: Annex I Part I covers the product, while Annex I Part II and Articles 13 and 14 cover the manufacturer's processes.
| Product requirements (Annex I, Part I) | Manufacturer process obligations |
| Secure by design and by default, at a level appropriate to the risk | Run and document a risk assessment before market placement |
| No known exploitable vulnerabilities at release | Operate a documented vulnerability handling process |
| Secure default configuration, with a factory reset option | Ship security updates for five years, or for the product lifetime if shorter |
| Data confidentiality and integrity, plus a minimized attack surface | Keep documentation for 10 years or the support period, whichever is longer |
| Secure update mechanisms and logging of internal activity | Report actively exploited vulnerabilities and severe incidents |
Two of these catch teams off guard: the requirement for a five-year support commitment turns a product decision into a multi-year budget line, and the ban on known exploitable vulnerabilities means your release gate needs a component-level view of what you ship.
An SBOM is a structured inventory of the software components in your product, including third-party libraries. The CRA requires manufacturers to produce one covering at least the top-level dependencies and keep it in their technical documentation.
An SBOM's value shows up the day a major vulnerability lands. Teams without it spend days searching repositories to see whether they're affected, while those who prepared can find the answer in minutes. Given the 24-hour early warning reporting window, that difference decides whether you meet the compliance deadline.
The CRA sorts products into risk categories, and the category determines how much external scrutiny your conformity assessment needs.
| Category | Examples | Conformity assessment |
| Default | Roughly 90% of products: standard software, consumer electronics, lower-risk IoT | Self-assessment |
| Important, Class I (Annex III) | Password managers, browsers, antivirus, VPNs, routers, operating systems, smart home assistants, connected toys | Self-assessment where harmonized standards apply in full, otherwise third-party |
| Important, Class II (Annex III) | Hypervisors, container runtimes, firewalls, intrusion detection and prevention systems | Third-party assessment by a notified body |
| Critical (Annex IV) | Hardware security modules, smart meter gateways, smartcards and secure elements | Third-party, with possible mandatory certification |
Classify early: a Class II product needs a notified body, and EU capacity is finite.
The CRA isn't a single 2027 deadline. Reporting obligations arrive first, and they apply to your current portfolio.
| Date | Milestone |
| December 10, 2024 | The CRA enters into force |
| June 11, 2026 | Rules on notifying conformity assessment bodies apply |
| September 11, 2026 | Article 14 vulnerability and incident reporting obligations apply |
| December 11, 2027 | Full application: essential requirements, conformity assessment, and CE marking |
September 2026 requires you to detect an actively exploited vulnerability and report it within 24 hours. December 2027 asks whether what you ship meets Annex I.
From September 11, 2026, manufacturers must report two kinds of events:
The obligation runs on a three-stage clock:
The European Union Agency for Cybersecurity ENISA is building the CRA Single Reporting Platform (SRP) to centralize this. You submit once, the platform routes the notification to the Computer Security Incident Response Team (CSIRT) where you have your main establishment, and ENISA receives it at the same time.
Three things to put in place now:
From December 11, 2027, a product with digital elements needs a CE marking to reach the EU market. That mark is the outward sign that a manufacturer has done three things: assessed the product against the CRA's essential requirements (handling responsibilities like secure-by-default configuration, vulnerability handling, no known exploitable vulnerabilities at release), written up technical documentation proving it, and signed an EU Declaration of Conformity.
The CRA uses the presumption-of-conformity mechanism found in other EU product laws. Here's what that means: The Cyber Resilience Act's Annex I's requirements are written as broad principles ("the product shall protect against unauthorized access"), which are challenging to test directly.
The Commission asks European standards bodies to write detailed technical standards that implement those principles. Once a standard is formally cited in the Official Journal of the EU, following it creates a legal presumption that you've met the corresponding essential requirement.
For "Important Class I" products specifically, having that presumption available is also what unlocks self-assessment as a way to conform with the CRA.
As of early September, these standards are not yet available. But waiting is still the wrong move. Standards make conformity easier to demonstrate, and they're not a prerequisite for a secure product. Design against Annex I now and map to the standards once they land.
Article 64 sets three tiers of administrative fines, enforced by national market surveillance authorities. Each is whichever figure is higher.
| Infringement | Maximum fine |
| Breaching the essential requirements in Annex I, or the manufacturer obligations in Articles 13 and 14 | €15 million or 2.5% of worldwide annual turnover |
| Breaching other CRA obligations, including those on importers, distributors, and conformity assessment | €10 million or 2% of worldwide annual turnover |
| Supplying incorrect, incomplete, or misleading information to notified bodies or authorities | €5 million or 1% of worldwide annual turnover |
Fines are only part of the exposure. Authorities can also order corrective action, withdrawal, or recall, and losing EU market access hurts most manufacturers more than a fine.
The CRA does build in proportionality. Microenterprises and small businesses can't be fined for missing the 24-hour early warning deadline specifically, and open-source stewards face no administrative fines at all.
Circumstances will always be different from one organization to another. But in general, it's considered best practice to follow these steps in order, because each makes the next one easier to execute.
Teams often ask which of the two applies to them. For many companies the answer is both.
| Cyber Resilience Act | NIS2 Directive | |
| What it regulates | Products with digital elements | Organizations |
| Core obligation | Security by design across the product lifecycle | Cyber risk management and governance |
| Who is in scope | Manufacturers, importers, and distributors selling into the EU | Essential and important entities in critical sectors |
| Proof of compliance | CE marking and EU Declaration of Conformity | Supervision by national competent authorities |
| Headline penalty | €15 million or 2.5% of worldwide turnover | €10 million or 2% for essential entities |
A device manufacturer supplying the energy sector can be a CRA manufacturer and a NIS2-important entity at once. Helpfully, the work overlaps: risk assessments, vulnerability management, and incident response serve both regulations.
For a full breakdown of NIS2 scope and obligations, see our NIS2 Directive hub.
The CRA treats open source with a lighter touch where no commercial activity is involved. Software developed and supplied outside a commercial activity falls outside the regulation entirely, so contributing to a project in your own time doesn't make you a manufacturer.
Then comes the open-source steward: a legal entity, different from a manufacturer, sustaining open-source products intended for commercial activities. Foundations maintaining widely used projects typically fall here.
Stewards carry proportionate duties. They need a documented cybersecurity policy. In addition, they must cooperate with market surveillance authorities, and report actively exploited vulnerabilities. However, they face no administrative fines.
If you build a commercial product on open-source components, you're the manufacturer, and full obligations apply to what you ship, including the open-source parts. Your SBOM and your vulnerability handling both need to cover them.
It can. Any UK company placing products with digital elements on the EU market is in scope, regardless of Brexit. UK-only sales don't trigger CRA obligations, but any EU market presence does.
Fines reach €15 million or 2.5% of worldwide annual turnover, whichever is higher, for breaching the essential requirements in Annex I or the manufacturer obligations in Articles 13 and 14. Other infringements carry up to €10 million or 2%, and supplying incorrect information up to €5 million or 1%. Authorities can also order a withdrawal or recall from the EU market.
The CRA regulates products and applies to manufacturers, importers, and distributors. NIS2 regulates organizations and applies to essential and important entities in critical sectors. Many companies are in scope for both, and the underlying work overlaps.
It depends on the commercial context. Non-commercial open-source software falls outside the regulation. Open-source stewards supporting projects used commercially carry lighter obligations and face no fines. Products built commercially on open-source components attract full manufacturer obligations.
Products already regulated under sector-specific EU law: medical devices, motor vehicles, civil aviation products, and marine equipment. Products developed exclusively for national security or defense are also excluded, along with non-commercial open-source software and spare parts.
September 11 2026. From that date, manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform, with a 24-hour early warning, a 72-hour notification, and a final report within 14 days or one month. These obligations also cover products already on the market.
_HighPerformer_HighPerformer.svg)
TISAX® is a registered trademark of the ENX Association. DataGuard is not affiliated with the ENX Association. We provide Software-as-a-Service and support for the assessment on TISAX® only. The ENX Association does not take any responsibility for any content shown on DataGuard's website.
All data provided is for information only, based on internal estimates. This information is not indicative of KPIs, and is not given with any warranties or guarantees, expressly stated or implied in relation to accuracy and reliability.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "www.dataguard.com#organization",
"name": "DataGuard",
"legalName": "DataCo GmbH",
"description": "DataGuard, the European leader in security and compliance software, is trusted by more than 4,000 organizations across 50+ countries. We help you identify and manage your security and compliance risks and fast-track your certifications and compliance by combining expert consultancy with AI-powered automation. Our purpose-built, all-in-one platform is developed with the experience of over 1.5 million total hours by a team of certified security and compliance experts.",
"foundingDate": "2018",
"taxID": "DE315880213",
"logo": "https://7759810.fs1.hubspotusercontent-na1.net/hubfs/7759810/DataGuardLogo.svg",
"url": "www.dataguard.com",
"email": "info@dataguard.de",
"telephone": "+49 89 452459 900",
"address": {
"@type": "PostalAddress",
"streetAddress": "Sandstrasse 33",
"addressLocality": "Munich",
"addressRegion": "Bavaria",
"postalCode": "80335",
"addressCountry": "Germany"
},
"sameAs": [
"https://www.linkedin.com/company/dataguard1/",
"https://www.youtube.com/channel/UCEQzPZ6sCBCj9cAoBvaLL6w",
"https://x.com/i/flow/login?redirect_after_login=%2FDataGuard_dg"
]
}
]
}✅ Organization schema markup for "DataGuard" has been injected into the document head.