The European Commission published draft guidance for the EU Cyber Resilience Act this week. It is the first concrete signal of how regulators expect manufacturers to interpret the obligations they signed into law in October 2024.

If you are shipping a connected device into the EU, three numbers matter: September 2026, December 2027, and 24 hours.

• September 11, 2026 — vulnerability and incident reporting obligations begin
• December 11, 2027 — full CRA compliance deadline for all products with digital elements (PDEs)
• 24 hours — the window to issue an early warning notification to ENISA after becoming aware of an actively exploited vulnerability

You have 15 months to reach the first deadline. For most hardware teams we work with, that is barely enough time. This post lays out what the draft guidance changes, what it confirms, and the architectural decisions you need to make in the next 90 days to stay on schedule.

What the Draft Guidance Actually Says

The draft guidance, published for stakeholder feedback this month, does not change the underlying law. What it does is clarify the European Commission’s expectations on the questions manufacturers have been arguing about for the last 12 months.

Three areas are now significantly clearer.

1. The Scope of “Product with Digital Elements” (PDE) Is Broader Than Many Expected

The guidance confirms that almost any device with networking capability falls within scope. A vibration sensor with a BLE radio is in scope. A consumer thermostat is in scope. An industrial gateway with a Linux stack is in scope. The carve-outs for medical devices and automotive are real, but narrower than industry lobbying had hoped.

If your product has a microcontroller, a network interface, and is sold in the EU, assume CRA applies. The burden is on you to prove otherwise, not on the regulator to prove inclusion.

2. “Actively Exploited” Has a Working Definition

The September 2026 reporting deadline applies to actively exploited vulnerabilities and the draft guidance now defines this term. A vulnerability is considered actively exploited when there is credible evidence that a threat actor has successfully used it against at least one in-the-wild target, regardless of whether that target is your customer.

For embedded device manufacturers, this means you need a process for ingesting threat intelligence, not just internal vulnerability disclosure. You need to know when a CVE affecting your platform shows up in active exploit chains, even if no one has reported a customer incident.

3. The 24-Hour Early Warning Is Real and Cannot Be Delegated

The 24-hour early warning notification to ENISA cannot be outsourced to a third-party SOC. The manufacturer’s compliance officer is responsible. The 72-hour follow-up notification and the 14-day final report can be supported by external services, but the initial 24-hour clock starts the moment the manufacturer becomes aware, not when the response team finishes triage.

If your incident response plan assumes a 5-business-day SLA, you are not CRA-compliant. Full stop.

The Five Things Hardware Teams Must Have in Place by September 2026

We have been working with hardware companies on CRA readiness since the regulation passed. Here is what an actually-ready posture looks like, mapped to where most teams currently stand.

1. A Software Bill of Materials (SBOM) for Every Shipping Product

Required by CRA Article 13. The SBOM must be machine-readable (SPDX or CycloneDX format), complete down to transitive dependencies, and continuously updated as firmware versions ship.

Where most teams are: They have an approximate list of major libraries. They have not generated a formal SBOM. They do not have a process for keeping it current as builds change.

What good looks like: SBOM generation is a step in the CI/CD pipeline. Every release produces a fresh SBOM artifact, stored alongside the firmware binary, signed, and accessible to the regulator on request.

Effort to implement from scratch: 3–6 weeks for a mid-sized firmware codebase, assuming you are using Yocto, Zephyr, or another modern build system. Longer if you are on legacy build infrastructure.

2. A Coordinated Vulnerability Disclosure (CVD) Policy

Required by CRA Annex I, Part 2. You must have a published policy describing how security researchers can report vulnerabilities to you, what your response timeline is, and how you will communicate fixes to customers.

Where most teams are: They have a generic security@company.com email and no documented response process.

What good looks like: A public security.txt file. A documented internal SLA for triage, fix, and disclosure. A process for issuing CVEs through a CNA partner if your organisation is not itself a CNA.

3. Secure Update Mechanism (OTA) with Verified Integrity

Required by CRA Annex I, Part 1. Devices must be able to receive security updates throughout their declared support period. Updates must be authenticated and verified before installation.

Where most teams are: They have OTA for feature releases but it was bolted on after the product shipped. Signing infrastructure is informal. Rollback testing is incomplete.

What good looks like: A signed, verified, A/B partitioned OTA system with documented rollback behaviour. Public signing keys baked into a protected bootloader region with a rotation mechanism. TLS 1.3 for transport. Anti-rollback enforcement.

We wrote a detailed architecture guide on getting OTA right from day one — Why Most Embedded Teams Get OTA Wrong — which walks through the partition strategy and bootloader decisions that have to be made before EVT to support a CRA-compliant update path.

4. Fleet Telemetry That Can Prove Per-Device Security Update Status

Required implicitly by CRA Articles 13 and 14. You must be able to demonstrate, on request, that security updates have been applied across your installed base.

Where most teams are: They know roughly which firmware versions are deployed. They cannot produce a per-device update status report.

