Cyber Resilience Act (CRA): What It Requires, Who It Affects, and How to Prepare

The Cyber Resilience Act (CRA) is the EU's regulation establishing mandatory cybersecurity requirements for products with digital elements. Adopted in 2024, with a phased implementation through December 2027, the CRA fills a critical gap in EU cybersecurity legislation by addressing the security of products before they reach the market.

For B2B software companies, the CRA represents a fundamental shift: cybersecurity is no longer a voluntary feature but a legal prerequisite for market access in the EU. Products must be designed with security in mind, vulnerabilities must be actively managed, and manufacturers must provide security updates throughout the product lifecycle.

This guide covers what the CRA requires, who it applies to, essential compliance obligations, and how software vendors can prepare.

---

CRA Scope and Applicability

What Are Products with Digital Elements

The CRA covers any software or hardware product and its remote data processing solutions placed on the EU market:

Category	Examples
Standalone software	Desktop applications, mobile apps, SaaS platforms
Operating systems	Desktop OS, mobile OS, embedded OS
IoT devices	Smart home devices, wearables, connected appliances
Network equipment	Routers, switches, firewalls, access points
Industrial systems	PLCs, SCADA systems, industrial IoT
Components	Software libraries, SDKs, firmware, microcontrollers

Product Classification

The CRA categorises products by risk level, determining the required conformity assessment:

Category	Assessment	Examples
Default	Self-assessment (if harmonised standards apply)	General-purpose software, smart speakers, games
Important Class I	Self-assessment with harmonised standards, or third-party	Identity management, password managers, VPNs, SIEM, network management
Important Class II	Mandatory third-party (notified body)	Operating systems, hypervisors, firewalls, microcontrollers, smartcards, industrial automation
Critical	Mandatory third-party (EU certification)	Hardware security modules, smart meter gateways, smartcards for qualified electronic signatures

Who Must Comply

Role	Obligations
Manufacturers	Design secure products, conduct conformity assessment, provide updates, report vulnerabilities, maintain technical documentation, CE marking
Importers	Verify manufacturer compliance, ensure CE marking, keep declarations available, report non-compliant products
Distributors	Verify CE marking, ensure compliance documentation, report non-compliant products
Open-source (non-commercial)	Exempt from most obligations; open-source stewards have lighter transparency requirements

---

Essential Cybersecurity Requirements

Product Security Requirements (Annex I, Part I)

Products with digital elements must meet these essential requirements:

Design and Development

• Designed, developed, and produced to ensure an appropriate level of cybersecurity based on risk assessment
• Delivered without known exploitable vulnerabilities
• Secure by default configuration, including the ability to reset to the original secure state
• Protection against unauthorised access with appropriate authentication and identity management

Data Protection

• Protect the confidentiality of stored, transmitted, and processed data (encryption at rest and in transit)
• Protect the integrity of data, commands, and configuration against manipulation
• Process only data adequate, relevant, and limited to the intended purpose (data minimisation)

Resilience and Availability

• Designed to ensure availability, including resilience against denial-of-service attacks
• Minimise negative impact on the availability of services provided by other devices or networks
• Reduce attack surfaces, including external interfaces
• Designed to limit the impact of an incident using appropriate exploitation mitigation mechanisms

Monitoring and Logging

• Provide security-relevant event logging and monitoring capabilities
• Ability to detect and report on security events
• Mechanisms for secure update distribution

Vulnerability Handling Requirements (Annex I, Part II)

Manufacturers must establish and maintain:

Requirement	Description
Vulnerability identification	Identify and document vulnerabilities, including through regular testing and third-party reports
Component documentation	Maintain a Software Bill of Materials (SBOM) identifying components and dependencies
Security updates	Apply effective and regular updates, provided free of charge for the support period
Vulnerability disclosure	Implement a coordinated vulnerability disclosure policy
Information sharing	Share information about fixed vulnerabilities in a timely manner
Update distribution	Provide secure mechanisms for distributing updates
Security advisories	Disseminate advisories about vulnerabilities and available fixes

---

Incident and Vulnerability Reporting

Reporting to ENISA

Manufacturers must report to ENISA (via a single reporting platform):

Event	Initial Notification	Full Notification	Final Report
Actively exploited vulnerability	24 hours	72 hours	14 days
Severe incident impacting security	24 hours	72 hours	14 days

ENISA forwards notifications to relevant national CSIRTs (Computer Security Incident Response Teams) and market surveillance authorities.

User Notification

Manufacturers must also:

• Inform users about incidents and actively exploited vulnerabilities
• Provide guidance on potential risk mitigation measures
• Where possible, provide corrective measures (patches, workarounds)

Reporting Timeline

The reporting obligation applies throughout the product's expected lifetime or for a minimum of five years from placing the product on the market, whichever is shorter.

