What the EU CRA actually requires from your ESP32 product, and the ship list before September 2026

Two dates, twelve months. Mark them now and back-solve from there.

September 11, 2026 is when the active-exploitation reporting obligations of the EU Cyber Resilience Act go live. Any product with digital elements you sell into the EU, including the small ESP32-based thing you ship in a brown box from a contract manufacturer in Shenzhen, owes ENISA a notification within 24 hours of becoming aware that one of your devices is being actively exploited in the wild.

December 11, 2027 is when the rest of the regulation becomes fully applicable. SBOMs in the technical documentation. Vulnerability handling processes. Conformity assessment. CE marking that now means something it did not mean before.

If you are a 2 to 10 person embedded team and you have not started, this post is the list of artifacts you need to be able to produce on demand. No fear-mongering, no recap of the legislation you have not had time to read. Just the ship list, the ESP-IDF specifics, and a worked example of what the patch-and-evidence cycle looks like in practice.

What "SBOM in the technical documentation" actually means

The CRA wants a Software Bill of Materials. Every component in your firmware, with name, version, supplier, and license, machine-readable, kept current.

Two formats dominate. CycloneDX is the OWASP-flavored one, originally focused on application security, now widely used for embedded. SPDX is the Linux Foundation one, originally focused on license compliance, now widely used everywhere. Both are JSON. Both encode the same fields the regulator cares about. ENISA does not have a preferred format and the CRA text does not name one, which is the right call: pick the format your toolchain emits and stop debating it in standups.

The thing that trips embedded teams up is not the format. It is that an ESP-IDF build pulls in roughly 200 components once you count the IDF itself, the component manager dependencies, your direct dependencies, and any vendored third-party C. You need an SBOM that reflects that, per release, archived. Not a Notion page someone updates manually. The build pipeline emits it or you do not have one.

The good news: Espressif ships esp-idf-sbom as a first-party tool. It walks the build artifacts of an ESP-IDF project and emits a CycloneDX SBOM. Wire it into CI, archive the output alongside the firmware binary for every signed release, and you have the artifact the auditor will ask for.

The 24-hour active-exploitation reporting clock

This is the part most teams have not thought through, because it is operational and not technical.

The clock starts when you, the manufacturer, become aware that a vulnerability in your product is being actively exploited. Not when a CVE is published. Not when a researcher emails you. When you have evidence that an attacker is using a flaw in your shipped firmware against a real user.

You owe ENISA an early-warning notification within 24 hours. A more detailed notification within 72 hours. A final report within 14 days. The exact submission portal, evidence schema, and acknowledgement workflow is being stood up by ENISA across 2026.

Operationally, this means three things you have to decide in advance:

Who in your company is allowed to declare that the clock has started. This is a judgment call, made under time pressure, with incomplete information. Pick the person now. Write it down. Tell the rest of the team. If the answer is "we will figure it out when it happens," you will miss the 24-hour window.
What evidence you submit. ENISA will want the CVE or vulnerability identifier, affected versions, what the exploit does, and what you are doing about it. You need to be able to assemble that in hours, not days. That means your fleet-state data has to already exist.
A public coordinated-disclosure policy. A security.txt file on your marketing site, an email address that goes to a human, and a documented response timeline. This is also a CRA requirement and the cheapest one to ship. Do it this week.

The reporting clock is the operational keystone of CRA compliance. Everything else, the SBOM, the patch evidence, the fleet state, exists so you can credibly hit this clock.

What Espressif gives you for free

Espressif has been moving on this for over a year and as of early 2026 they ship most of what an ESP32 team needs to start. From their March 2026 CRA post, the relevant tooling:

Security Advisories repository, the canonical place to watch for ESP-IDF, mbedTLS, lwIP, and Wi-Fi stack CVEs that affect your build. Subscribe with GitHub watch notifications. Do not wait for them to find you on Twitter.
esp-idf-sbom, the CycloneDX generator described above.
Security Dashboard on the Espressif developer portal, which surfaces CVEs scoped to specific IDF versions. If you tell it you are on IDF 5.4.1, it tells you what is unpatched in 5.4.1.
RED DA Assessment Tool, the gap-analysis self-questionnaire for the EU Radio Equipment Directive Delegated Act, the security baseline that overlaps roughly 70 percent with what the CRA wants. Working through it is the cheapest way to find out where your product is exposed.
Long-term-support IDF branches with a published support window, which is the only honest way to manage CVE response on shipped product. Pin to LTS, not to bleeding-edge minor.

What Espressif does not give you is the fleet-side state. That part is yours.

What you have to build yourself

Espressif tells you which CVEs exist. They cannot tell you which of your devices are running the affected firmware version, where those devices are deployed, or whether your last OTA actually landed.

That state lives in your cloud, or it does not exist. Concretely, you need:

