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 enforcement arriving between 2025 and 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 addresses “systemic weaknesses in digital product security due to lack of incentives and lack of harmonisation”. 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 interacts with a network, processes data, receives updates, or operates via firmware or software, 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 cybersecurity legislation (e.g., medical devices, automotive ECUs)
- 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?
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 II & VII)
- 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 vs Critical Class
The CRA introduces two categories:
- Default Class: Most products fall here
- Critical Class: Higher-risk products requiring stricter assessments
Default Class Products
These include general-purpose software, 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
Critical Class Products
Critical Class includes systems where vulnerabilities can affect:
- Industrial operations
- Critical infrastructure
- Access controls
- Security functions
- Core connectivity components
Critical Class often requires:
- 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 II & 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:
- Exploited vulnerabilities (within a fixed timeline)
- Severe cybersecurity incidents
Reports must be submitted to:
- National CSIRTs
- ENISA (when required)
External reference: ENISA – Official EU Cyber Agency
CRA Timeline 2025–2027
The rollout includes:
- 2025: Regulation enters into force
- 2026: Preparation and alignment window
- 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 or Critical Class. 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 II and VII.
5. Implement Vulnerability Handling Workflows
Define intake, triage, remediation, and disclosure processes.
6. Prepare for Conformity Assessment
Default Class → internal control
Critical Class → external notified body in many cases
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.