---

Conformity Assessment and CE Marking

Assessment Procedures

Procedure	Applicable To	Process
Internal control (self-assessment)	Default products; Class I with harmonised standards	Manufacturer assesses against requirements, creates technical documentation, issues EU declaration of conformity
EU-type examination	Class I without harmonised standards; Class II; critical products	Notified body examines technical design and a sample of the product
Full quality assurance	Alternative for Class I/II	Notified body approves and monitors the manufacturer's quality assurance system
EU certification	Critical products where specified	Certification under an EU cybersecurity certification scheme

Technical Documentation

Manufacturers must prepare and maintain technical documentation including:

• General product description and intended purpose
• Design and development details relevant to cybersecurity
• Risk assessment and how essential requirements are met
• List of harmonised standards applied (or other solutions)
• Test reports from cybersecurity assessments
• Software Bill of Materials (SBOM)
• EU declaration of conformity
• Information on security updates and support period

CE Marking

Products meeting all applicable requirements receive CE marking, which:

• Indicates conformity with essential cybersecurity requirements
• Is required for placing the product on the EU market
• Must be affixed visibly, legibly, and indelibly
• For software-only products, can be included in documentation or the digital interface

---

CRA Implementation Timeline

Date	Milestone
2024	CRA adopted and enters into force
September 2026	Reporting obligations for manufacturers apply (vulnerability and incident reporting to ENISA)
December 2027	All CRA requirements fully applicable, including conformity assessment and CE marking

---

CRA and Other Frameworks

CRA and NIS2

Aspect	CRA	NIS2
Focus	Product security (pre-market)	Organisational cybersecurity (operational)
Scope	Products with digital elements	Essential and important entities
Nature	Regulation (directly applicable)	Directive (requires transposition)
Assessment	Conformity assessment before market placement	Risk management and incident reporting during operation
Reporting	Actively exploited vulnerabilities to ENISA	Significant incidents to competent authorities
Relationship	Complementary — CRA secures the product, NIS2 secures the organisation using it

CRA and ISO 27001

Aspect	ISO 27001	CRA Additions
Focus	Organisational ISMS	Product-level security
Vulnerability management	A.8.8 management of technical vulnerabilities	Mandatory SBOM, coordinated disclosure, free patches
Incident reporting	Internal procedures	24/72-hour reporting to ENISA
Secure development	A.8.25-A.8.31 application security	Mandatory secure-by-default design
Supply chain	A.5.19-A.5.23 supplier security	Component documentation and SBOM requirements

---

Preparing for CRA Compliance

For Software Manufacturers

1. Classify your product — Determine whether your product is default, Important Class I/II, or critical
2. Gap analysis — Map current security practices against CRA essential requirements (Annex I)
3. Secure development lifecycle — Implement or strengthen SDL practices, including threat modelling and security testing
4. Vulnerability management — Establish coordinated vulnerability disclosure, patch management, and security advisory processes
5. SBOM creation — Generate and maintain a Software Bill of Materials for all products
6. Technical documentation — Prepare documentation demonstrating conformity with essential requirements
7. Reporting readiness — Build capacity for 24-hour vulnerability and incident reporting to ENISA
8. Support period planning — Define and communicate the security support period for each product

For B2B SaaS Companies

1. Determine applicability — Assess whether your SaaS qualifies as a product with digital elements or remote data processing
2. Review customer contracts — Prepare for CRA-aligned contractual requirements from enterprise buyers
3. Strengthen vulnerability handling — Implement SBOM generation, vulnerability scanning, and coordinated disclosure
4. Publish on Trust Center — Make security documentation, vulnerability handling processes, and compliance evidence available to buyers
5. Plan conformity assessment — Determine the appropriate assessment route and prepare accordingly
6. Monitor harmonised standards — Track the development of harmonised standards that will enable self-assessment for Class I products

---

How Orbiq Supports CRA Compliance

• Trust Center: Publish your CRA compliance posture — secure development practices, vulnerability handling processes, SBOM availability, and security update policies for buyer self-service
• Continuous Monitoring: Track CRA essential requirements across your product security controls with real-time compliance status
• Evidence Management: Centralize technical documentation, security testing reports, and vulnerability records mapped to CRA Annex I requirements
• AI-Powered Questionnaires: Auto-respond to CRA-related security questionnaire questions from enterprise customers

---

Further Reading

• NIS2 Compliance — Understanding the relationship between CRA product security and NIS2 organisational security
• DORA Compliance — CRA implications for ICT providers serving the financial sector
• Penetration Testing — Meeting CRA security testing requirements
• Incident Response — Building reporting capabilities for CRA vulnerability and incident notifications

---

This guide is maintained by the Orbiq team. Last updated: March 2026.