EU CRA Hardware Compliance Checklist

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 have to satisfy several overlapping regulations:

Regulation	Focus	Overlap with the CRA
RED (Radio Equipment Directive)	Cybersecurity of radio equipment	RED Art. 3.3(d/e/f) aligns closely with the CRA; products that meet the CRA can satisfy RED’s cybersecurity requirements
NIS2 Directive	Operators of critical infrastructure	NIS2 may require operators to use CRA-compliant products
GDPR	Personal data protection	The CRA’s data-minimization and secure-communication requirements reinforce GDPR compliance
AI Act	Artificial intelligence systems	AI-enabled products must comply with BOTH the AI Act and the CRA
Machinery Regulation	Industrial machinery safety	Connected machinery must meet the CRA’s cybersecurity requirements

How Hardware Decisions Affect CRA Compliance

CRA compliance isn’t just a software or process problem — it starts with the hardware architecture decisions made at the requirements stage:

Hardware decision	Impact on the CRA	Cost to fix later
No Secure Element included	Cannot implement a Hardware Root of Trust	Full board redesign (€50,000–200,000)
No OTA update mechanism	Cannot deliver security patches	Field recall or end-of-life declaration
Single firmware bank	Cannot implement secure rollback	Bootloader redesign + recertification
Debug port always enabled	Fails the 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 board is already in production without these features, CRA compliance will require a hardware revision — not just a firmware update. That’s 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 11 December 2027 have no retroactive obligation to meet the CRA’s essential requirements. However, if you release a substantial modification (a significant firmware update or a new hardware revision) after that date, the modified product must comply. In addition, vulnerability-reporting obligations apply to all actively sold products from September 2026.

How does the CRA affect open-source software?

Open-source software developed and released in a non-commercial context is exempt from the CRA. However, if you integrate open-source components into a commercial product, you (the manufacturer) are responsible for ensuring those components meet the CRA’s requirements — including vulnerability monitoring and patching. This is why SBOM management is critical.

What is the difference between the CRA and CE marking?

CE marking existed before the CRA. The CRA adds cybersecurity as a new essential requirement under CE marking. From December 2027, to legally apply CE marking to a connected product you must demonstrate CRA compliance on top of the other applicable directives (LVD, EMC, RED, etc.).

Can I self-certify for the CRA?

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 the CRA relate to PSA Certified?

The ARM PSA Certified framework is not formally recognized by the CRA. However, achieving PSA Certified Level 2 demonstrates compliance with many of the CRA’s essential requirements (secure boot, secure update, Hardware Root of Trust). It provides a strong technical foundation and can 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:

1. Security architecture review — Threat modeling, attack-surface analysis, and security-requirements definition.
2. Secure hardware selection — Choosing the right MCU, Secure Element, and communication module for your security level.
3. Secure boot + OTA implementation — From an immutable bootloader to cloud-managed firmware delivery.
4. SBOM generation — Automated tooling integrated into our build pipeline.
5. Conformity-assessment support — Documentation packages for self-assessment or third-party assessment.

We are based in the European Union and know the regulatory landscape intimately. Contact us to discuss your CRA compliance strategy.

Sources & Official References

• Cyber Resilience Act — Regulation (EU) 2024/2847 — EUR-Lex (Official Journal of the EU)
• NIS2 Directive — Directive (EU) 2022/2555 — EUR-Lex (Official Journal of the EU)
• Radio Equipment Directive — 2014/53/EU — EUR-Lex (Official Journal of the EU)
• EU AI Act — Regulation (EU) 2024/1689 — EUR-Lex (Official Journal of the EU)
• GDPR — Regulation (EU) 2016/679 — EUR-Lex (Official Journal of the EU)
• Machinery Regulation — Regulation (EU) 2023/1230 — EUR-Lex (Official Journal of the EU)