BlackIoT
  • CRA
  • Approach
  • Services
  • Industries
  • References
    • Secure Wireless Platforms
    • WildBay
    • WildBay MKR
    • Vallarta
    • Vallarta MKR
    • BlackMoon
    • BlackMoon MKR
    • Sensor Reference Designs
    • Polverine
    • PortRoyal MKR
    • Havana MKR
    • Martinica MKR
    • Mayreau
  • Aerospace
  • ECSS PCB
  • Contact
Regulation (EU) 2024/2847

The EU Cyber Resilience Act — practical overview

This page summarizes the Cyber Resilience Act as it applies to manufacturers of products with digital elements placed on the EU market. It is not legal advice — refer to the official sources linked below.

Download the CRA overview (PDF, 12 pages) STM32H5 × CRA technical brief (PDF, 15 pages)

What the CRA is

Regulation (EU) 2024/2847 — the Cyber Resilience Act — is the first horizontal EU regulation imposing binding cybersecurity requirements on products with digital elements (PDEs). It applies to hardware and software products sold, distributed, or otherwise placed on the EU market, whether the manufacturer is based inside or outside the EU.

The regulation entered into force on 10 December 2024. Its obligations apply in phases, with full application on 11 December 2027.

Who it applies to

Every economic operator along the chain carries obligations: manufacturers, authorized representatives, importers, and distributors. Exceptions are narrow — products already covered by sector-specific Union law (medical devices, civil aviation, motor vehicles) are carved out only to the extent of equivalent cybersecurity requirements.

Default classification is Annex I self-assessment. Important products (Annex III) and Critical products (Annex IV) require stricter conformity assessment, typically involving a Notified Body.

Annex I — Essential cybersecurity requirements

Section 1 — Product properties

  • Secure-by-design and by-default configuration, with minimum attack surface.
  • Protection from unauthorized access with appropriate control mechanisms.
  • Protection of confidentiality and integrity of stored, transmitted, and processed data.
  • Processing of only minimum personal data necessary for the intended use.
  • Protection of availability of essential functions, including resilience against denial-of-service.
  • Minimization of the negative impact of the product itself or connected devices on other devices or networks.
  • Limitation of attack surfaces, including external interfaces.
  • Reduction of the impact of an incident using appropriate mitigation mechanisms.
  • Provision of security-related information by recording and monitoring relevant internal activity.
  • Secure default configuration; user ability to reset to factory settings; secure removal of user data.
  • Security updates delivered without delay, free of charge, with clear advisory messages.

Section 2 — Vulnerability handling

  • Identify and document vulnerabilities and components in the product, including by producing a machine-readable SBOM covering at least top-level dependencies.
  • Address and remediate vulnerabilities without delay, including by providing security updates.
  • Apply effective and regular tests and reviews of the security of the product.
  • Publicly disclose information about fixed vulnerabilities once updates are available.
  • Put in place and enforce a coordinated vulnerability disclosure policy.
  • Facilitate the sharing of information about potential vulnerabilities.
  • Provide secure update mechanisms, including over-the-air updates where applicable.
  • Distribute security updates without delay and free of charge, with advisory messages.

What is a Software Bill of Materials (SBOM)?

An SBOM is a formal, machine-readable inventory of every software component shipped inside a product — open-source libraries, third-party SDKs, OS layers, firmware blobs, and their versions, licences, and supply-chain relationships. It is to software what a Bill of Materials is to a PCB.

The CRA (Annex I Section 2) makes SBOMs mandatory for products with digital elements: manufacturers must identify and document vulnerabilities and components, including by producing a machine-readable SBOM covering at least the top-level dependencies. The SBOM must be kept current — updated whenever the product software changes — and must be available to authorities on request.

Common SBOM formats

  • SPDX (ISO/IEC 5962:2021) — Linux Foundation standard, broadly adopted across the open-source ecosystem.
  • CycloneDX — OWASP standard, originally designed for application security and supply-chain risk management.
  • SWID Tags (ISO/IEC 19770-2) — software identification tags, often used alongside SPDX/CycloneDX rather than instead of them.

Why the CRA requires an SBOM

  • When a vulnerability is published in a third-party library, an SBOM lets you instantly answer the question "do any of my products ship this version?" — without it, vulnerability handling on the 24 h / 72 h / 14 d cadence is not realistically achievable.
  • An SBOM is a core piece of the technical file presented at conformity assessment and made available to market-surveillance authorities.
  • It enforces supply-chain due diligence (CRA Article 13): if you cannot list a component, you cannot demonstrate that it does not compromise your product's cybersecurity.

