EU CRA Hardware Compliance Checklist

Vladimír Vician

The Cyber Resilience Act (CRA) sets product-security and vulnerability-handling requirements. It does not prescribe an external TPM, a particular MCU, OTA transport or an A/B bootloader for every device. Select technical controls from the product’s cybersecurity risk assessment and document how they meet the applicable requirements.

Scope and product category

Check Articles 2 and 3 of the CRA: the regulation covers products with digital elements made available on the EU market whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. This includes software or hardware components placed on the market separately and relevant remote data processing solutions. A cloud function can be part of the product where the manufacturer designs it, or is responsible for its development, and its absence would prevent the product from performing one of its functions.

Check the exact exclusions for the product. Examples include specified medical devices, vehicles, certified civil-aviation products and marine equipment. Free and open-source software not supplied in the course of a commercial activity is outside the ordinary product obligations; open-source software stewards have a separate regime. Using such software in commercial hardware does not exempt the hardware manufacturer.

Document the product’s core functionality and category. Annex III distinguishes important Class I and Class II products. Class II includes hypervisors/container runtimes supporting virtualised operating systems, firewalls/IDS/IPS, and tamper-resistant microprocessors and microcontrollers. Annex IV covers critical categories such as smartcards and similar devices, including secure elements. Not every smart meter or security component belongs to Class II. Use the 2025/2392 technical descriptions when matching a category.

Security by design

Define assets, trust boundaries, threats and foreseeable misuse. Map the applicable Annex I requirements to controls and test evidence. Use secure defaults, appropriate access controls, data minimisation and protection of confidentiality and integrity. Record why a control is applicable or not applicable; a checklist tick is not a risk assessment.

Review the full requirement map, including known exploitable vulnerabilities at market release, availability of essential functions, limitation of attack surfaces, incident mitigation, security-related recording and monitoring with the required user opt-out, and secure removal of data and settings. Assess applicability under Annex I Part I and document any justified exclusions. Keep the risk assessment current as required by Article 13.

Hardware root of trust

Secure boot, protected key storage, debug restrictions and tamper measures can support identified risks. They are implementation choices, not a universal legal requirement to install a discrete TPM or irreversibly lock every debug interface. Validate the actual boot chain, manufacturing provisioning and recovery process.

Secure communication

Identify every interface and its trust boundary. Select authentication and cryptographic protection appropriate to the risks. Test certificate validation, credential lifecycle and failure handling. Merely naming a TLS version is insufficient evidence that a product meets the essential requirements.

Vulnerability management

Assign intake, triage, remediation and disclosure owners. Publish a security contact and define supplier escalation. Under Article 13, set the support period with regard to expected use: normally at least five years, but if expected use is shorter, the support period corresponds to that expected use. A long-lived product may require longer support. Communicate the support end date and plan the resources to honour it.

Implement coordinated vulnerability disclosure, effective and regular security tests and reviews, and risk-based remediation without delay. Once a security update is available, publish the required information about the fixed vulnerability, affected products, impact, severity and user action. In duly justified cases, publication can be delayed until users have had the opportunity to apply the patch where disclosure risks outweigh its security benefits. Exercise due diligence over integrated components and handle supplier notifications under Article 13(5) and (6). These duties follow Annex I Part II.

Software bill of materials (SBOM)

Annex I Part II requires an SBOM in a commonly used, machine-readable format covering at least top-level dependencies. A deeper internal inventory is useful for vulnerability triage. Identify versions and update the release inventory; distinguish this requirement from publishing the entire SBOM publicly, which is not a blanket CRA obligation.

Update infrastructure

Provide a secure mechanism appropriate to the product for distributing security updates. Authenticity, integrity, recovery and update usability matter. OTA, A/B slots and anti-rollback may be appropriate controls but are not universal mandated technologies. Test interrupted updates and key rotation with the chosen architecture.

Where applicable, enable automatic security updates by default within an appropriate timeframe, with a clear and easy-to-use opt-out mechanism, update notifications and an option to postpone installation temporarily. Document applicability for the product and its operating environment. Recital 56 explains why automatic updates may not apply to components intended for integration or to certain professional and industrial environments.

Distribute available security updates without delay and free of charge, except where otherwise agreed with a business user for a tailor-made product. Provide advisory messages explaining relevant user action. Supply security updates separately from functionality updates where technically feasible. These conditions are set out in Annex I Part I, point (2)(c), and Part II, points (2), (7) and (8).

Under Article 13(9), keep each security update issued during the support period available for at least ten years after it is issued or for the remainder of the support period, whichever is longer. Availability of an issued update is separate from the obligation to develop fixes during the support period.

Incident reporting

