Intro into Cyber Resilience Act: what product teams need to understand about the new EU regulation
The EU Cyber Resilience Act makes cybersecurity a market-access requirement for products with digital elements sold in the EU. The first reporting deadline hits in six months. Here’s what the regulation actually requires and what a realistic preparation path looks like for product teams.
TL;DR — Key takeaways:
- The EU Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024 and applies to any product with digital elements placed on the EU market — regardless of where the manufacturer is headquartered.
- The first operational deadline is 11 September 2026: manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA within 24 hours.
- Full compliance — conformity assessments, CE marking, Annex I essential requirements — is required by 11 December 2027 for all in-scope products.
- The CRA classifies products into four risk tiers (Default, Important Class I, Important Class II, Critical), each with a different conformity assessment path.
- ISO 27001 certification gives you a head start on governance, but the CRA requires product-level evidence: per-product risk assessments, SBOMs, technical files, and conformity documentation.
A product regulation, not an IT framework
The EU Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. It ends the era of voluntary cybersecurity standards for digital products in the EU. Unlike GDPR (which governs personal data) or NIS2 (which targets essential service operators), the CRA regulates the security of the products themselves, and it shifts the legal and financial responsibility for that security from end-users to manufacturers.
That distinction matters. Organisational certifications like ISO 27001 prove that your company manages information security well. The CRA asks a different question: is this specific product secure, and can you prove it? The answer requires product-level documentation, vulnerability handling processes, conformity assessments, and — for the first time in this context — CE marking for cybersecurity.
Research suggests it takes an average of 199 days to identify a data breach in industrial settings and another 73 days to resolve it, often because products were built without incident detection or forensic capabilities. A 2024–2025 consensus across vulnerability‑management research (e.g., VulnCheck, Verizon DBIR‑aligned analyses, and IBM‑linked patch‑management studies) indicates that roughly 20% or more of attacks exploit known vulnerabilities for which patches already exist but were not applied or poorly managed. The CRA addresses both problems: mandatory lifecycle vulnerability management and mandatory transparent reporting.
The regulation applies regardless of where your company is headquartered. If you place products on the EU market, you comply.
Regulations changed. Are you ready?
ins2outs AI-powered Regulatory Intelligence monitors the requirements that apply to your products and markets, maps every update directly to the controls it affects, and updates your team, giving enough time to act
Four deadlines, and the first one is close
The EU Cyber Resilience Act follows a phased implementation. In March 2026, the European Commission published draft guidance on applying the Cyber Resilience Act to help companies, particularly SMEs, navigate the regulation and provide feedback.
The milestones are fixed:
10 Dec 2024 – Entry into force
Regulation (EU) 2024/2847 became law. The Commission began developing technical guidance and implementing acts, including the technical descriptions of “Important” and “Critical” product categories (published November 2025).
11 Jun 2026 – Infrastructure
The legal framework for notifying Conformity Assessment Bodies (CABs) becomes active. Member states designate the notified bodies that will audit products in higher-risk categories. If your product is Important Class II or Critical, identify and pre-qualify these partners early, expect bottlenecks in 2027.
11 Sep 2026 – Reporting deadline
Manufacturers must report actively exploited vulnerabilities and severe incidents to the relevant CSIRT and ENISA, within 24 hours for an early warning, with full notification within 72 hours. This applies to products already on the market, not just new launches. Triage workflows, escalation paths, and ENISA reporting mechanisms must all be operational.
11 Dec 2027 – Full compliance
All in-scope products placed on the EU market must meet the essential cybersecurity requirements of Annex I, have undergone the required conformity assessment, and bear the CE marking. Products on the market before this date are generally grandfathered — unless they undergo a “substantial modification” (more on this below).
The September 2026 deadline for EU Cyber Resilience Act reporting may catch many teams off guard.
It doesn’t require full product compliance, but it does require operational vulnerability reporting processes.
If you discover an actively exploited vulnerability in your product, you need to notify authorities within 24 hours. That means triage workflows, escalation paths, and ENISA reporting mechanisms all need to exist and be tested before September.
What's in scope of the EU Cyber Resilience Act and what falls outside
The EU Cyber Resilience Act defines its scope around “products with digital elements” (PDEs).
The definition is intentionally broad: any software or hardware product — and its remote data processing solutions — whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. This covers everything from simple IoT sensors and mobile apps to complex industrial control systems and operating systems.
In CRA scope:
-
- Hardware devices with embedded software or firmware;
- Standalone software that users download and run locally (apps, SDKs, desktop software);
- Connected and network-capable products across consumer, industrial, and professional categories;
- Software components placed on the market separately;
- Open-source software that is monetised in any form: if you make money from it, you’re treated as a manufacturer.
Explicitly excluded from CRA:
-
- Medical devices covered by the MDR and IVDR (they have their own cybersecurity requirements);
- Motor vehicles subject to UN R155/R156 type-approval;
- Products developed exclusively for military or national security purposes (including command and control systems, classified software, and encryption devices certified by national intelligence agencies)
- Pure SaaS accessed solely through a browser (this generally falls under NIS2 instead).
The SaaS trap
If your SaaS product serves as the backend for a physical device you sell — the cloud that runs a smart doorbell, the server that controls an industrial sensor — that software is caught by the CRA.
The scope follows the product, not the deployment model.
The question is whether the user receives or possesses something (an app, firmware, a binary), not how you architect it.
Open source: a new regulatory category
The CRA introduces the “open-source software steward” — a new type of economic operator for organisations (typically foundations or platforms) that support the development of non-commercial open-source software. Stewards have lighter obligations than manufacturers, primarily coordinated vulnerability disclosure and severe incident reporting, but they are formally included in the regulatory framework for the first time.
Non-commercial hobby projects, research code, and strictly non-profit software remain generally exempt. But if you monetise your open-source project in any form, you’re treated as a manufacturer with full obligations.
Quick EU Cyber Resilience Act applicability test:
-
- Does your product contain or depend on software?
- Is it placed on the EU market?
- Does the user receive or install something (an app, firmware, a binary)?
If all three are yes, the CRA almost certainly applies. Want to dive deeper? Use our gap assessment tool.
Take the CRA gap assessment
Check our Cyber Resilience Act gap assessment tool, and we’ll follow up with a summary of where you stand and what to focus on first.
Risk classification: four tiers, four conformity paths
The CRA classifies products by risk, which determines the rigour of your conformity assessment, and whether you can self-assess or need a notified body.
| Classification |
Examples |
Conformity path |
|
Default |
|
Self-assessment |
|
Important — Class I |
|
Self-assessment if using harmonised standards; otherwise, third-party assessment by a notified body. |
|
Important — Class II |
|
Mandatory notified body involvement. |
|
Critical |
|
Mandatory EU cybersecurity certification or high-assurance notified body audit. |
The European Commission published an implementing regulation in November 2025 (Commission Implementing Regulation (EU) 2025/2392) with technical descriptions for each category. Several draft harmonised standards are also in the “mature draft” stage, developed by ETSI, CEN, and CENELEC, covering specific product types including browsers, password managers, antivirus software, VPNs, network management systems, SIEM platforms, and boot managers.
If your product sits near a classification boundary, get specific advice early. Misclassification in either direction creates problems: unnecessary certification costs if you over-classify, or non-compliance exposure if you under-classify.
Industry-specific implications
The CRA is horizontal, it applies across sectors, but the practical impact varies significantly depending on what you build.
AI and machine learning products
AI systems that connect to networks for training, data ingestion, or real-time inference fall within scope as products with digital elements.
The CRA and the EU AI Act (Regulation (EU) 2024/1689) work together: if a high-risk AI system meets the CRA’s cybersecurity requirements, it’s presumed to satisfy the cybersecurity obligations of the AI Act’s Article 15. This prevents regulatory duplication, but AI teams must extend their risk assessments beyond standard software vulnerabilities to include AI-specific threats: data poisoning, model manipulation, and adversarial inputs.
The CRA requires technical solutions “appropriate to the circumstances and risks involved,” which for AI products means integrating adversarial resilience testing into standard QA.
Healthcare and medtech
Medical devices covered by the MDR/IVDR are excluded from the CRA’s scope. But the CRA sets a higher horizontal cybersecurity benchmark that influences expectations across the sector.
Products near the boundary — health and wellness devices, clinical software that doesn’t qualify as a medical device — fall under the CRA directly.
The fail-safe and lifecycle security requirements are particularly relevant: a connected health product that loses its network link must continue to provide its core function safely. For life-critical adjacent products, this means hardcoded backup routines, local state storage, and physical or logical separation of control systems from connectivity layers.
Industrial, IoT, and agricultural machinery
The broadest impact area. Industrial controllers, building automation, smart sensors, and connected machinery are all in scope.
A significant gap exists for agricultural and forestry vehicles (Categories T, R, S) — these are not covered by UN R155, so the CRA is the primary regulation for smart tractors, autonomous harvesters, and connected implements.
Development teams used to hardware-centric design face a shift toward secure-by-design architectures with over-the-air update capability and documented risk assessments. Small and medium-sized suppliers of components (such as tractor-implement management systems) now carry direct legal responsibility for CRA compliance.
Consumer electronics
Most consumer products fall into the Default category — self-assessment by the manufacturer. But “Default” does not mean “low standard.”
Products must still ship with secure defaults, no weak default passwords, and a published contact for vulnerability reports.
The support period obligation means that a smart speaker sold today with a claimed 5-year lifespan needs free security patches for the full five years. For hardware with limited memory or processing power, teams must plan for how to deliver modern security updates to constrained devices over a long deployment period.
ISO 27001 helps — but it's not enough
If your organisation holds ISO 27001 certification, you have a meaningful head start. Your risk management framework, security policies, incident response processes, and supplier management controls all contribute to the governance backbone that CRA compliance requires at the organisational level.
But the CRA demands more.
ISO 27001 certifies your information security management system — the organisation.
The CRA certifies each product. That means extending your existing controls into product-specific territory:
- per-product risk assessments,
- per-product technical files,
- per-product SBOM generation,
- per-product conformity evidence.
Vulnerability handling processes need to include ENISA reporting timelines and product-specific escalation paths. Your existing A.8.8 vulnerability management controls need to be extended to cover vulnerabilities in your products (not just your infrastructure), with customer notification and 24/72-hour ENISA reporting layered on top.
The most efficient architecture:
- use the Information Security Management System as the organisational governance layer (policies, risk methodology, supplier management, training, incident response),
- then extend it with per-product CRA documentation (technical files, SBOMs, conformity assessments, support period statements).
One system, one set of processes, one audit trail that serves both ISO 27001 and CRA obligations without duplication, and ins2outs is built to support exactly this architecture.
Already ISO 27001 certified?
ins2outs provides an operational ISMS extended with a CRA-specific Know-How Set out-of-the-box, so you add product-level compliance without rebuilding.