Incident and vulnerability reporting

When an actively exploited vulnerability is identified in a product, manufacturers must notify the designated CSIRT and ENISA through a single reporting platform:

  • 24 hours — early warning notification.
  • 72 hours — detailed vulnerability notification including any corrective measures.
  • 14 days after a corrective measure is available — final report.
EU CRA vulnerability reporting cascade showing trigger event, 24-hour early warning, 72-hour detailed notification, and 14-day final report submitted via the ENISA single reporting platform to ENISA and the designated national CSIRT
Fig. 1 — The CRA reporting cascade. One submission via the ENISA single reporting platform, three escalating deadlines (24 h early warning, 72 h detailed notification, 14 d final report), two recipients (ENISA and the designated national CSIRT).

The same cadence applies to severe incidents impacting the security of the product.

Conformity assessment and CE marking

A successful conformity assessment results in an EU Declaration of Conformity and the affixation of the CE marking. The assessment route depends on the product class:

  • Default (most PDEs) — internal control (Module A) self-assessment against Annex I.
  • Annex III — Important products (e.g., password managers, boot managers, firewalls, VPNs, identity management, intrusion detection) — stricter routes, including application of harmonized standards, EU-type examination (Module B), or full quality assurance (Module H).
  • Annex IV — Critical products — European cybersecurity certification scheme may be mandated by implementing act.
CRA conformity assessment decision chart showing three routes by product class. Default products with digital elements not listed in Annex III or IV follow Module A internal control self-assessment. Annex III Important products (password managers, VPNs, firewalls, identity management, intrusion detection, boot managers) take stricter routes: harmonized standards, Module B plus C EU-type examination, or Module H full quality assurance, typically involving a Notified Body. Annex IV Critical products require a European cybersecurity certification scheme mandated by Commission implementing act. All three routes converge on an EU Declaration of Conformity and CE marking.
Fig. 2 — Three conformity-assessment routes under the CRA. Default products self-assess against Annex I (Module A). Annex III Important products take stricter routes involving harmonized standards or a Notified Body (Module B+C, Module H). Annex IV Critical products require a European cybersecurity certification scheme set by Commission implementing act.

Compliance timeline

  1. 10 December 2024 Entry into force

    The Regulation is published in the Official Journal and enters into force.

  2. 11 June 2026 Notification of conformity assessment bodies

    Chapter IV applies — Member States notify designated bodies able to perform CRA conformity assessments.

  3. 11 September 2026 Reporting obligations

    Manufacturers must notify actively exploited vulnerabilities and severe incidents to ENISA through the single reporting platform on the 24 h / 72 h / 14 d cadence.

  4. 11 December 2027 Full application

    All remaining obligations apply — Annex I product properties, vulnerability handling, SBOM, conformity assessment, Declaration of Conformity, CE marking.

Penalties

Non-compliance with essential cybersecurity requirements or vulnerability-handling obligations can trigger administrative fines of up to €15 million or 2.5% of total worldwide annual turnover of the preceding financial year, whichever is higher. Lesser infractions (incorrect information to authorities, missing documentation) are subject to lower caps.

Official EU sources

  • European Commission — Cyber Resilience Act policy hub Policy page with background, FAQs, and implementing-act tracking.
  • Commission — summary of the legislative text Structured overview of the regulation, article by article.
  • EUR-Lex — Regulation (EU) 2024/2847 Full, authoritative text of the Regulation as published in the Official Journal.
  • ENISA — EU Agency for Cybersecurity Home of the single reporting platform and implementation guidance.

Redesign ahead of the deadline

Products on the EU market from 11 December 2027 must meet the full CRA. Beginning a redesign in late 2026 is, for most manufacturers, already tight — SBOM tooling, secure-update infrastructure, and Notified Body engagement all have real lead times. Starting now is how you land on 11 December 2027 without a scramble.

Talk to our engineering team
BlackIoT — Break The Edge
CRA Aerospace ECSS PCB Cookies Terms Accessibility Vulnerability Disclosure Privacy Policy Legal Notice

© 2026 BlackIoT Sagl — CHE-192.005.916 · Vacallo, Switzerland