Article 14 reporting has applied since 11 September 2026. It covers actively exploited vulnerabilities and severe incidents impacting product security, not every CVE discovered in a dependency. Submit the early warning without undue delay and within 24 hours of awareness, and the notification without undue delay and within 72 hours of awareness. The 72 hours do not start after the early warning. Submit through the Single Reporting Platform to the coordinating CSIRT and ENISA, subject to the regulation’s dissemination provisions.

Event	Final report deadline
Actively exploited vulnerability	No later than 14 days after a corrective or mitigating measure becomes available
Severe incident impacting product security	Within one month after submission of the incident notification

Inform impacted users, and where appropriate all users, about the vulnerability or incident and necessary corrective or mitigating actions under Article 14(8). See the reporting workflow and the Commission’s reporting guidance for the required contents and operational steps.

Existing products and transition

Under Article 69, products individually placed on the market before 11 December 2027 generally become subject to the main requirements only if substantially modified from that date. A substantial modification affects compliance with Annex I Part I or changes the intended purpose for which the product was assessed; an ordinary repair or update does not automatically qualify.

Newly placed units of an older model are not exempt. Article 14 reporting also applies to in-scope products placed on the market before that date, including where the support period has ended. Distinguish reporting from the obligations to develop security fixes during the applicable support period.

Documentation and conformity

The main CRA requirements apply from 11 December 2027, subject to the transition provisions above. Prepare the risk assessment, technical documentation, tests and vulnerability-handling evidence for the applicable assessment route under Article 32:

Default category: internal control under Module A is available.
Important Class I: check Article 32(2). For the harmonised-standard route, apply all applicable requirements of a relevant standard cited in the Official Journal whose scope covers at least the cybersecurity risks associated with the product’s core functionality. Assess additional functions and document how additional risks are addressed. Relevant common specifications and qualifying European cybersecurity certification schemes at assurance level at least “substantial” are also recognised under the conditions in Article 32(2). Where the conditions for internal control are not met, use Module B+C or Module H.
Important Class II: use Module B+C, Module H or an available and applicable European cybersecurity certification scheme under Article 27(9) at assurance level at least “substantial”.
Critical products: follow Article 32(4). Where an applicable delegated act under Article 8(1) requires European cybersecurity certification, use that route; otherwise the procedures in Article 32(3) apply. Classification under Annex IV does not, by itself, impose mandatory EUCC certification.

Article 32(5) provides a separate option for important products that themselves qualify as free and open-source software, provided their technical documentation is publicly available when they are placed on the market. It does not automatically apply to hardware merely because it contains open-source components. The Commission’s guidance, section 6.2, explains the Class I conditions and treatment of additional functions. Products also falling under another EU act can have specific assessment provisions; check the relevant overlap.

Before placing a product on the market under the applicable CRA requirements, draw up the EU declaration of conformity and affix the CE marking as required. Supply the user information and instructions in Annex II, and accompany the product with the declaration or simplified declaration containing the address of the full declaration. Keep the technical documentation and declaration available to market surveillance authorities for at least ten years after market placement or for the support period, whichever is longer, under Article 13(13).

A component’s PSA/SESIP certificate can support its assessed properties, but conformity of the integrated product remains the manufacturer’s responsibility.

Practical review checklist

Use this checklist to organise evidence. Assess each applicable requirement and document the result; ticking the boxes alone does not establish conformity.

EU compliance support · Discuss your product’s assessment route

Frequently asked questions

Does the CRA require a TPM and OTA in every product?

No. The CRA sets risk-based essential requirements. A TPM, secure boot, OTA or A/B updates may be suitable controls, but the law does not mandate those specific technologies universally.

Is the support period always five years?

Article 13 normally sets at least five years, taking expected use into account. If expected use is shorter, support corresponds to that expected use; longer-lived products may need a longer period.

Must every discovered CVE be reported within 24 hours?

No. Mandatory Article 14 reporting concerns actively exploited vulnerabilities and severe incidents impacting product security. Other vulnerabilities still need handling under the applicable obligations.

Can important Class I products always use self-assessment?

No. Check Article 32(2). For the harmonised-standard route, apply all relevant requirements of a cited standard covering at least the cybersecurity risks of the product’s core functionality, and address additional risks separately. Article 32(5) provides a separate option for qualifying free and open-source software with public technical documentation.

How long must issued security updates remain available?

Each security update issued during the support period must remain available for at least ten years after it is issued or for the remainder of the support period, whichever is longer. This is distinct from the period during which new fixes must be developed.

Primary sources

Technical and regulatory references checked on 6 October 2026. This article is a preparation guide; applicability and evidence depend on the specific product.

Related guides inEU Compliance & CE Marking

Explore all →