EU regulations · Cyber Resilience Act
Article 14 reporting starts 11 September 2026Cyber Resilience Act
Compliance for Every
Product You Ship
Turn CRA obligations into assigned controls, linked evidence, and a conformity trail per product. Reporting duties start 11 September 2026, and they cover products already on the market.
What you need to know
- Products with digital elements made available on the EU market are in scope: connected software and hardware, plus the cloud backends they cannot run without, wherever your company sits; sectoral carve-outs and standalone SaaS sit outside.
- Reporting starts 11 September 2026. Actively exploited vulnerabilities and severe incidents go to your CSIRT and ENISA within 24 hours, including for products already on the market.
- The full obligation set lands 11 December 2027: secure-by-design evidence, SBOM, support period, technical documentation, CE marking. Exposure runs to €15M or 2.5% of worldwide turnover.
What the Cyber Resilience Act is
The Cyber Resilience Act (Regulation (EU) 2024/2847) is the EU's first horizontal product-security law. Where NIS2 regulates organizations and the EU AI Act regulates AI systems, the CRA regulates the products themselves: any hardware or software with digital elements placed on the EU market must be secure by design, ship without known exploitable vulnerabilities, and receive security updates for its support period.
The regulation entered into force on 10 December 2024 and phases in through 2027. The obligation to report actively exploited vulnerabilities and severe incidents applies from 11 September 2026, and it covers products already on the market. The full set of essential requirements, CE marking among them, applies from 11 December 2027.
Where things stand
Two dates ahead decide your plan, and the reporting start comes first.
Today
Spacing proportional to time from today
11 Jun 2026
now in effect
Notified-body designations under way
11 Sep 2026
in 1 month
Article 14 reporting starts, including for products already on the market
11 Dec 2027
in 16 months
Full application: Annex I requirements, conformity assessment, CE marking
Today
11 Jun 2026
now in effect
Notified-body designations under way
11 Sep 2026
in 1 month
Article 14 reporting starts, including for products already on the market
11 Dec 2027
in 16 months
Full application: Annex I requirements, conformity assessment, CE marking
Behind us: in force since 10 December 2024; Commission application guidance published July 2026; the first harmonised standards are expected from CEN/CENELEC through late 2026 and 2027.
Does the CRA apply to you?
Two questions decide it: is your product a product with digital elements on the EU market, and which role do you hold for it? Scope follows the product, wherever your company sits.
The Article 3 product test
A product with digital elements is any software or hardware that connects, directly or indirectly, to a device or network: apps, operating systems, firmware, connected devices, and components sold separately.
Who carries which duties
Carries the full obligation set: secure design, the cybersecurity risk assessment, Annex I compliance, vulnerability handling, the support period, technical documentation, conformity assessment, CE marking, and Article 14 reporting.
Acts in the EU on a written mandate for a non-EU manufacturer: keeps documentation available, cooperates with authorities, and can carry delegated reporting tasks.
May only place compliant products on the market. Verifies that the manufacturer ran conformity assessment, that documentation exists, and that the product bears the CE marking.
Acts with due care: checks the CE marking and required information, and stops supplying a product it has reason to believe is non-conforming.
A lighter Article 24 regime for foundations and similar bodies supporting open source: a documented cybersecurity policy, cooperation with authorities, and Article 14 reporting where the steward is involved in development, without CE marking or conformity assessment.
What stays out
- Medical devices and in-vitro diagnostics under MDR and IVDR
- Vehicles covered by the type-approval regime (Regulation (EU) 2019/2144)
- Aviation equipment certified under the EU Basic Regulation
- Marine equipment under the Marine Equipment Directive
- Products developed exclusively for national security or defence
- Spare parts that replace identical components
Careful with the edges: wellness and fitness software that is not a medical device stays in CRA scope, but only certified-category drones are excluded; open- and specific-category drones remain in.
Which of the five reach you?
Answer for your company, and see the stack you actually manage. Most teams arrive here for one regulation and leave managing three.
You came for the CRA. Tick what else is true and watch the stack grow.
A one-question check gives orientation only; actual scope turns on each regime's territorial, entity-size, and product tests.
Which class is your product in?
Classification decides who checks your work. Most products self-assess; the closer a product sits to a security function, the more third-party involvement the CRA demands.
| Class | Conformity route | Examples |
|---|---|---|
| Defaultmost products | Self-assess Internal control (Module A) | Ordinary apps, games, most business software, connected devices without a security function |
| Important · Class IAnnex III | Standards route Self-assessment only with harmonised standards, common specifications, or a European cybersecurity certification applied in full; otherwise a notified body | Password managers, VPNs, browsers, operating systems, malware tools, smart-home security devices, connected toys, health wearables |
| Important · Class IIAnnex III | Third party EU-type examination plus production control, full quality assurance, or a certification scheme at assurance level substantial | Hypervisors and container runtimes, firewalls, intrusion detection and prevention systems, tamper-resistant microprocessors |
| CriticalAnnex IV | Certification European cybersecurity certification once a scheme is designated; Class II modules until then | Hardware devices with security boxes, hardware security modules among them, smart meter gateways, smartcards and secure elements |
The essential requirements are identical across all four classes, but a wrongly classified product fails conformity assessment even when its security engineering is sound.
What do you owe?
Annex I comes down to two duties: build the product secure, then keep it secure for as long as you support it.
Before you ship · Part I, 13 properties
- No known exploitable vulnerabilities
- Secure by default, with a reset path
- Authentication and access control
- Encryption at rest and in transit
- Only the data the product needs
- Minimal attack surface
After you ship · Part II, 8 duties
- Machine-readable SBOM
- Fix vulnerabilities without delay
- Free security updates
- Coordinated disclosure, public contact point
- Regular security testing
- Support for 5 years, or expected use if shorter
Every requirement applies risk-based, but a documented justification can mark one not applicable. Technical documentation, the EU declaration of conformity, and the CE marking close the loop.
What happens when something goes wrong?
From 11 September 2026, Article 14 sets one reporting cascade for two kinds of events: vulnerabilities under active exploitation, and severe incidents. The first two steps are shared; the final report depends on which event you are reporting.
| Step | Deadline | Content |
|---|---|---|
| Early warning | 24 h from becoming aware | The vulnerability or incident exists; whether more than one member state is affected |
| Notification | 72 h from becoming aware | Nature and severity; corrective or mitigating measures taken or available to users |
| Final report · vulnerability | 14 days after a corrective or mitigating measure is available | The vulnerability, its severity, and the corrective or mitigating measure |
| Final report · incident | 1 month after the 72-hour notification | Severity, impact, the likely cause, and the mitigations applied |
Where reports go: through the single reporting platform ENISA operates under Article 16, which routes each notification to the CSIRT designated for your main EU establishment.
What happens if you get it wrong?
Article 64 sets three tiers of maximum administrative fines, scaled to what was breached. The higher of the fixed amount and the percentage applies.
Annex I requirements and the manufacturer duties in Articles 13 and 14, reporting included
Article 64(2)
Other obligations listed in Article 64(3), notified bodies included
Article 64(3)
Incorrect, incomplete, or misleading information to authorities
Article 64(4)
Pick a global annual turnover to draw all three tiers to scale.
At €50M global turnover the fixed amounts set the ceiling: 2.5% is only €1.3M, so the top tier stays at €15M. The notch marks each percentage amount.
At €250M global turnover the fixed amounts set the ceiling: 2.5% is only €6.3M, so the top tier stays at €15M. The notch marks each percentage amount.
At €2B global turnover the percentages set the ceiling: 2.5% is €50M and 1% is €20M. The notch marks the fixed amounts they overtake.
At €10B global turnover the percentages set the ceiling: 2.5% is €250M and 1% is €100M. The notch marks the fixed amounts they overtake.
The steepest tier is reserved for the substance: the Annex I essential requirements and the manufacturer obligations in Articles 13 and 14, reporting included. Member states set the actual fine rules nationally within these ceilings, and Article 64(5)(c) makes the offender's size and SME status a factor in setting the amount.
Fines are one lever among several. Market surveillance authorities can require corrective action, restrict availability, or order a product withdrawn or recalled under Articles 54 to 58, which for a shipping software product is usually the sharper threat.
How regimes stack on one AI system
The CRA regulates the product itself. Ship the same AI system as software and the product-security duties stack on top of everything else. Here is how one system accumulates duties across regimes.
Worked example · SYS-04 · credit-scoring model at an EU-serving bank
Credit scoring is Annex III point 5(b): the model is a high-risk AI system.
- Articles 9 to 17 high-risk stack
- Conformity assessment
- EU database registration
Personal data runs through training, inputs, and outputs, and a solely automated credit denial is an Article 22 decision.
- Lawful basis for each processing purpose
- Article 35 DPIA
- Data-subject rights incl. Article 22
At a financial entity, the model is ICT supporting a critical or important function.
- Chapter II ICT risk management
- Major-incident reporting
- Register of information entry
For financial entities NIS2 is largely disapplied: DORA is lex specialis under NIS2 Article 4. Run the same model at an energy or health company and the Article 21 measures attach instead.
- Article 21 cybersecurity measures (where in scope)
- 24h early warning, 72h notification
If the model ships to the bank as licensed software, it is a product with digital elements and the vendor carries manufacturer duties. Run purely as an internal model or hosted service, it stays outside the CRA and the entity regimes above cover it.
- Annex I secure-by-design & vulnerability handling
- Article 14 reporting (24h/72h)
- Article 12 bridge to AI Act Article 15
The regimes overlap where the controls live. Map controls once, keep one evidence record, and reuse it across every regime that attaches; the Modulos platform is built on that working model.
The regimes overlap where the controls live
The governance graph maps every control in the framework library to every regulation it serves. Where regimes map the same control, one implementation and one evidence record can support all of them, subject to each regime's own requirements, and most of the CRA's controls already serve at least one other framework.
Framework library v1.0.28
How the work gets done
Modulos gives product security and compliance teams one workflow for requirements, controls, evidence, reviews, and exports. The CRA framework pair turns the regulation into assigned work per product and per organization, with the evidence trail conformity assessment expects.
Start from a ready-made CRA framework pair
The Modulos framework library ships the CRA in both scopes: an application framework that assesses one product across scope, classification, risk assessment, Annex I, support period, and CE marking, and an organization framework for manufacturer capabilities and economic-operator roles.
Assess each product on its own facts
Scope determination, product class, conformity route, and the Article 13 risk assessment are per-product questions. Run each product as its own assessment while the organization-level duties stay assessed once.
Treat justified non-applicability as complete
Annex I Part I is risk-based: a documented justification that a requirement does not apply is a completed outcome, and the CRA framework treats it that way instead of reporting a false gap.
Reuse controls across regimes
CRA outcomes share controls with ISO/IEC 27001, the EU AI Act, and NIS2 in the library, so vulnerability handling, testing, and incident processes produce one body of evidence that serves every framework that attaches.
Keep the Article 12 bridge documented
For high-risk AI systems, the framework tracks the Article 12 branch explicitly, so the CRA work that earns the EU AI Act Article 15 presumption of conformity is visible and exportable when the AI Act assessment needs it.
Be ready for 11 September 2026
The organization framework carries the Article 14 reporting duties as their own requirement: intake, triage, the 24-hour and 72-hour notifications, and final reports, with owners, evidence, and review history attached.
How the CRA fits with other frameworks
The CRA and the NIS2 Directive divide the territory: the CRA secures products, NIS2 secures the organizations that run them. Shipped software falls under the CRA, while a standalone SaaS provider escapes it and instead meets NIS2 where it qualifies as an essential or important entity, and a vendor that both makes products and operates such services answers to both regimes, including two separate reporting tracks for the same event.
For AI builders, CRA Article 12 is the bridge to the EU AI Act: a high-risk AI system in CRA scope that fulfils the CRA's Annex I and demonstrates it in the CRA declaration of conformity is deemed to meet the AI Act's Article 15 cybersecurity requirement. GDPR applies in parallel wherever the product processes personal data.
Operationally, the Annex I requirements land on ground ISO/IEC 27001 programs already cover: secure development, vulnerability management, access control, and logging. ISO/IEC 42001 supplies the AI-management layer for AI-enabled products, and NIST AI RMF supports the Article 13 risk assessment without substituting for it.
For US-attestation work, SOC 2 control sets share evidence with CRA vulnerability-handling and change-management controls, especially around testing, release, and incident response.
FAQ about the Cyber Resilience Act
The Cyber Resilience Act (Regulation (EU) 2024/2847) is the EU’s horizontal product-security law. It sets mandatory cybersecurity requirements for products with digital elements, meaning hardware and software, placed on the EU market. It entered into force on 10 December 2024. Reporting obligations apply from 11 September 2026, and the main obligations apply from 11 December 2027.
The CRA applies in three stages under Article 71. Provisions on notified conformity assessment bodies apply from 11 June 2026. The Article 14 obligations to report actively exploited vulnerabilities and severe incidents apply from 11 September 2026. All remaining obligations, including the Annex I essential requirements, CE marking, and technical documentation, apply from 11 December 2027.
The CRA covers products with digital elements: hardware and software whose intended purpose involves a direct or indirect connection to a device or network, including their remote data processing solutions. Excluded are products already covered by equivalent sectoral rules, such as medical devices, type-approved vehicles, certified aviation equipment, and marine equipment, plus products developed exclusively for national security or defence purposes.
Standalone SaaS and other pure cloud services are generally outside CRA scope; their providers may instead face NIS2 duties where they meet its entity and size tests. A cloud component is in scope only when it qualifies as remote data processing: processing designed by the manufacturer, or under its responsibility, without which the product could not perform one of its functions. Where an AI product ships as installed software with a required backend, both halves can fall in scope.
Open-source software developed or supplied outside a commercial activity is out of scope. Monetized or commercially supported open source is treated like any other product. In between, Article 24 creates a light-touch regime for open-source software stewards, such as foundations: a cybersecurity policy, cooperation with market surveillance authorities, and the Article 14 reporting duties to the extent the steward is involved in development, but no CE marking and no conformity assessment.
Yes. The CRA attaches to any product with digital elements made available on the EU market, wherever the manufacturer is established. Non-EU manufacturers typically act through an authorised representative, and importers and distributors carry their own verification duties under Articles 19 to 21. A US or UK software vendor selling into the EU faces the same Annex I requirements and reporting obligations as an EU manufacturer.
Annex I Part I sets product requirements: a risk-based secure design, no known exploitable vulnerabilities at release, secure default configuration, security updates, access control, encryption of data at rest and in transit, integrity protection, data minimisation, availability protection, a minimised attack surface, and security logging. Part II adds vulnerability-handling duties, including a machine-readable SBOM, coordinated vulnerability disclosure, regular testing, and free security updates for the support period.
From 11 September 2026, manufacturers must report any actively exploited vulnerability and any severe incident affecting a product’s security. Article 14 sets a cascade: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days for vulnerabilities or one month for severe incidents. Reports go to the designated CSIRT and ENISA through the EU single reporting platform.
Annex III lists important products in two classes. Class I includes password managers, VPNs, browsers, operating systems, and smart-home security devices; Class II includes hypervisors, firewalls, and tamper-resistant microprocessors. Annex IV lists critical products such as hardware security modules, smart meter gateways, and smartcards. Higher classes face stricter conformity assessment, up to mandatory third-party involvement, while most ordinary products self-assess.
Article 64 sets three tiers of administrative fines. Breaching the Annex I essential requirements or the manufacturer obligations in Articles 13 and 14 carries fines up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher. Other obligations carry up to €10 million or 2%. Supplying false or misleading information to authorities carries up to €5 million or 1%. Market surveillance authorities can also restrict or recall products.
CRA Article 12 builds a bridge between the two regimes. A high-risk AI system that is also a product with digital elements is deemed to satisfy the EU AI Act’s Article 15 cybersecurity requirement when it meets the CRA’s Annex I essential requirements and documents that in its CRA declaration of conformity. Teams that map controls once can reuse the same evidence across both conformity assessments.
The Modulos framework library includes a dedicated CRA framework pair: an application-scope framework that assesses one product across scope, classification, the cybersecurity risk assessment, the Annex I requirements, support period, and CE marking, and an organization-scope framework covering manufacturer capabilities such as SBOM operations, coordinated disclosure, and Article 14 reporting. Controls are shared with ISO/IEC 27001, the EU AI Act, and NIS2, so evidence is reused rather than duplicated.
By industry
How this applies in your sector
The CRA lands hardest where connected products meet regulated infrastructure. See how it stacks with the EU AI Act and sector rules:
Where the CRA work goes next
Talk to an expert
Walk through your product portfolio with someone who has stood up the CRA framework pair before.
Book a CRA demo →Keep exploring on your own
The framework docs cover the CRA requirement by requirement, and the governance graph shows how its controls reuse across regimes.