Zephyr RTOS and the EU Cyber Resilience Act: September 11 Is Weeks Away — What Still Needs to Be Done
There’s a particular kind of false comfort that comes from having made the right foundational choice. Engineering teams that selected Zephyr RTOS over the last few years — partly, in many cases, because of its CRA alignment — are sitting with that comfort right now.
They know Zephyr runs under the Linux Foundation. They know the PSIRT handles CVEs with the kind of transparency you’d expect from a mature open-source project. They know the LTS branches carry five years of security maintenance, which maps cleanly to the CRA’s support window. They know west spdx can generate an SBOM automatically at build time.
All of that provides a strong foundation. It doesn’t necessarily mean the finished product is ready for the CRA obligations that begin on September 11.
Because Zephyr’s CRA alignment belongs to the upstream project. The moment a real product diverges from that upstream—and they all do, for perfectly legitimate engineering reasons—the distance between “we use Zephyr” and “we have a CRA-compliant product shipping into the EU” begins to widen. How significant that gap becomes depends on how the product has evolved and the engineering practices around it.
We covered the CRA landscape in detail earlier this year—the milestones, the fines, the fork problem, the tinyML wrinkle. This article is for the team that read that piece, nodded in the right places, and still has work to do. That’s understandable. Engineering teams have been focused on shipping products, and for many organizations the CRA has remained just below the most immediate priorities.
September 11 is literally around the corner. That changes the calculus.
What September 11 Actually Triggers
Most of the CRA’s requirements, such as security-by-design as a legal mandate, full technical documentation, CE marking, don’t land until December 11, 2027. That’s the date most teams have in mind when they think about CRA compliance, and it’s the right date for that broader body of work.
September 11 is a different and more immediate obligation. What kicks in on that date is Article 14 — mandatory vulnerability and incident reporting — and it operates on a timeline that leaves very little margin for “we’re still setting up our process.”
Here’s what it looks like. Your product is deployed across Germany and the Netherlands. On an ordinary day, your team becomes aware that a vulnerability in a component running in that firmware is being actively exploited in the wild. From that moment, a very specific cascade begins:
*24 hours: File an early warning with ENISA and the relevant national CSIRT
*72 hours: Submit a triage report with a credible resolution path
*14 days: Submit the final report after a corrective measure is available
What most teams haven’t fully internalized is what “becomes aware” demands of their organization. It isn’t passive. It means your vulnerability monitoring process is proactive enough that you know about an actively exploited CVE in your shipping firmware within hours of it being published.
It means you have a named person responsible for making the call. It means a documented workflow exists for drafting and filing the Article 14 report. It means you know which national CSIRT covers your primary EU market. And it means your team has an active, verified account on ENISA’s Single Reporting Platform, which goes live on September 11 itself.
One detail that hasn’t landed widely enough yet: Article 14 applies to products already in the field, not only to new designs built with CRA in mind. The residential gateway your team shipped in 2022. The industrial IoT sensor that’s been in the catalog since 2021. The Wi-Fi access controller that went into production last year. If it has digital elements and it’s selling into the EU, it’s inside the scope of September 11’s reporting obligation, whether or not it was ever designed with that obligation in mind.
The Zephyr SBOM Problem Nobody Warned You About
Here’s where the Zephyr-specific gap gets precise, and where the false comfort described at the start becomes a real compliance risk.
Upstream Zephyr’s west spdx SBOM tooling, built into the CMake build system, is genuinely good for what it covers. It tracks source files, build configuration, and dependencies within the West workspace cleanly, and produces a machine-readable SPDX document that will stand up to scrutiny. If you’re building on a clean upstream Zephyr tree with standard in-tree drivers, it does the job well.
But that’s not the firmware most teams are actually shipping.
In real embedded products built on Zephyr, the binary that lands on the device typically includes components that live entirely outside the West workspace:
i) Vendor HALs delivered as pre-compiled libraries, often from silicon partners who maintain them on their own schedule
ii) Out-of-tree modules that your team or your silicon partner maintains separately from the upstream project
iii) Silicon vendor SDKs — from Nordic, NXP, Silicon Labs, Infineon — that carry their own dependency trees and their own CVE exposure
iv) Binary blobs for specific radio stacks or cryptographic accelerators where source simply isn’t available
None of those components show up in a standard west spdx output, because west doesn’t know they’re there. The result is an SBOM that is accurate for part of your binary and silent about the rest. And under Article 14, if a CVE drops against a component in that silent part, your monitoring process won’t catch it, because your SBOM never told it that component existed.
This is the moment where the forking and maintenance debt problem we described in March becomes a compliance problem, not just an engineering headache. The question has changed. It’s no longer only “can we pull the upstream patch when a fix drops.” It’s “do we even know this component is in our binary, does our SBOM reflect it, and does our CVE scanner know to watch it.” Those are questions many engineering teams are now having to ask.
CVE Monitoring at the Product Level vs. the Project Level
There’s a distinction that sounds subtle until you think about it operationally — and then it matters a great deal.
Monitoring Zephyr upstream CVEs — tracking what the PSIRT publishes, watching the security advisories on the LTS branch you’re pinned to — is not the same as monitoring CVEs against the specific firmware binary running on your device in the field. They are related, but they are not the same thing, and Article 14 requires the latter.
If your shipping firmware runs Zephyr 3.5 with a custom networking patch, a Nordic BLE HAL from early 2024, and an OpenSSL library pinned to a version your silicon vendor’s SDK required, the question Article 14 asks is not “has the Zephyr project published a CVE this week.” It’s “does that CVE affect this specific binary, and do you know about it within hours of the advisory being published.”
Answering that second question requires monitoring tied to the actual component inventory of your shipping firmware, which is exactly why the SBOM accuracy problem in the previous section isn’t just a documentation issue. Your SBOM is the input that makes product-level CVE monitoring possible. Without an accurate one, you’re monitoring the wrong thing. And you’ll find out you were monitoring the wrong thing at the worst possible moment — when a vulnerability is actively being exploited, and the 24-hour clock has already started.
What a Defensible September 11 Position Actually Looks Like
Let’s be direct about what the remaining weeks can and cannot accomplish, because the teams that navigate this transition most effectively are the ones that are realistic about both.
You cannot, in the time remaining, retrofit full CRA compliance onto products that weren’t designed with the December 2027 obligations in mind. Security by design as a legal requirement, complete technical documentation, conformity assessment, and CE marking under the CRA framework are substantial engineering efforts. The right place to be on December 11, 2027, is a separate, longer conversation.
What is achievable now, if the work starts immediately and involves the right people, is establishing a defensible position on the Article 14 reporting obligations that begin on September 11. In practical terms, that means focusing on three areas.
1. An SBOM that reflects what’s actually running on your EU-market devices
Not just the clean upstream Zephyr tree, but the complete firmware that ships to customers: vendor HALs, out-of-tree modules, silicon vendor SDKs, third-party libraries, and binary blobs. That means auditing the firmware build for components that sit outside the primary Zephyr source tree and either incorporating them into an extended SBOM pipeline or maintaining a supplemental inventory that is updated with every firmware release. Importantly, this applies to products already deployed in the field, not only those still under active development.
2. A CVE monitoring process tied to those specific component versions
Your vulnerability monitoring needs to be tied to the actual component inventory in your shipping firmware, with a defined triage owner and an escalation path that can move within hours when an exploited vulnerability is identified. For organizations managing large product portfolios, manual CVE review is unlikely to scale well enough to consistently support the 24-hour reporting timeline. In practice, automated monitoring becomes an important part of maintaining that level of responsiveness.
3. A tested Article 14 reporting workflow
A named owner. A documented process for preparing the early warning, the 72-hour update, and the final report. Access to the ENISA Single Reporting Platform should be established and verified before it’s needed, rather than during an active incident. Many organizations would also benefit from running at least one tabletop exercise or simulated vulnerability report so the team has already worked through the end-to-end process before a real incident occurs.
For many organizations, these are realistic priorities to complete before September 11, provided the work starts immediately.
A Closing Thought
The teams that will navigate September 11 most cleanly share one characteristic: they treated this as an engineering problem and resourced it like one, rather than handing it to a compliance function and waiting for a deliverable.
The three capabilities described above are firmware and build-system problems before they are compliance problems. Getting them right requires people who understand what’s actually in an embedded binary, how vendor HALs get integrated, where out-of-tree modules live in a Zephyr workspace, and how to wire automated CVE scanning into a CI/CD pipeline without grinding the development team to a halt.
That’s the work embedUR has been doing alongside Zephyr product teams as the CRA milestones have come into focus — sustaining engineering, CVE monitoring pipelines, SBOM tooling extended to cover the full binary beyond the West workspace, and hardware-in-the-loop test environments for security regression.
We know where the component gaps typically live for Nordic, NXP, Silicon Labs, and Infineon products, because we’ve spent years inside those codebases. We’ve walked this path with teams who came to us earlier in the year, and the same path is still open, but the window to do it without a fire drill is closing fast.
If you want to understand specifically where your Zephyr stack stands relative to the Article 14 obligation, a good place to start is embedUR’s CRA Readiness Audit. A short scorecard that gives you an immediate snapshot of your exposure across SBOM coverage, CVE monitoring, and incident reporting readiness. It takes a few minutes, and the result tells you, in plain terms, where the gaps are and how urgent they are to close.
If what comes back raises questions or confirms what you already suspected, that’s the right time to talk to us. We can do a technical review of your firmware and build pipeline and tell you exactly what it realistically takes to close those gaps before September 11.
