The Cyber Resilience Act's Reporting Clock Starts September 11 — Before Your Upstream's Does

TL;DR: The EU Cyber Resilience Act (Regulation (EU) 2024/2847) applies in two phases. September 11, 2026 — this week — is Phase 1: report an actively exploited vulnerability or severe incident within 24 hours of becoming aware, a fuller notice at 72 hours, a final report 14 days after a fix exists. December 11, 2027 is Phase 2: full essential requirements, conformity assessment, CE marking. Phase 1 applies to products already shipping, and the clock starts on your awareness, which can run ahead of your RTOS vendor’s own disclosure. Below: what’s imminent, how Zephyr handles its half as an open-source steward, what’s left for you as the manufacturer, where it actually hurts, and a worked example end to end.

Update (10 September 2026): A reader correctly pointed out that an earlier version of this piece blurred an important distinction: Article 14’s clock starts on awareness of active exploitation (or a severe incident) — not on merely discovering that you ship a reachable, affected component. A vulnerability sitting under an embargoed CVD/VDP process with no evidence of exploitation does not, by itself, trigger the 24-hour deadline. The “two clocks” section and the worked example below have been corrected to reflect that, and a note on CVEs — not required for Article 14 to apply — has been added.

What the CRA is

Regulation (EU) 2024/2847 entered into force on 10 December 2024. It covers any “product with digital elements” placed on the EU market — hardware, firmware, and the software that ships with it — and does three things: sets essential cybersecurity requirements (Annex I), requires conformity assessment and CE marking, and creates a duty to report exploited vulnerabilities and severe incidents (Article 14). It doesn’t distinguish open-source from proprietary components — it regulates the product you place on the market, built from whatever went into it.

What’s imminent

11 September 2026 is when Article 14 — vulnerability and incident reporting — becomes applicable. Under Article 69(3) it applies to products already on the market, not just new designs. Once you’re aware of an actively exploited vulnerability or a severe incident, three deadlines start:

Reports go to your designated national CSIRT and, automatically, to ENISA. The single reporting platform ENISA is standing up for this hadn’t published a public URL as of two weeks before the deadline — it’s scheduled to go live the same day the obligation does.

The two-phased approach

It helps to stop treating the CRA as one deadline and read it as two:

• Phase 1 — now through 11 December 2027: reporting only. Article 14 applies uniformly to every manufacturer, regardless of how your product will eventually be classified. No conformity assessment, no CE marking — just a working incident-response process.
• Phase 2 — from 11 December 2027: full application. Annex I’s essential requirements, conformity assessment, and CE marking become mandatory. The route depends on classification:

One catch worth planning around now: no CRA harmonised standard has been published in the Official Journal yet, for any category. The first standards are expected around Q3 2026, but publication in the OJ is what actually triggers Article 27’s presumption of conformity, and that hasn’t happened. A Class I product that could in principle self-assess against a published standard has no standard to point to today — so Phase 2 prep currently means documenting directly against the Annex I text, not waiting for a shortcut.

How Zephyr is handling it

Zephyr — the RTOS this site’s founder maintains the Wi-Fi stack for — qualifies as an open-source software steward under Article 3(14): an organization that systematically sustains development of a product intended for commercial use, distinct from a “manufacturer.” Under Article 24, that comes with its own obligations: a documented cybersecurity policy, cooperation with market surveillance authorities, and — from the same 11 September 2026 date — reporting actively exploited vulnerabilities and severe incidents affecting its own development infrastructure.

Zephyr already runs the mechanics this implies: private security advisories, PSIRT feedback targeted within 7 days, an embargo of up to roughly 90 days while a fix is prepared, then usually a CVE — Zephyr has been a CVE Numbering Authority since 2017 — and public disclosure, plus a vulnerability alert registry manufacturers can subscribe to for advance notice. None of that is what starts your Article 14 clock, though — a CVE isn’t required for Article 14 to apply at all, and plenty of actively exploited vulnerabilities never get one.

Zephyr’s own CRA documentation is explicit about where its responsibility ends and yours begins: your Article 14 clock is triggered by when you become aware — but aware of what matters. Being on the alert registry, or running your own check against a private advisory, tells you whether a component you ship is present and reachable. That’s necessary, not sufficient. The clock only starts once you’re also aware the vulnerability is being actively exploited (or that you have a severe incident on your hands) — which can genuinely happen while Zephyr’s own embargo is still open, and your obligation doesn’t wait for that embargo to lift.

How manufacturers need to handle it

None of Zephyr’s Article 24 work substitutes for your Article 13 obligations. “We ship an open-source RTOS, so the project handles CRA compliance” is the most common misreading of this regulation. As the manufacturer, you keep: risk assessment, technical documentation, an accurate SBOM, vulnerability management decisions, conformity assessment, CE marking, and the Article 14 clock itself. It also runs the other way — Article 13(6) requires you to report a vulnerability you discover in a component you integrate, including back upstream.

The SBOM is the part most teams underbuild. Annex I Part II requires you to “identify and document vulnerabilities and components… including by drawing up a software bill of materials (SBOM) in a commonly used machine-readable format… covering at least the top-level dependencies.” It doesn’t need to be public — it lives in your technical documentation, produced for authorities on request. Zephyr ships the tool for its half:

