Axon Labs
All insights

From the engineering desk

Insight12 min read20 July 2026

Cyber Resilience Act: An Engineering Guide for Device Makers

What the CRA requires you to build — SBOMs, secure boot, signed updates and 24-hour reporting readiness — before the September 2026 deadline.

By Axon Labs Engineering

In 2026, 66% of organizations remain unfamiliar with the EU Cyber Resilience Act — and in the US and Canada it's 72%, per the OpenSSF and Linux Foundation's readiness study. Yet on 11 September 2026, mandatory 24-hour vulnerability reporting begins for every connected product sold into the EU, wherever its maker sits. This guide covers what the CRA actually requires you to build — not just document — phase by phase.

Key takeaways

  • The CRA is the first EU-wide mandatory cybersecurity law for products with digital elements: reporting obligations start 11 September 2026, full obligations 11 December 2027, with fines up to €15M or 2.5% of global turnover.
  • Readiness is poor: in 2026, 66% of organizations are unfamiliar with the CRA and only 32% of manufacturers generate SBOMs for all products (OpenSSF/Linux Foundation).
  • Compliance is an architecture problem — secure boot, signed OTA updates, an SBOM pipeline and a PSIRT. Documentation follows architecture; it never replaces it.

What is the Cyber Resilience Act and who must comply?

The Cyber Resilience Act — Regulation (EU) 2024/2847 — is the first EU-wide law making cybersecurity a mandatory condition for market access. It covers every “product with digital elements”: hardware, embedded software, and the remote services they depend on. If your product has a processor and ships to the EU, the CRA applies — regardless of where your company is based (European Commission).
The law sorts products into a default class covered by self-assessment, “important” classes I and II with stricter conformity routes, and a small critical tier. Compliance becomes part of CE marking — the same gate as safety and EMC. Miss it, and the product legally can’t be sold in the EU.
Awareness hasn’t caught up. In 2026, 41% of organizations that know about the CRA still haven’t determined whether it applies to them, per the OpenSSF/Linux Foundation readiness report. For North American exporters the gap is widest — and the deadline doesn’t move for being unaware of it.

What are the CRA deadlines?

Three dates matter. 11 June 2026: the chapter on notified conformity-assessment bodies took effect. 11 September 2026: mandatory vulnerability and incident reporting begins — the operative fire alarm. 11 December 2027: the full essential requirements apply and CE marking depends on them.
September’s deadline is the one that catches teams out, because it applies to products already on the market, not just new ones. The European Commission published implementation guidance on 3 March 2026 and maintains a living FAQ — first issued December 2025 — that answers scope edge-cases as they arise (IBF Solutions).

Does the CRA apply to your product?

The working assumption: if it has a processor and ships to the EU, it’s in scope until proven otherwise. The genuine exclusions are narrower than most teams hope, and the details live in the Commission’s FAQ (legacy-products guidance).
  • Legacy products. Units placed on the market before 11 December 2027 aren’t retroactively subject to the essential requirements — unless they’re “substantially modified” afterwards. But Article 14 reporting applies to all products, including legacy ones, from 11 September 2026.
  • Spare parts. One-to-one replacements for an existing product are excluded, even from an old design (KEBA CRA FAQ).
  • Open-source software. An exception exists, but it hinges on commercial activity — hardware that ships with open-source components is still fully in scope.
  • Substantial modification. A firmware update that adds features or changes the security posture can re-trigger obligations for an old product. Plan update roadmaps with this line in view.
One planning tool worth adopting early: product families. Products sharing context, architecture, and security mechanisms can be assessed together — which turns a portfolio-wide compliance problem into a handful of assessments.

What does Annex I actually require — in engineering terms?

Annex I reads like legal text but behaves like an architecture specification. Roughly 80% of it maps to concrete engineering artifacts. If your product has them, the documentation follows naturally; if it doesn’t, no amount of paperwork makes you compliant.
Annex I requiresWhat you buildEvidence
Secure-by-default configurationNo default passwords; least-privilege services; hardened factory imageConfiguration baseline + factory-image audit
Minimized attack surfaceUnused ports and debug interfaces disabled; JTAG locked in productionInterface inventory + provisioning checklist
Protection of dataEncryption at rest and in transit; hardware-backed key storageCrypto architecture + key-management plan
Secure updatesSigned, staged, revertible OTA for firmware and modelsUpdate-path design + rollback test evidence
Logging & monitoringTamper-evident security event logging with exportLog schema + retention policy
Vulnerability handlingSBOM, intake channel, patch process, coordinated disclosurePSIRT charter + published disclosure policy
This is the same argument we made in Secure by Design for Connected Hardware before the law required it: security added after architecture is a patch; security designed into the architecture is a property. The CRA effectively writes that principle into market-access law.

How do you build an SBOM pipeline for embedded products?

In 2026, only 32% of manufacturers generate software bills of materials for all their products (OpenSSF/Linux Foundation). The CRA requires a machine-readable SBOM covering at least the top-level dependencies of every product with digital elements, kept current and available to market-surveillance authorities on request.
  • Firmware is the hard part. A Yocto or Zephyr build pulls in hundreds of components; vendor SDKs bury more. Generate the SBOM from the build system — not by hand — or it will be wrong by the second release.
  • Pick a standard format. CycloneDX and SPDX are both machine-readable and tooling-rich; either satisfies the requirement. Consistency across products matters more than the choice.
  • Automate it in CI. The SBOM regenerates on every build, versions with the firmware, and travels with each OTA release. A stale SBOM fails the “kept current” test.
  • Feed it forward. The SBOM isn’t paperwork — it’s the input to vulnerability monitoring. Matching your dependency list against CVE feeds is what makes 24-hour awareness physically possible.

