Overview of the EU Cyber Resilience Act

What do you need to know about the new rules in Europe

#

Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), sets mandatory cybersecurity rules for products with digital elements on the EU market. That covers typical ESP32 designs: connected appliances, sensors, gateways, wearables, device firmware, companion apps, and cloud services sold as part of the product.

Espressif’s Developer Portal CRA series goes deeper than this lecture. Read Understanding the EU Cyber Resilience Act (CRA) first, then EU Cyber Resilience Act: Vulnerability Reporting Obligations. If your product already falls under the RED Delegated Act, use ESP32 RED DA / EN 18031 Compliance Guide alongside the CRA material.

Learning objectives

#

By the end of this overview, you should be able to:

• Say which products the CRA covers and how that maps to ESP32-based designs
• Recall the September 2026 and December 2027 deadlines and what each triggers
• Tell Annex I Part I (design-time security) from Part II (vulnerability handling)
• Link workshop labs to artifacts you might keep for a gap analysis or CRA technical file

Scope and who is responsible

#

Medical, automotive, aviation, and other sector rules can exempt or overlap with the CRA. Confirm your product category with qualified counsel.

Economic operators (manufacturer, importer, distributor) each have defined duties. The manufacturer is normally whoever places the product on the EU market under their name or trademark. Re-branding does not shift liability: the name on the box owns the obligations. See the FAQ in the vulnerability reporting article.

Key dates

#

The CRA entered into force on 10 December 2024. For ESP32 OEMs, two dates usually drive the plan:

Timeline figures and context: CRA overview, reporting obligations.

The overview FAQ cites a minimum five-year security update period unless you document and communicate a shorter support window to buyers.

Essential cybersecurity requirements

#

Annex I Part I covers design and development. Provisioning, update policy, documentation, and post-market handling count alongside firmware features.

Espressif’s summary of Part I groups the themes as:

• Secure-by-design and secure-by-default development
• Product-level cybersecurity risk assessment
• Protection against unauthorized access and misuse
• Secure update mechanisms
• Data protection and minimization where relevant
• Logging and monitoring where relevant
• Transparency (security documentation and user instructions)

Secure Boot, encryption, and TLS in this workshop address parts of that list. Signed OTA belongs in your product plan; the optional Assignment 5 shows it with app rollback. Anti-rollback is referenced here for CRA mapping but is not a hands-on lab in this course. You still own the product risk assessment and the CRA technical file that ties controls to requirements.

Vulnerability handling and reporting

#

Annex I Part II covers vulnerability management for the declared support period.

Reportable conditions under the CRA (see the overview article):

• Actively exploited vulnerability in the product
• Severe incident with significant impact on the product or its users

When thresholds are met, manufacturers coordinate disclosure, notify users, ship fixes, and report through the ENISA Single Reporting Platform (SRP). Notification timelines appear in the overview article reporting table.

Espressif’s side of the stack is described in Staying Ahead with ESP32 Security Updates: advisories, the ESP-IDF Security Dashboard, esp-idf-sbom, LTS branches, and secure OTA. You still track impact on your firmware, deploy patches, and file CRA reports when your product triggers Article 14.

Conformity assessment (overview)

#

Under the full CRA regime, manufacturers usually:

1. Classify the product (default, Important Class I or II, or critical) using Annex III and IV. Many ESP32 IoT devices land in default or Important Class I depending on function and risk.
2. Run the risk assessment, implement measures, write technical documentation, sign an EU Declaration of Conformity, and apply CE marking. Some classes need a Notified Body.
3. Keep post-market duties: monitor vulnerabilities, ship updates, and report under Article 14 when required.

Class diagrams and step detail: CRA compliance process.

From workshop controls to CRA evidence

#

The labs do not finish conformity assessment. They produce testable artifacts for themes that often appear in gap analysis and technical documentation.

Platform features (secure boot, flash encryption, eFuse keys, ESP-IDF patches, OTA, SBOM tools) are listed in Espressif’s CRA overview and Product Security docs. The reporting FAQ states plainly: no API or SoC is “CRA-compliant” by itself; compliance belongs to the finished product.

Developer Portal reading list

#

EU primary sources: Regulation (EU) 2024/2847, Commission CRA policy, CRA implementation FAQ.

Navigation

#

Previous: Overview of the security features on the ESP32-S31

Next: Lecture 1: TLS for secure communication

Return to the workshop main page