Glossary · EU Cybersecurity Cyber Resilience Act (CRA)
The 2024 EU regulation establishing cybersecurity requirements for products with digital elements throughout their lifecycle, with full applicability by 2027.
## What the Cyber Resilience Act actually does
The Cyber Resilience Act (Regulation (EU) 2024/2847) is the EU's regulation establishing cybersecurity requirements for **products with digital elements**. Adopted in October 2024, with full applicability from December 2027, it imposes obligations on manufacturers throughout product lifecycles.
Where NIS2 addresses cybersecurity for organizations operating critical services, the CRA addresses cybersecurity of products themselves — software, hardware, IoT devices, and any product containing digital components.
## What "products with digital elements" means
The CRA covers an extremely broad scope. "Products with digital elements" includes:
- **Software products** — operating systems, applications, software libraries
- **Hardware with embedded software** — IoT devices, routers, smart appliances
- **Connected products** — anything with network connectivity
- **Components and integrated software** — both standalone and integrated digital elements
The scope is deliberately broad. The Commission's reasoning: cybersecurity failures in any connected product can affect broader ecosystem security.
Some narrow exclusions apply: products covered by sector-specific cybersecurity regulations (medical devices under MDR, automotive under specific frameworks) have alternative compliance paths. Open-source software developed in non-commercial context has lighter obligations.
## Core obligations
The CRA imposes obligations across product lifecycle:
### Pre-market obligations
Before placing products on the EU market:
- **Risk assessment** — identify cybersecurity risks throughout product lifecycle
- **Security by design** — implement appropriate technical and organizational security measures
- **Vulnerability handling** — establish processes for vulnerability identification and remediation
- **Conformity assessment** — verify product meets CRA requirements (may require third-party assessment for higher-risk products)
- **Documentation** — comprehensive technical documentation including security architecture
- **CE marking** — products must bear CE marking indicating conformity
### Post-market obligations
After products are sold:
- **Security updates** — provide updates for the support period (default 5 years, longer for some categories)
- **Vulnerability reporting** — report actively exploited vulnerabilities to ENISA within 24 hours
- **Incident reporting** — report severe security incidents to authorities
- **Coordinated vulnerability disclosure** — engage with security researchers
- **Operator and user information** — clear security information for users
### Ongoing obligations
Throughout product lifecycle:
- **Secure-by-default configuration** — minimum security baseline
- **Authentication mechanisms** — strong authentication required where applicable
- **Encryption support** — for products handling sensitive data
- **Access controls** — appropriate authorization mechanisms
- **Logging and monitoring** — security-relevant event logging
## Risk-based product classification
The CRA classifies products into categories with different conformity assessment requirements:
### Default category
Most products fall into the default category requiring self-assessment of conformity. Manufacturers complete the assessment and apply CE marking.
### Important category (Class I and Class II)
Products with higher cybersecurity stakes face stricter requirements:
**Class I** — products including identity management systems, password managers, antivirus software, network security tools, generic hypervisors and VPN solutions. Self-assessment with optional third-party verification.
**Class II** — operating systems for servers and workstations, smart cards and certified boot loaders, key management systems for critical infrastructure. Mandatory third-party conformity assessment.
### Critical category
Products with the highest cybersecurity stakes require the most stringent assessment, including for products supporting critical infrastructure and key sovereignty applications.
## Penalty structure
CRA penalties are substantial:
- **Up to €15 million or 2.5% of global annual turnover** (whichever is higher) for non-compliance with key requirements
- **Up to €10 million or 2% of turnover** for non-compliance with other obligations
- **Up to €5 million or 1% of turnover** for supplying incorrect or misleading information
For SMEs, fines are capped at proportionally lower thresholds.
## Why the CRA matters for European tech
The CRA creates significant implications:
### Software products are now regulated products
Historically, software has been less rigorously regulated than physical products with digital elements. The CRA changes this — software products face baseline cybersecurity requirements similar to hardware.
For European software companies, this creates compliance overhead but also competitive opportunity. EU-native software companies that build CRA compliance into product architecture from start have advantages over retrofit-compliance.
### Open-source treatment
The CRA includes provisions reducing burden on open-source software developed in non-commercial context. Commercial open-source distributions and software companies using open-source components face full obligations.
This has been controversial. Open-source community advocates argued for lighter treatment; security advocates argued for full coverage. Final framework requires manufacturers using open-source components to ensure those components meet CRA requirements as integrated.
### IoT product market reshaping
Connected products markets face substantial CRA compliance overhead. Cheap IoT devices from manufacturers that can't or won't comply will exit EU market. This:
- Increases prices for connected products
- Reduces variety at low end of market
- Creates competitive opportunity for EU-based manufacturers building CRA-compliant products
### Software supply chain implications
Manufacturers using third-party software components must ensure those components meet CRA requirements. This creates supply chain pressure:
- Software suppliers face compliance obligations to their manufacturer customers
- Open-source components used in commercial products face stricter scrutiny
- Software bills of materials (SBOMs) become more important
## Timeline and current status
CRA implementation phased:
- **December 2024**: Regulation enters force
- **September 2026**: Vulnerability reporting obligations apply
- **December 2027**: Full applicability for all obligations
We're currently in transition phase. Manufacturers are preparing for September 2026 vulnerability reporting and December 2027 full compliance.
## Relationship to other EU regulations
The CRA fits into broader EU cybersecurity and digital regulation:
**vs. NIS2** — NIS2 addresses organizations operating critical services. CRA addresses products. Together they cover both organizational and product cybersecurity.
**vs. Data Act** — Data Act addresses data access and portability. CRA addresses cybersecurity of products generating that data. Complementary frameworks.
**vs. AI Act** — AI Act addresses AI system risks (safety, fairness, fundamental rights). CRA addresses cybersecurity of products including AI systems. Both apply to AI products.
**vs. GDPR** — GDPR addresses personal data protection. CRA addresses product cybersecurity broadly. Complementary in personal data context.
For products covered by multiple regulations, compliance requires explicit mapping.
## What 2026-2027 brings
- **September 2026 vulnerability reporting deadline** — first major operational milestone
- **December 2027 full applicability** — comprehensive enforcement begins
- **First major enforcement actions** likely 2027-2028
- **Implementing acts and harmonized standards** continuing development
- **Industry-specific guidance** for various product categories
The CRA is the EU's most ambitious cybersecurity regulation by scope. Implementation will substantially shape European software and hardware markets through 2028 and beyond.
## What this means for European businesses
For European software and hardware businesses:
### 1. CRA compliance is a competitive feature
EU-built products with strong CRA compliance posture position favorably against cheaper non-compliant alternatives. Document the compliance work.
### 2. Open-source usage requires care
Use of open-source components in commercial products requires ensuring those components meet CRA requirements. Audit your software supply chain.
### 3. Security-by-design as default
Building products without CRA-aligned security architecture creates technical debt that will need to be paid before December 2027. New product development should incorporate CRA requirements from start.
### 4. SBOM and vulnerability management are operational requirements
Software bills of materials, vulnerability handling processes, and coordinated disclosure programs are no longer optional for products in EU market.
### 5. Update support periods matter
Products must be supported with security updates for default 5-year periods. This affects product lifecycle economics — particularly for IoT manufacturers selling cheap devices with short historical support periods.
For European tech buyers, the CRA creates structural quality improvements in products available in EU markets. Cheap-but-insecure connected products will become less available; properly-engineered alternatives will become more competitive.
Was this helpful?
Thanks for your feedback!