
The Cyber Resilience Act (CRA) is an EU regulation setting mandatory cybersecurity requirements for digital products and connected devices placed on the EU market. Its aim is to close the gap where many products are shipped with little or no built-in security, leaving users exposed to exploitation.
CRA applies across the entire product lifecycle, from development and design to post-market monitoring, maintenance, and updates. It directly targets manufacturers, importers, and distributors, shifting cybersecurity responsibility to those placing digital products on the market. This makes CRA different from regulations like GDPR or NIS2, which focus on data protection and service-level security.
What does CRA stand for?
CRA stands for Cyber Resilience Act, a binding EU regulation adopted in 2024. Its purpose is to ensure that all hardware and software with digital elements come with built-in cybersecurity, and that vendors remain responsible for product security over time. It establishes a harmonized set of rules across the EU, replacing fragmented national approaches.
What does CRA require?
CRA introduces cybersecurity obligations across the full product lifecycle, with a mix of pre-market and post-market controls. Key CRA requirements include:
- Secure-by-design and default: Products must minimize vulnerabilities and be secure out of the box, with strong default configurations.
- Vulnerability handling: Manufacturers must set up clear processes to receive, assess, and fix vulnerabilities, including coordination with security researchers.
- Security updates: Ongoing support is required for the product’s expected lifecycle, including timely delivery of patches.
- Incident reporting: Exploited vulnerabilities and security incidents must be reported to ENISA within 24 hours.
- Technical documentation: Includes a risk assessment, conformity assessment, and a declaration of compliance.
- Post-market monitoring: Vendors must track emerging threats and product behavior after sale and take action as needed.
- CE marking for cybersecurity: Products must carry a CE marking that confirms they meet CRA cybersecurity standards.
- Conformity assessments:
- Class I (standard products): Self-assessment allowed.
- Class II (critical products): Third-party audits are required (e.g. operating systems, password managers, firewalls).
CRA product classification examples
The CRA introduces two product classes based on cybersecurity risk:
- Class I (standard products): Lower criticality. Self-assessment allowed.
- Class II (critical products): Higher risk. Third-party conformity assessment required.
Below are example classifications to help organizations understand where their products may fall:
Tip: Even Class I products still need to meet all baseline CRA requirements, just with a simpler assessment process. Critical Class II products require more rigorous compliance steps.

How CRA improves product security and why it matters
The Cyber Resilience Act improves product security by making cybersecurity a built-in responsibility throughout the product lifecycle. It requires manufacturers to adopt secure-by-design and default practices, manage vulnerabilities systematically, and respond quickly to security incidents. These obligations reduce the chances of insecure products reaching users and help prevent isolated flaws from becoming large-scale exploitation risks.
By shifting accountability to manufacturers, importers, and distributors, CRA ensures that security is no longer optional or deferred—it becomes part of product quality and legal compliance.
Organizations that comply with CRA benefit from:
- Fewer vulnerabilities through structured development and testing practices
- Faster incident response via mandatory vulnerability handling and reporting
- Stronger vendor and supply chain trust, especially in regulated industries
- Regulatory clarity thanks to a unified EU-wide compliance standard
- Market advantage, as secure, CRA-compliant products become more desirable to B2B buyers and public sector customers
Overall, CRA raises the cybersecurity baseline for digital products and creates both legal accountability and competitive opportunity.
Global comparisons
CRA shares goals with other global frameworks but differs in scope and enforcement:
CRA best practices and common challenges
Best practices from early adopters:
- Integrating secure coding into SDLC
- Automating vulnerability scanning and triage
- Building Product Security Incident Response Teams (PSIRTs)
- Creating reusable technical documentation templates
- Using platforms like Cyberday to assign responsibilities and collect evidence
Common challenges:
- Retrofitting older products with no security baseline
- Budgeting for long-term patching and support
- Understanding overlap with CE marking and Radio Equipment Directive
- Managing multiple conformity assessment processes

FAQs
Is CRA mandatory?
Yes. CRA is a binding EU regulation. Once enforcement begins, compliance is mandatory for all applicable products placed on the EU market.
Why is CRA important?
CRA brings legal accountability to product vendors and closes the long-standing gap in cybersecurity regulation for connected devices and software. It helps reduce EU-wide risk from insecure products and ensures vendors build security from the start.
Who needs to comply with CRA?
CRA applies to:
- Manufacturers, importers, and distributors of digital products
- Products with digital elements, including:
- IoT devices
- Mobile and desktop apps
- Embedded systems
- Operating systems
- Industrial control software
Excluded: Products already covered by specific EU sectoral laws (e.g., medical devices, automotive, aviation).
When is CRA in effect?
CRA entered into force on December 10, 2024. Key deadlines:
- September 2025: ENISA receives national implementation plans.
- September 2026: Incident reporting obligations become enforceable.
- December 2027: Full obligations apply. After this, all in-scope products must be CRA-compliant.
Is CRA supported in Cyberday?
Yes. CRA is available to work in Cyberday. The platform includes:
- CRA-specific tasks and controls
- Secure development and update support
- Technical documentation templates
- Vulnerability and incident response workflows
- Continuous updates as guidance evolves