EU Cyber Resilience Act Article 14 — 24-Hour Vulnerability Reporting Hits RISC-V IoT

On September 11, 2026, Article 14 of the EU Cyber Resilience Act (CRA, Regulation EU 2024/2847) became applicable. From this date forward, every manufacturer placing a “product with digital elements” on the EU market — regardless of where the company is headquartered — must report actively exploited vulnerabilities and severe security incidents on a strict regulatory clock. For the RISC-V MCU, SoC, embedded-firmware and IoT industry, this is the first “hard” compliance horizon that touches almost every SKU shipped into Europe.

The reporting clock starts the moment a manufacturer becomes aware that exploitation is happening, not when a vulnerability is publicly disclosed. That distinction matters in practice: it forces vendors to maintain live product inventories, signed-update infrastructure, and a pre-built relationship with ENISA’s Single Reporting Platform before anything goes wrong.

The 24 / 72 / 14-Day Reporting Clock

CRA Article 14 sets three deadlines that every in-scope vendor must hit:

The 24-hour early warning is deliberately thin — a notice that exploitation exists, the member states where the product is available, and any preliminary mitigation. The full technical root-cause analysis is due at 72 hours; the final report tracks the patch lifecycle. The aim, as Netscout’s Darren Anstee put it, is to “create urgency while ensuring prompt, high-quality information sharing.”

Scope: Why Every RISC-V Vendor Is In

The CRA defines a “product with digital elements” (PDE) as any hardware or software whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. That horizontal scope pulls in almost every RISC-V SKU:

• RISC-V MCUs (WCH CH32V series, GigaDevice GD32VW5xx, SiFive E series, Nuclei N/U lines) — if the firmware is networked or updatable, it’s in.
• Embedded single-board computers (StarFive VisionFive, Sipeed LicheePi, Pine64 Star64, Milk-V Jupiter on SpacemiT K1) — all have shipped EU-available SKUs with built-in WiFi/BT or Ethernet.
• Industrial controllers / IIoT gateways using RISC-V SoCs (SiFive P550/P870, SpacemiT K3-based modules).
• Edge AI inference appliances (Ruixin High-Beam D35, Sophgo SG2042 / SG2380 dev boards, ESP32-P4 family for vision/audio).
• Firmware and downloadable software components — toolchains, SDKs, container images.

The scope is location-independent. A Shenzhen-based vendor selling CH32V-based industrial sensors to a Hamburg customer is in scope. The coordinating CSIRT is determined under separate rules for non-EU manufacturers (typically the CSIRT of the member state with the largest install base).

Penalty Tier: €15M or 2.5% of Global Turnover

Failing to meet the core reporting duties triggers the CRA’s top penalty tier — the same ceiling reserved for the most serious breaches:

Note the “or whichever is higher” clause — for a vendor doing €1B of global turnover, 2.5% is €25M, far above the €15M floor. The CRA is structurally aimed at the same gravity as GDPR (which tops out at 4%) for product security.

The December 11, 2027 Horizon: SBOM, Security-by-Design, CE Mark

Article 14 is the first of three enforcement dates. Most of the CRA’s substantive obligations — secure-by-default configuration, SBOMs, security update commitments, and CE marking — become fully applicable on December 11, 2027, roughly 14 months from now:

The reporting obligation is expressly carved out of the December 2027 limitation — a product shipped years ago and never touched still needs a working 24-hour reporting capability today.

Annex I Requirements: What the SBOM and Security-by-Design Phases Will Demand

The CRA splits product security duties into two parts of Annex I:

• Part I — Product Security Requirements: secure-by-default configuration, access control / integrity protection, minimal attack surface, secure update mechanisms (no default passwords, signed OTA, attack-surface minimization).
• Part II — Vulnerability Handling: coordinated vulnerability disclosure (CVD) policy, regular security testing, free security updates throughout the support period (minimum 5 years from placement on market), and a maintained Software Bill of Materials (SBOM) in machine-readable format (CycloneDX or SPDX).

For a RISC-V SoC vendor, “product with digital elements” includes the SDK, the BSP, the toolchain wrapper, and even the Docker images of build environments — each potentially needing its own SBOM under the CVD rules.

Engineering Checklist: Five Steps Before December 2027

For RISC-V vendors shipping into the EU, here is the working order:

1. Stand up a security.txt + VDP today. Publish a coordinated vulnerability disclosure policy at /.well-known/security.txt with a security@ contact, response-time SLA, and safe-harbor clause. Without this, the CVD part of Annex I fails on day one.
2. Generate and maintain machine-readable SBOMs. Adopt CycloneDX for firmware/SDK SBOMs and SPDX for OS/distro SBOMs. Capture top-level dependencies, suppliers, and versions; update on every release.
3. Build the Annex VII technical file. Document product description, intended use, design and development documentation, cybersecurity risk assessment, test reports, instructions for secure use, and vulnerability handling procedures.
4. Run the conformity assessment. For Standard-class products, Module A self-assessment is sufficient. For Class I (identity management, VPNs) and Class II (hypervisors, firewalls), a Notified Body engagement is required — start Notified Body discussions 6–9 months before CE marking.
5. Implement signed-update infrastructure. No default passwords, attestation/measured-boot where applicable, secure OTA distribution. This is the single biggest engineering investment for hardware vendors.

Who Determines Awareness — And Why This Catches Vendors Out

The trigger event is “manufacturer becomes aware,” which requires two capabilities the regulation does not require anyone to have: knowing whether the product is affected and knowing whether exploitation is occurring. The first needs dependency records per product version; the second needs threat intelligence or field observation. Without both, an advisory arrives and nobody can say whether it applies.

A senior DLA Piper cybersecurity partner summarises the operational change: organisations are “already grappling with a growing body of Digital Decade legislation, including NIS2, DORA, the Data Act, and the AI Act,” and the CRA adds another cross-cutting reporting obligation on top. Vendors who treat CRA compliance as “add another report” rather than “build a cross-framework incident playbook” will miss the 24-hour deadline.

Why This Is a Structural Moment for RISC-V

The CRA codifies what mature RISC-V vendors were already building — SBOMs for transparency, CVD for responsible disclosure, signed updates for deployed fleets — and makes them mandatory for EU market access. The regulation’s horizontal scope (no ISA carve-out) means a CH32V MCU and an ESP32-C5 Wi-Fi module face the same disclosure-clock obligations as an x86 industrial controller. Open-ISA vendors who already publish detailed reference manuals, hardware errata, and BSP changelogs on a regular cadence have a structural head start.

For Asian RISC-V chipmakers serving EU customers, the practical implication is that the cost of not having a 24-hour vulnerability pipeline is now larger than the cost of building one. Compliance budgets need an SBOM tool, a vulnerability triage workflow, a documented CVD policy, and a pre-signed ENISA reporting account — today, not in 2027.