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 Article 2 of the CRA: the regulation covers products with digital elements whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Sector-specific exclusions include products covered by specified medical-device, vehicle and aviation legislation. Non-commercial free and open-source software is treated differently; open-source stewards have separate obligations.
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.
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.
Software bill of materials (SBOM)
Annex I Part II requires a machine-readable SBOM 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.
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. Both the 24-hour early warning and 72-hour notification run from awareness. Submit through the Single Reporting Platform to the coordinating CSIRT and ENISA, subject to the regulation’s dissemination provisions. See the reporting workflow for final-report deadlines.
Documentation and conformity
The main CRA requirements apply from 11 December 2027. Prepare the risk assessment, technical documentation, tests, vulnerability-handling evidence and EU declaration of conformity for the applicable assessment route. Internal control is available for the default category. Class I self-assessment is conditional on the relevant harmonised standards, common specifications or qualifying certification covering the applicable requirements; otherwise third-party assessment is required. Class II requires the specified third-party routes. Critical products follow Article 32 and any applicable Article 8 certification implementing act; Annex IV alone does not make EUCC mandatory today.
A component’s PSA/SESIP certificate can support its assessed properties, but conformity of the integrated product remains the manufacturer’s responsibility.
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. Internal control depends on the qualifying standards, specifications or certification covering the applicable requirements. Otherwise the prescribed third-party assessment route is needed.
Primary sources
Technical and regulatory references checked on 1 October 2026.
Related guides inEU Compliance & CE Marking
Explore all →EU Electronics Compliance: CE, CRA & RED
A product-specific CE roadmap for electronics: applicable legislation, evidence, assessment routes, RED cybersecurity and CRA responsibilities.
CRA Vulnerability Reporting: Step-by-Step Guide
CRA Article 14 reporting in force since 11 September 2026: scope, 24/72-hour awareness deadlines, final reports, SRP and operational preparation.
EN 18031 Compliance: What "Self-Assessment" Actually Means for Connected Hardware
What EN 18031 self-assessment actually requires under Module A — and where the documented compliance gaps most often appear for connected hardware.
RED Delegated Act & EN 18031: Hardware Requirements
How the RED Delegated Act and EN 18031 define mandatory cybersecurity for radio equipment from August 2025 — with gaps that cannot be fixed in firmware.
EU Hardware Legislation 2026: Complete Guide
Which EU rules apply to your hardware? Distinguish CRA, RED, AI Act, ESPR and NIS2 scope, application dates and product-specific obligations.