A per-device deployed-version table. Device ID, firmware hash, IDF version, deployment timestamp, last seen. Updated automatically by the device on every boot and OTA. This is the table the auditor will ask to see, and it is the table you will pull from at 2am when CVE-2025-XXXXX drops and your CTO asks "how many of our devices are exposed."
OTA evidence trail. When you push firmware version N+1 to fleet F, you need a log of which devices acknowledged the update, which rolled back, which never came back online. Not just "we sent it." Proof it landed. ESP-IDF supports rollback and anti-rollback natively; you need the cloud side to record the outcome of every attempt.
Vulnerability handling process documentation. Written, dated, version-controlled. Who triages a new CVE, what severity bands trigger what response, who signs off on the patched build, who makes the call on the 24-hour clock. This is the document the auditor opens first.
Public coordinated-disclosure policy. As above. Single hardest artifact for a small team to produce, because it requires deciding what your response timelines actually are. Do not write commitments you cannot meet.

The team that ships this in 2026 is the team that already had a fleet-management layer with deployed-version state. The team that has to build it from scratch in response to the regulation is looking at a 4 to 6 month project on top of their roadmap.

A worked example

Two-hundred-device thermostat fleet. ESP32-S3, IDF 5.4.1, deployed across European hotels through an OEM partner. Tuesday morning your on-call sees two new entries on the Espressif security dashboard: a high-severity Wi-Fi stack issue and a medium-severity mbedTLS issue, both fixed in IDF 5.4.2.

Here is the next 48 hours.

Tuesday 09:00. On-call pulls the fleet-state table. 200 devices, 187 on firmware 1.4.3 (IDF 5.4.1, exposed to both CVEs), 13 on 1.4.2 (also exposed). Severity assessment: high-CVE is exploitable only if attacker is on the same Wi-Fi network as the device. Hotels with guest Wi-Fi separation are at lower risk. Hotels without are at higher risk. Risk is not zero, but it is not "drop everything." No evidence of active exploitation. The 24-hour clock has not started.

Tuesday 11:00. Bump the IDF dependency to 5.4.2 in the build. Run the standard test suite. Build firmware 1.4.4. CI emits the new SBOM, archives it next to the binary, signs the binary.

Tuesday 15:00. Push firmware 1.4.4 to a 10-device canary cohort, hotels you have a direct line to. Watch for boot success and rollback signals.

Wednesday 09:00. Canary clean. Push to the remaining 190 devices in waves of 50, with 4-hour gaps between waves to catch regressions.

Wednesday 21:00. Fleet table shows 198 of 200 on 1.4.4. Two devices have not checked in, both at the same hotel. Open a ticket with the OEM partner to confirm physical status.

Thursday 08:00. Two stragglers come online and accept the update. Fleet is at 200 of 200 on patched firmware.

The evidence pack you can hand a regulator the next morning, if they ask:

The two CVE IDs and the published Espressif advisories.
Your severity assessment, written down with a timestamp.
The SBOM diff between firmware 1.4.3 and 1.4.4 showing the IDF version bump.
The OTA rollout log showing the canary phase, the wave schedule, and the per-device acknowledgement timestamps.
The fleet-state table showing 200 of 200 on the patched version, with a 47-hour total response time from CVE publication to fleet completion.

This is the loop. Notice what is in it and what is not. There is no scrambling. There is no spreadsheet. There is no slack thread that becomes the audit trail. Every artifact is generated by the system as a side effect of doing the work.

The ship list

Print this. Tape it to the wall. Twelve months.

Public security policy. security.txt on your marketing domain, [email protected], documented response timelines. Ship this week.
CVE monitoring subscribed. GitHub watch on the Espressif Security Advisories repo. Espressif Security Dashboard account.
SBOM in CI. esp-idf-sbom runs on every release build. CycloneDX JSON archived alongside the firmware binary, retention 10 years.
Per-device deployed-version table. Device ID, firmware hash, IDF version, last seen. Updated on every boot.
OTA evidence trail. Per-device acknowledge, rollback, and failure events recorded with timestamps.
Vulnerability handling process document. Written, version-controlled, names not roles. Reviewed quarterly.
Active-exploitation reporting playbook. Who declares the clock has started. What evidence goes to ENISA. Who is on call.
Pin to an Espressif LTS branch. Published end-of-support date in your wiki. Migration timeline before EOS.
RED DA self-assessment completed. Espressif's tool. Two days of work. Tells you where the gaps are.
One named owner of CRA compliance. Not "the team." A person, with their initials next to the line item.

The last one matters most. The teams that hit September 2026 cleanly are the teams where one person owns this and tracks it weekly. The teams that miss it are the teams where the regulation lives in everyone's head and nobody's calendar.

Talk to a founder

If September 2026 is on your calendar and the SBOM, fleet-state, and active-exploitation reporting pieces are not yet in your stack, that's the conversation. Twenty minutes, no slides.

Book a quick chat with Ali