EU CRA Hardware Compliance Checklist

Q: When does the EU Cyber Resilience Act take full effect?

The CRA entered into force on 10 December 2024. Conformity assessment bodies become operational on 11 June 2026. Vulnerability reporting obligations under Article 14 begin on 11 September 2026 — manufacturers must report exploited vulnerabilities to ENISA within 24 hours. Full enforcement starts on 11 December 2027, after which all products with digital elements sold in the EU must comply with essential cybersecurity requirements or face market withdrawal.

Q: What are the maximum fines under the EU Cyber Resilience Act?

The CRA imposes three tiers of penalties: up to €15,000,000 or 2.5% of global annual turnover for failure to meet essential cybersecurity requirements; up to €10,000,000 or 2% of turnover for failure to meet other CRA obligations like documentation or reporting; and up to €5,000,000 or 1% of turnover for providing incorrect or misleading information to authorities. Non-compliant products can also be recalled from the EU market or prohibited from sale — potentially more damaging than fines for EU-dependent businesses.

Q: Does the CRA apply to existing products already on the market?

Products placed on the EU market before 11 December 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. Vulnerability reporting obligations apply to ALL actively marketed products from 11 September 2026, regardless of when they were first placed on the market.

Q: 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 Software Bill of Materials (SBOM) management critical for CRA compliance, since you must track every third-party component and its known vulnerability status.

Q: What is the difference between CRA and CE marking?

CE marking existed before CRA. The CRA adds cybersecurity as a new essential requirement within the existing CE marking framework. Starting 11 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, Machinery Regulation, etc.). CE marking and CRA are not separate processes — CRA is integrated into the CE conformity assessment.

Q: Can I self-certify for CRA compliance?

For Default category products (basic IoT sensors, smart light bulbs), yes — you can perform an internal conformity assessment. For Important Class I products (routers, firewalls, smart home hubs, identity management software), you can self-certify only if harmonized standards exist AND your product fully conforms to them. For Important Class II (hypervisors, HSMs, smart meters, industrial firewalls, secure elements) and Critical products, third-party assessment by a notified body is mandatory.

Q: How does CRA relate to PSA Certified?

ARM's PSA Certified framework is not formally recognized as proof of CRA compliance. However, achieving PSA Certified Level 2 demonstrates conformity with many CRA essential requirements (secure boot, secure update, root of trust). It provides a strong technical foundation and can streamline the CRA conformity assessment process, but does not replace the need for a CE Declaration of Conformity covering CRA requirements.

Q: Does the CRA require a minimum support period for security updates?

Yes. CRA requires manufacturers to provide security updates for at least 5 years from the date a product is placed on the EU market, or for the expected lifetime of the product if longer. Manufacturers must declare the end-of-support date and have a documented vulnerability handling process with a defined patch delivery SLA. Not committing to 5 years of updates is itself a CRA violation, regardless of whether vulnerabilities are reported.

Q: What products are classified as Critical under the CRA?

Critical class covers smart cards and hardware security modules used in critical infrastructure — the highest-risk category. These products require European cybersecurity certification under the Cybersecurity Act EUCC scheme rather than self-assessment or standard third-party evaluation. Important Class II products like hypervisors, HSMs, smart meters, industrial firewalls, and secure elements require mandatory third-party assessment by a notified body.

Inovasense

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 m