What good looks like: Each device reports its current firmware version, last successful update timestamp, and rollback events to a fleet management backend. Reports can be exported as audit evidence.

This is often where the gap between feature engineering and compliance engineering becomes painful. The telemetry pipeline that was good enough for product analytics is rarely good enough for regulatory audit.

5. A Documented Vulnerability Handling Process Tied to ENISA Reporting

Required by CRA Article 14. You must have a documented process for:

• Receiving vulnerability reports
• Triaging severity and exploitability
• Generating the 24-hour early warning to ENISA when criteria are met
• Issuing the 72-hour incident notification
• Delivering the 14-day final report
• Notifying affected users within the same windows

Where most teams are: They have an internal incident response runbook that was last updated before the regulation passed.

What good looks like: A CRA-specific runbook with named owners, escalation paths, ENISA portal credentials, and template notifications. Tabletop exercises run quarterly with the compliance officer participating.

What Changes If You Are Currently at EVT, DVT, or PVT

The earlier you are in the product lifecycle, the easier and cheaper compliance becomes. Here is what to prioritise at each stage.

At EVT: Decide your OTA partition strategy with CRA in mind. Spec the flash for A/B updates. Choose a signed bootloader (MCUboot or U-Boot). Get the SBOM generation step into the build system before the codebase becomes hard to refactor.

At DVT: Implement and test the full security update path under failure conditions. Document the vulnerability disclosure process. Start drafting the CVD policy. If you have not yet appointed a person responsible for cybersecurity compliance, do so now.

At PVT: Integrate manufacturing provisioning of cryptographic identities. Validate the fleet telemetry pipeline produces audit-ready data. Run a tabletop exercise simulating a 24-hour ENISA notification.

Already in MP: This is the hardest position. You are retrofitting compliance onto products that were not designed for it. The priorities shift to: documenting current state, identifying highest-risk gaps, and triaging which devices can be made compliant through firmware updates versus which will need hardware revisions in the next refresh cycle.

We have worked with two clients in this position over the last 18 months. The honest answer is that compliance for a fielded product designed without CRA in mind takes 6–9 months and costs roughly €150–300K depending on fleet size and firmware complexity.

What the Draft Guidance Does Not Resolve

Three areas remain unclear, and the public consultation period (open until late summer 2026) is the moment to push for clarification if your product is affected.

1. Definition of “support period.” Manufacturers must declare a security support period for each product, but the guidance gives no minimum. Industry consensus is forming around 5 years for consumer devices and 10 for industrial, but this is not law.
2. SBOM disclosure to whom. The guidance is clear that SBOMs must be maintained, but ambiguous on whether they must be disclosed to customers on request, only to regulators, or made public. Many manufacturers have legitimate trade-secret concerns here.
3. Treatment of open-source components. The CRA explicitly carves out non-commercial open-source contributors, but the boundary between “open-source maintainer” and “manufacturer using open-source” is fuzzy when a vendor ships a Yocto-based Linux image with thousands of OSS components.

If your product depends on heavy OSS use, file feedback on the consultation. The guidance can still change.

What Better Devices Recommends Doing in the Next 90 Days

Most hardware teams we work with are 6–9 months behind where they need to be for September 2026 reporting readiness. If you are in that position, here is a 90-day action plan:

Month 1: Appoint a named CRA compliance owner. Run an internal gap assessment against the five requirements above. Decide which gaps are firmware-fixable and which require process or organisational changes.

Month 2: Implement SBOM generation in CI/CD. Draft and publish the CVD policy. Build (or commission) the ENISA notification runbook. If your OTA infrastructure has gaps, scope the firmware work required to close them.

Month 3: Validate the fleet telemetry pipeline produces audit-ready reports. Run a tabletop exercise. Brief your executive team on residual risk and remediation timelines.

If September 2026 still feels far away, run the calculation backwards. To be confident on Day 1 of September, you need the full process tested by August. To test in August, you need it built by July. To build in July, you need scoping and design done by May. May is now.

Where to Get Help

At Better Devices, CRA readiness is built into how we approach every embedded engagement. We support clients with:

• Compliance gap assessments against the five core CRA requirements
• OTA architecture and implementation for products that need a CRA-compliant update path
• SBOM generation and CI/CD integration for Yocto, Zephyr, and other modern build systems
• Fleet telemetry design for audit-ready per-device compliance reporting
• CVD policy and ENISA notification runbook development

If your product is shipping into the EU and September 2026 is on your roadmap, we should talk. The earlier you start, the cheaper compliance gets.

---

Better Devices is a Berlin-based embedded engineering consultancy. We help hardware teams design, validate, and ship CRA-compliant connected devices — from PoC through mass production. Read our related guides: Surviving the EU Cyber Resilience Act: A Guide for Legacy Hardware, Why Most Embedded Teams Get OTA Wrong, and Security by Design: Protecting Embedded Systems from the Ground Up.

Frequently Asked Questions