The Cyber Resilience Act (CRA) is one of the most impactful EU cybersecurity regulations ever introduced. It establishes mandatory security requirements for all products with digital elements—software, firmware, connected hardware, IoT devices, and embedded systems—throughout their entire lifecycle.
The CRA will reshape how digital products are designed, developed, tested, documented, supported, updated, and monitored. With obligations applying from 2026 and in full from December 2027, organisations must begin preparing now to avoid legal risk, market disruption, and costly non-compliance.
This guide provides a deep, expert-level overview of the Cyber Resilience Act: scope, roles, classification, essential requirements, documentation, reporting obligations, conformity assessments, and actionable preparation steps.
What Is the Cyber Resilience Act?
The CRA is an EU-wide regulation designed to strengthen cybersecurity across digital products. Unlike voluntary standards or sector-specific directives, the CRA applies universally to any product with digital elements placed on the EU market.
Its main objectives are to:
- Reduce the number of insecure digital products sold in the EU
- Require cybersecurity-by-design and security-by-default practices
- Establish consistent vulnerability handling and disclosure processes
- Introduce mandatory incident reporting for exploited vulnerabilities
- Guarantee long-term support and security updates
- Ensure transparent and verifiable technical documentation
According to the European Commission, the CRA responds to two problems: the low level of cybersecurity of many digital products, and the lack of information users have to choose secure ones. Source: European Commission Press Release.
In effect, the CRA enforces cybersecurity requirements comparable to safety requirements under the CE marking framework.
CRA Scope: What Products Does the Cyber Resilience Act Apply To?
The CRA applies to any product with digital elements (PDE) that is:
- Software (installable or distributed binaries)
- IoT products (consumer or industrial)
- Connected hardware
- Embedded systems with firmware
- Standalone software delivered on physical media
- Hardware modules containing digital functionality
- Digital components integrated into other products
If a product can connect, directly or indirectly, to a device or a network, and is placed on the EU market in the course of a commercial activity, it is almost always in scope.
Products NOT in scope
Some categories are excluded, based on Article 2:
- Pure SaaS platforms without distributed software components
- Products already covered by sectoral legislation (e.g., medical devices, civil aviation and marine equipment, and vehicles type-approved under Regulation (EU) 2019/2144, including their type-approved components; aftermarket devices sold separately are not excluded)
- Open-source software developed outside a commercial activity
- Products used exclusively for national security or military purposes
For a detailed applicability analysis, see our guide: CRA Applicability: Does the CRA Apply to Your Product?
Is your product Class I, Class II or default?
Classify it in Regulus by its core function, with the exact Annex III or IV reference. The requirements, risk assessment and technical file follow from the answer. Free for manufacturers.
Who Must Comply With the Cyber Resilience Act?
The CRA follows the New Legislative Framework (NLF) and applies to all economic operators involved in placing a digital product on the EU market:
1. Manufacturers
Manufacturers bear the most obligations, including:
- Secure design and development processes
- Conformity assessment and CE marking
- Technical documentation (Annex VII), including the user information of Annex II
- Security updates throughout the support period
- Vulnerability handling and post-market monitoring
- Incident reporting
2. Importers
Importers must verify that products coming from outside the EU comply with CRA requirements before being placed on the market.
3. Distributors
Distributors must verify labelling, documentation completeness, and ensure conformity before making products available.
4. Authorised Representatives
They may carry out tasks delegated by the manufacturer but cannot assume liability for insecure products.
CRA Product Classification: Default, Important and Critical
The CRA introduces four categories:
- Default Class: Most products fall here
- Important Class I and Class II (Annex III): Products whose core function is listed there, requiring stricter assessments
- Critical (Annex IV): Three categories of products that may require European cybersecurity certification
Default Class Products
These include most software applications, embedded products, IoT devices, developer tools, and typical firmware-driven hardware.
Default Class obligations include:
- Secure design and development
- Secure update mechanisms
- Lifecycle risk management
- Conformity based on internal control
- Complete CRA technical documentation
Important and Critical Products
Classification depends on the product’s core function, not on the sector it is sold to. The lists are closed:
- Class I: identity and access management, browsers, password managers, anti-malware, VPN products, network management, SIEM, boot managers, PKI, network interfaces, operating systems, routers, modems and switches, microprocessors and microcontrollers with security functions, home virtual assistants, smart home security products (locks, cameras, baby monitors, alarms), connected toys with social interaction or location features, and certain wearables
- Class II: hypervisors and container runtime systems, firewalls and intrusion detection and prevention systems, and tamper-resistant microprocessors and microcontrollers
- Critical: hardware devices with security boxes, smart meter gateways, and smartcards or similar devices, including secure elements
Important and critical products often require:
- Third-party conformity assessment
- More rigorous documentation
- Enhanced vulnerability and patching procedures
To determine your class, start with our free evaluation tool: CRA Applicability Checker
Essential Security Requirements (Annex I)
Annex I defines the mandatory security controls for all digital products. These include:
1. Secure-by-design and secure-by-default architecture
- Minimisation of attack surface
- Least privilege
- Secure default configurations
2. Protection from known vulnerabilities
- CVE tracking
- SBOM integrity
- Dependency monitoring
3. Secure development practices
- Threat modelling
- Static and dynamic testing
- Code review processes
4. Supply chain security
- Supplier validation
- Dependency integrity checks
5. Vulnerability handling capabilities
- Intake and triage
- Remediation workflows
- Coordinated disclosure
6. Update mechanisms
- Secure patch delivery
- Cryptographically signed updates
- Rollback protections
Technical Documentation Requirements (Annex VII)
Manufacturers must produce and maintain a comprehensive technical file that includes:
- Product description and intended purpose
- Architecture diagrams and component mapping
- Security controls and implementation details
- Vulnerability handling processes
- Update strategy and lifecycle support
- Evidence of conformity assessment
To simplify documentation, download our template: CRA Readiness Checklist (PDF)
Incident Reporting Requirements
Manufacturers must report:
- Actively exploited vulnerabilities (early warning within 24 hours of becoming aware, notification within 72 hours)
- Severe incidents affecting the security of the product (same 24 and 72-hour deadlines)
Since 11 September 2026, reports are submitted through the single reporting platform and reach, at the same time:
- The CSIRT designated as coordinator in the manufacturer’s Member State
- ENISA
External reference: ENISA – Official EU Cyber Agency
CRA Timeline 2024–2027
The rollout includes:
- 10 December 2024: Regulation enters into force
- 11 June 2026: Rules on notifying authorities and notified bodies apply
- 11 September 2026: Reporting obligations for actively exploited vulnerabilities and severe incidents apply
- 11 December 2027: Full mandatory compliance and enforcement
Companies that begin early can reduce cost, risk, and operational friction significantly.
How to Prepare for the Cyber Resilience Act
1. Assess Applicability and Classification
Determine whether your product is default, important (Class I or II) or critical. Start here: CRA Applicability Checker
2. Conduct a Product Inventory
List firmware, software modules, embedded components, connectivity features, and update mechanisms.
3. Establish Secure Development Practices
Build security into each lifecycle phase:
- Threat modelling
- Secure coding standards
- Secure build pipelines
- Static analysis, fuzzing, penetration testing
External benchmark:
NIST Secure Software Development Framework (SSDF)
4. Build CRA Technical Documentation
Create and maintain a living technical file aligned with Annex VII, including the user information required by Annex II.
5. Implement Vulnerability Handling Workflows
Define intake, triage, remediation, and disclosure processes.
6. Prepare for Conformity Assessment
Default → internal control (Module A)
Important Class I → internal control only if harmonised standards are applied in full; otherwise a notified body
Important Class II → notified body (Module B + C or Module H)
Critical → European cybersecurity certification where required; otherwise as Class II
Conclusion
The Cyber Resilience Act introduces a new era of EU cybersecurity regulation. Its impact will be profound: stronger product security, improved patching practices, and more trustworthy digital ecosystems.
To accelerate your readiness, start with our full library of resources: Cyber Resilience Act Resources
Early preparation is the most valuable advantage you can secure.
For a structured, step-by-step view, see our Cyber Resilience Act compliance roadmap for 2025–2027.