west spdx --init -d BUILD_DIR
west build -d BUILD_DIR -- -DCONFIG_BUILD_OUTPUT_META=y
west spdx -d BUILD_DIR
# → BUILD_DIR/spdx/ : SPDX 2.3 tag-value or SPDX 3.0 JSON-LD,
#   split into an application-source BOM and a Zephyr-source BOM

That command produces separate app, zephyr, build, and modules-deps documents — don’t stop at reading them. Both trivy and grype consume SPDX tag-value output directly: trivy sbom BUILD_DIR/spdx/zephyr.spdx or grype sbom:BUILD_DIR/spdx/zephyr.spdx will match every component in that exact build against known CVEs, which turns a fresh advisory into a pass/fail list in seconds instead of a manual grep through release notes. For a product you’re supporting long-term, point the same files at a continuous scanner such as Dependency-Track so a new CVE against something you’ve already shipped surfaces on its own, rather than waiting for the next manual audit.

“Top-level dependencies” is a floor. A useful SBOM resolves to your Kconfig — which driver, which crypto backend, which optional subsystem shipped in this build — so an advisory becomes a fast reachability check instead of a research project.

One head start worth knowing about if your product talks Wi-Fi or any internet-connected radio: RED’s Delegated Regulation (EU) 2022/30 cybersecurity requirements have been mandatory since 1 August 2025, backed by an already-published harmonised standard, EN 18031. CRA’s Annex I overlaps that scope closely enough that the Commission is repealing 2022/30 the day CRA fully applies, rather than running both indefinitely. EN 18031 evidence you already produced isn’t a separate track — it’s a working draft of a real part of your CRA technical documentation.

Pain points

Where this actually bites, in order of how often it shows up in practice:

• No harmonised standard to point to. Phase 2 prep means writing your own rationale against Annex I text, with no shortcut available yet.
• 24 hours is an engineering deadline, not a legal one. Once exploitation is confirmed, turning “there’s an advisory” into “this affects us” fast enough requires SBOM-to-Kconfig reachability tooling most teams haven’t built.
• SBOM drift. Anything vendored or forked outside the west manifest, or pulled into the application layer some other way, goes stale first if SBOM generation isn’t wired into CI.
• Classification ambiguity. “Microprocessors/microcontrollers with security-related functionality” is a real Class I trigger, and it’s easy to assume default category without checking your actual bill of materials.
• No PSIRT function. Most embedded teams have never had to run intake-triage-notify as an ongoing process; it has to exist before the first advisory lands, not after.
• The 5-year support-period commitment. Article 13(8) makes this a contractual and sales commitment, not just an engineering one — and the end date has to be stated to purchasers at point of sale.

A compliant flow, worked end to end

Take a Wi-Fi-connected sensor built on Zephyr and an nRF54-class SoC.

1. A vulnerability is found in a Zephyr networking subsystem. Zephyr’s PSIRT opens a private advisory; you’re on the alert registry, so you see it immediately rather than waiting for the public CVE. This is a normal CVD process — nothing is reportable yet, and nothing should be.
2. Your CI already runs west spdx against every release build. You check the affected subsystem against your Kconfig and confirm it’s compiled in and reachable from an unauthenticated path. That tells you whether you’re affected. It does not, by itself, start any clock.
3. Weeks later, a customer report (or your own monitoring) shows the vulnerability is now being actively exploited in the field — while Zephyr’s embargo is still open. That’s the moment you become “aware” for Article 14 purposes, logged with a timestamp. The clock starts here, independent of where the embargo stands.
4. T0 + 24h: early warning to your CSIRT and ENISA — notification type, your name, product ID, issue title.
5. T0 + 72h: fuller notice — the general nature of the vulnerability, your initial assessment, and the mitigations available so far (e.g. a configuration workaround while a patch is built).
6. In parallel, engineering builds and validates the fix against your secure update path — a signed image through MCUboot, A/B partitioned, with anti-rollback — and stages it for fleet delivery separately from any feature release.
7. Once the fix is available, the 14-day final report goes out: full description, severity, impact, and remediation detail.
8. The SBOM snapshot, the reachability determination, the exploitation evidence, the three reports, and the patched build are retained together as part of your technical documentation — the same evidence trail Phase 2’s conformity assessment will eventually ask for.

Nothing in that flow depends on a harmonised standard existing yet. It depends on the SBOM, the reachability tooling, the update mechanism, and the reporting contact already being in place before the advisory lands.

Where we come in

If you want a second, technical pair of eyes on where your product actually sits against Article 14 and Annex I — not a compliance checklist, an engineering read — that’s the shape of our Technical Audit: five days, fixed fee, a written report on what’s built and what’s missing, plus a walkthrough with your engineers. For teams past that stage, it folds into an Engineering Sprint to build the SBOM pipeline, PSIRT process, or update architecture, or a Retainer to keep it current as Zephyr, hostap, and Mbed TLS/PSA Crypto keep moving under you.

Let’s talk.

Talk to us about a CRA readiness audit