What architecture does the CRA assume you already have?

Read the obligations backwards and an architecture appears. You can’t “handle vulnerabilities” in the field without a signed update path. You can’t trust the update path without secure boot and a root of trust. You can’t report exploitation within 24 hours without telemetry that detects it. The CRA quietly presupposes all four.
  • Hardware root of trust — key storage and boot verification anchored in silicon, chosen at MCU/SoC selection time. The bill of materials is a security document.
  • Secure boot chain — each stage verifies the next; a compromised image doesn’t run.
  • Signed, staged, revertible OTA — with rollback protection, for firmware and, in intelligent devices, for models too.
  • Security telemetry — logging designed for the questions an incident asks: what ran, when, and what changed.
Intelligent devices add one more layer: models are assets to protect and update paths of their own — the security section of our edge AI development guide covers it, and AI cybersecurity at the hardware layer shows how intelligence below the software stack can defend as well.

How do you prepare for 24-hour vulnerability reporting?

From 11 September 2026, an actively exploited vulnerability or severe incident triggers a clock: an early-warning report within 24 hours, details within 72 hours, and a final report within 14 days of a fix — filed through the single reporting platform coordinated by ENISA and national CSIRTs (ONEKEY).
  • Stand up a PSIRT — even a small one. Named roles, an intake address, an escalation path, and authority to ship a fix. The 24-hour clock is unforgiving of “who owns this?” meetings.
  • Monitor continuously. SBOM-to-CVE matching plus field telemetry is what turns “we found out from a customer” into “we detected it Tuesday night.”
  • Pre-draft the notifications. Templates for the 24-hour early warning and 72-hour report, written calmly in advance, beat prose written at 3 a.m. during an incident.
  • Rehearse once. A half-day tabletop exercise — vulnerability discovered, clock started — finds the missing pieces while they’re still free to fix.

What does non-compliance cost — and what does compliance cost?

The penalty ceiling is €15 million or 2.5% of worldwide annual turnover, whichever is higher, plus market-withdrawal powers (Mend.io). For a hardware company, the withdrawal power is the sharper threat — inventory that can’t legally ship is a balance-sheet event, not a fine.
The compliance side is more manageable than the headlines suggest. In 2026, 40% of manufacturers plan to pass costs to customers at an average 4% price increase — down from the 6% they anticipated in 2025 (OpenSSF/Linux Foundation). Costs fall as tooling matures, and they fall furthest for teams that design security in rather than bolt it on.
There’s also an upside worth naming: for enterprise buyers, CRA readiness is becoming a procurement filter. A device maker who can hand over an SBOM, a disclosure policy, and a conformity file mid-sales-cycle closes against competitors who can’t. Compliance built early is a sales asset wearing a legal costume — the same phase-gate logic as the rest of hardware product development: evidence beats intentions.
You can't paper over a missing update mechanism.

The bottom line

  • The CRA applies to virtually every connected product sold into the EU, wherever it’s made. Reporting starts 11 September 2026; full obligations land 11 December 2027.
  • Annex I is an architecture spec: root of trust, secure boot, signed OTA, SBOM pipeline, telemetry, PSIRT. Build those and the documentation follows.
  • Retrofit costs multiples of design-in. If an EU market is anywhere on your roadmap, CRA-readiness belongs in the feasibility phase, not the launch checklist.
This is engineering guidance, not legal advice — deadline facts verified July 2026 against Commission sources. If your product roadmap crosses the EU market, start with a discovery & feasibility phase — a few weeks of security architecture, risk and cost modeling that de-risks everything after it.

Frequently asked questions

Does the Cyber Resilience Act apply to non-EU manufacturers?

Yes. The CRA applies to any product with digital elements placed on the EU market, regardless of where the manufacturer is based. North American readiness lags most — 72% of US/Canadian organizations were unfamiliar with the CRA in 2026 (OpenSSF/Linux Foundation).

Do products already on sale need to comply?

Not retroactively with the full requirements — products placed before 11 December 2027 are exempt unless substantially modified afterwards. But Article 14 vulnerability and incident reporting applies to all products, including legacy ones, from 11 September 2026 (European Commission FAQ).

Is open-source software exempt from the CRA?

There's an exception, but it hinges on commercial activity. Non-commercial open-source development is out of scope; a commercial product that ships open-source components is fully in scope, and the manufacturer owns compliance for everything in its SBOM.

What must be reported within 24 hours under the CRA?

Actively exploited vulnerabilities and severe incidents affecting product security. The cadence is an early-warning report within 24 hours, detailed notification within 72 hours, and a final report within 14 days of a fix — via the ENISA single reporting platform, from 11 September 2026.

What are the penalties for CRA non-compliance?

Administrative fines up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher, for breaching essential requirements — plus the power to force products off the EU market, which for hardware makers is often the costlier consequence.

Sources

If the product has to ship, talk to the team that builds for that outcome.

Senior engineer on the first call. NDA before technical detail. References available under NDA after qualification. Or start with a fixed-fee feasibility study.

Request a conversationFeasibility study