What is the EU Cyber Resilience Act?
The EU Cyber Resilience Act (Regulation EU 2024/2847) is a mandatory cybersecurity regulation requiring all products with digital elements sold in the EU to meet baseline security requirements — including secure boot, authenticated OTA updates, vulnerability management, and a Software Bill of Materials (SBOM). Non-compliance carries fines up to €15 million or 2.5% of global turnover. The first reporting obligations begin September 2026, with full enforcement in December 2027. For implementation guidance, see our Embedded Security & IoT services.
Why Hardware Engineers Must Act Now
The CRA is not a future concern — it is an active regulation with a compressed timeline:
| Milestone | Date | What Happens |
|---|---|---|
| CRA enters into force | December 10, 2024 | Clock starts ticking |
| Conformity assessment bodies activated | June 11, 2026 | Third-party auditors begin operations |
| Vulnerability reporting obligation | September 11, 2026 | Manufacturers MUST report exploited vulnerabilities within 24 hours |
| Full enforcement | December 11, 2027 | All products must comply or face market withdrawal |
If you are designing a connected product today, it must be CRA-compliant by the time it ships. Retrofitting security into an existing design is 5–10× more expensive than designing it in from the start.
Who Is Affected?
The CRA covers all products with digital elements — meaning any product that includes software or can connect to a network. This includes:
- IoT devices — sensors, actuators, gateways, smart home products
- Industrial equipment — PLCs, HMIs, SCADA controllers, industrial PCs
- Consumer electronics — routers, cameras, smart speakers, wearables
- Embedded systems — any product with a microcontroller and connectivity
- Software — standalone applications, firmware, operating systems
Who it does NOT cover: SaaS (cloud services), open-source software (under specific conditions), medical devices and vehicles (covered by sector-specific regulations), and products exclusively for national security.
Product Classification: Default, Important, or Critical
The CRA classifies products into risk categories that determine the required conformity assessment:
| Category | Examples | Assessment Method | Third-Party Audit? |
|---|---|---|---|
| Default | Smart light bulbs, basic sensors, simple IoT devices | Self-assessment (internal) | No |
| Important (Class I) | Routers, firewalls, ICS, smart home hubs, identity management software | Harmonized standard OR third-party | Conditional |
| Important (Class II) | Hypervisors, HSMs, smart meters, industrial firewalls, secure elements | Third-party mandatory | Yes |
| Critical | Smart cards, hardware security modules for critical infrastructure | European cybersecurity certification | Yes |
Key insight: Most industrial IoT products fall into the “Important (Class I)” category. If harmonized standards exist for your product type, you can self-assess against them. If not, you need third-party evaluation.
The Complete CRA Compliance Checklist
This checklist covers every technical and procedural requirement that the CRA imposes on hardware manufacturers:
Security by Design
- Threat model completed — STRIDE or equivalent analysis identifying all attack surfaces
- Security requirements defined in the product specification (not retrofitted)
- Secure development lifecycle documented and followed (e.g., IEC 62443-4-1)
- Default settings are secure — no default passwords, unnecessary ports closed, debug interfaces disabled in production
Hardware Root of Trust
- Secure boot chain implemented — immutable first-stage bootloader in ROM/OTP verifying all subsequent stages
- Hardware key storage — cryptographic keys stored in Secure Element or TPM, not in application flash
- Debug port protection — JTAG/SWD disabled in production via option bytes or fuses (RDP Level 2 or equivalent)
- Tamper detection — physical or logical tamper response for Important/Critical class products
For implementation details, see our guide on Hardware Security Design.
Secure Communication
- TLS 1.3 (or equivalent) for all external communications
- Mutual authentication — device authenticates to server AND server authenticates to device
- Certificate management — per-device unique certificates, not shared credentials
- Data minimization — only necessary data transmitted, minimal PII exposure
Vulnerability Management
- Vulnerability handling process documented — intake, triage, remediation, disclosure
- Coordinated vulnerability disclosure policy published and accessible
- Security contact publicly available (security.txt, product documentation)
- Patch delivery SLA defined — maximum time from vulnerability discovery to fix deployment
- End-of-support date declared — minimum 5 years of security updates from market placement
Software Bill of Materials (SBOM)
- SBOM generated in SPDX or CycloneDX format covering all software components
- Third-party components tracked with version numbers and known vulnerability status
- License compliance verified for all included open-source components
- SBOM updated with each firmware release and available to market surveillance authorities on request
OTA Update Infrastructure
- Authenticated updates — all firmware packages cryptographically signed (ECDSA or equivalent)
- Rollback protection — monotonic counter or anti-replay mechanism prevents downgrade to vulnerable versions
- A/B firmware slots — dual-bank update mechanism for atomic, fail-safe updates
- Update verification — integrity check before applying (hash verification of complete image)
- Automatic security updates — capability for critical patches without user interaction (or clear user notification)
For OTA architecture patterns, see our article on Embedded Programming best practices.
Incident Reporting
- Vulnerability reporting system operational — capable of reporting to ENISA within 24 hours of discovering an actively exploited vulnerability
- Incident log maintained — all security incidents documented with timeline, impact assessment, and remediation
- Customer notification process defined — how affected users will be informed of security issues
Documentation & Conformity
- Technical documentation complete — design specifications, security architecture, test results
- EU Declaration of Conformity prepared — declaring compliance with CRA essential requirements
- CE marking applied to product (CRA becomes part of the CE marking framework)
- Conformity assessment completed — self-assessment for Default class, or third-party for Important/Critical
- Post-market surveillance plan — ongoing monitoring, vulnerability scanning, and incident response
Penalty Structure
The CRA introduces significant financial penalties for non-compliance:
| Violation | Maximum Fine |
|---|---|
| Failure to meet essential cybersecurity requirements | €15,000,000 or 2.5% of global annual turnover |
| Failure to meet other CRA obligations (documentation, reporting) | €10,000,000 or 2% of global annual turnover |
| Providing incorrect or misleading information to authorities | €5,000,000 or 1% of global annual turnover |
Additionally, non-compliant products can be recalled from the market or prohibited from sale in the EU — potentially worse than fines for businesses dependent on EU revenue.
CRA vs Other EU Regulations: What Stacks?
The CRA doesn’t exist in isolation. Hardware manufacturers often need to comply with multiple overlapping regulations:
| Regulation | Focus | Overlap with CRA |
|---|---|---|
| RED (Radio Equipment Directive) | Radio equipment cybersecurity | RED Art. 3.3(d/e/f) aligns closely with CRA; products complying with CRA may satisfy RED cybersecurity |
| NIS2 Directive | Critical infrastructure operators | NIS2 may require operators to use CRA-compliant products |
| GDPR | Personal data protection | CRA’s data minimization and secure communication requirements support GDPR compliance |
| AI Act | Artificial intelligence systems | AI-enabled products must comply with BOTH the AI Act and CRA |
| Machinery Regulation | Industrial machinery safety | Connected machinery must meet CRA cybersecurity requirements |
How Hardware Design Decisions Affect CRA Compliance
CRA compliance is not just a software or process problem — it starts with hardware architecture decisions made in the requirements phase:
| Hardware Decision | CRA Impact | Cost of Fixing Later |
|---|---|---|
| No Secure Element included | Cannot implement hardware root of trust | Complete board redesign (€50K–200K) |
| No OTA update mechanism | Cannot deliver security patches | Field recall or end-of-life declaration |
| Single firmware bank | Cannot implement safe rollback | Bootloader redesign + re-certification |
| Debug port always enabled | Fails security assessment | Board revision + new production setup |
| No hardware random number generator | Weak key generation, certification risk | MCU change or external TRNG addition |
The lesson: If your PCB is already in production without these features, CRA compliance will require a hardware revision — not just a firmware update. This is why security must be an architecture decision, not an afterthought.
Frequently Asked Questions
Does the CRA apply to existing products already on the market?
Products placed on the EU market before December 11, 2027 are not retroactively required to comply with CRA essential requirements. However, if you release a substantial modification (significant firmware update, new hardware version) after that date, the modified product must comply. Additionally, vulnerability reporting obligations apply to ALL actively marketed products from September 2026.
How does the CRA affect open-source software?
Open-source software developed and released in a non-commercial context is excluded from CRA. However, if you integrate open-source components into a commercial product, you (the manufacturer) are responsible for ensuring those components meet CRA requirements — including vulnerability monitoring and patching. This makes SBOM management critical.
What is the difference between CRA and CE marking?
CE marking already existed before CRA. The CRA adds cybersecurity as a new essential requirement within the CE marking framework. Starting December 2027, to legally apply CE marking to a connected product, you must demonstrate CRA compliance in addition to other applicable directives (LVD, EMC, RED, etc.).
Can I self-certify for CRA compliance?
For Default category products, yes — you can perform an internal conformity assessment. For Important (Class I) products, you can self-certify only if harmonized standards exist AND your product fully conforms to them. For Important (Class II) and Critical products, third-party assessment by a notified body is mandatory.
How does CRA relate to PSA Certified?
ARM’s PSA Certified framework is not formally recognized by the CRA. However, achieving PSA Certified Level 2 demonstrates compliance with many CRA essential requirements (secure boot, secure update, root of trust). It provides a strong technical foundation and may streamline the CRA conformity assessment process.
Our CRA Compliance Engineering
At Inovasense, we design CRA compliance into products from day one — during the architecture phase, not as a last-minute certification exercise:
- Security architecture review — Threat modeling, attack surface analysis, and security requirement definition
- Secure hardware selection — Selecting the right MCU, Secure Element, and communication module for your security level
- Secure boot + OTA implementation — From immutable bootloader to cloud-managed firmware delivery
- SBOM generation — Automated tooling integrated into our build pipeline
- Conformity assessment support — Documentation packages for self-assessment or third-party evaluation
We are based in the EU and understand the regulatory landscape intimately. Contact us to discuss your CRA compliance strategy.