EU Regulation 2024/2847 · Cyber Resilience Act

Is your connected product ready for the EU Cyber Resilience Act?

From December 2027, products with digital elements must prove they're secure to be sold in the EU. We help embedded and industrial product makers get there — the firmware, the secure boot, the paperwork. Find out in 2 minutes what applies to you.

  • Plain-English first, engineer-deep on tap
  • Guided estimate — no email needed to use it
The beginner on-ramp

What is the CRA?

The Cyber Resilience Act is a new EU law. In simple terms: if you sell a product that has software or can connect to anything, it now has to be secure — by law — before it can be sold in Europe. You have to build it securely, keep it patched, and be able to prove it. If you don't, you can't sell it in the EU (and fines can reach €15M or 2.5% of global turnover).

  1. Build it secure

    Security designed in from the start — not bolted on later.

  2. Keep it patched

    Fix vulnerabilities and ship secure updates through the product's life.

  3. Prove it

    Keep the documents and declarations that show you did the work.

  1. Dec 2024 Law starts Entered into force
  2. Sep 2026 You must report vulnerabilities Actively exploited bugs & serious incidents — 24h early warning
  3. Dec 2027 Full rules apply All essential requirements, CE marking, technical file
For engineers

Regulation (EU) 2024/2847 — a horizontal regulation applying across all products with digital elements (PDEs). Scope is determined by intended connectivity (logical, physical, or indirect via a hub), not just by whether a device looks "smart." It complements NIS2 (which targets operators of essential services) and works through the existing CE-marking conformity framework. Harmonised standards — the EN 40000 series plus a vulnerability-handling standard and ETSI vertical/product-specific standards — are still being finalised under standardisation request M/606; treat them as emerging, not settled.

Two quick questions

Does it apply to me?

1

Does your product run software or connect to anything (USB, Wi-Fi, Bluetooth, an app, a cloud service)?

2

Is it sold in the EU — even built into someone else's product?

If you answered yes to both, the CRA almost certainly applies. The big question is which category — and that changes how much work you face. Let's find out ↓

The centrepiece

The Annexes, explained

People panic about "the annexes." They're just the different parts of the law. Here's each one in plain English — tap any card for the engineering detail.

Annex I · Core

The security rulebook

The actual security your product must have, plus how you must deal with problems found after launch. This is the heart of the CRA.

For engineers

Part I — essential product requirements: secure-by-design/default, no known exploitable vulnerabilities at release, a secure update mechanism, data confidentiality/integrity, minimised attack surface, protection of essential functions.

Part II — vulnerability handling: maintain an SBOM, coordinated vulnerability disclosure, issue security updates without delay, test & remediate. This is where most of the engineering work lives.

Annex II

What you must tell the user

The information and instructions that have to ship with the product.

For engineers

Manufacturer identity & single point of contact, product identification, intended use, where to find the declaration of conformity and SBOM, the security-update support period, and secure-decommissioning guidance.

Annex III · Important

'Important' products (extra scrutiny)

A list of riskier product types that face stricter checks. Split into Class I and a higher-risk Class II.

For engineers

Class I — e.g. identity/access & privileged-access management, password managers, standalone & embedded browsers, VPNs, network management, routers/switches/modems, SIEM, boot managers, PKI, smart-home assistants, smart locks/cameras/alarms, and MCUs/MPUs/FPGAs with security-related functions.

Class II (higher risk) — e.g. operating systems, hypervisors, firewalls (hardware & software), industrial intrusion-detection/prevention, tamper-resistant microprocessors, container runtimes, data diodes.

A 2026 Implementing Regulation adds precise technical descriptions of these categories.

Annex IV · Critical

'Critical' products (top tier)

The most security-critical products — these may need formal EU certification.

For engineers

E.g. hardware devices with security boxes, smart-meter gateways, smartcards / secure elements, Hardware Security Modules (HSMs). May require a European cybersecurity certificate at assurance level "substantial"+ once schemes exist; otherwise follow the Class II route.

Annex V

The Declaration of Conformity

The official "we comply" statement and what must be in it.

For engineers

Product ID, manufacturer details, statement of sole responsibility, standards/specs applied, notified-body info where relevant, signature.

Annex VI

Simplified Declaration of Conformity

A short-form version of that statement.

For engineers

Minimal wording plus a URL to the full DoC.

Annex VII

The Technical Documentation

The evidence file that proves you actually did the work.

For engineers

Product description, design/development/production info, risk assessment, standards applied, test reports, SBOM, and vulnerability-handling procedures — kept available for market-surveillance authorities.

Annex VIII

How conformity is assessed

The procedure you follow to earn the CE mark — self-check versus an outside assessor.

For engineers

Module A (internal control / self-assessment), Module B (EU type-examination) + Module C, Module H (full quality assurance). The route allowed depends on the product class.

2-minute check

Which CRA category is my product?

Answer five quick questions. We'll show your likely category, the obligations that apply, your key dates, and how we'd help — no email required to see the result.

Question 1 of 5
See the engineering

Secure boot: with vs without the CRA

This is what "build it secure" actually means on a device. Flip the switch, try to flash different firmware, and watch what the device accepts.

Firmware image to flash

Mode: no checks. Anything you flash will be accepted.

MCU idle FW Signature Version Integrity
Choose an image and press “Try to flash firmware”.

…and after launch: the vulnerability pipeline

Annex I, Part II in motion — and the reporting duty that starts 11 Sep 2026.

  1. Components → SBOM
  2. Matching CVE found
  3. Security update issued
  4. Reported to ENISA ≤24h
From the law to the work

How we help

Four focused services. Each one is tagged with the annex it answers — so you can see exactly how the law maps to the work.

CRA Gap Assessment

Where you stand vs. what's required, with a prioritised action list.

Scopes Annexes I, VII, VIII

Secure-by-Design Firmware

Secure boot, signed/encrypted OTA updates, anti-rollback, hardened configuration.

Annex I, Part I

Vulnerability Handling & Reporting Readiness

SBOM pipeline, coordinated disclosure process, update strategy, and readiness for the Sep 2026 reporting duty.

Annex I, Part II

Technical File & Declaration

We prepare your technical documentation and conformity paperwork.

Annexes II, V, VI, VII

Specialists in embedded and industrial/OT products (Modbus, CAN, RS-485, BLE, STM32). We understand the device — not just the checklist.

Who you'll work with

You'll work directly with our engineers

Approachable and hands-on — and always happy to get into the technical detail with you.

Jeshwanth N G

Embedded Systems Engineer

15+ years in firmware, industrial automation, and IoT — secure bootloaders, signed firmware updates, SBOMs, and the protocols real industrial products run on (Modbus, CAN, RS-485, BLE).

Ramachandra Gowda

Director

Leads KnoDTec with 20+ years of experience — a strong technical mind who stays close to the engineering and digs into the hard problems right alongside the team.

  • Secure Boot
  • SBOM
  • STM32
  • FreeRTOS
  • Modbus/CAN
  • BLE
  • PCB
Calm answers

Common questions

Does this apply to open source?

Non-commercial open source developed outside a commercial activity is largely outside the CRA. But once open-source software is integrated into a commercial product, the manufacturer placing that product on the market carries the obligations. A lighter set of duties applies to "open-source software stewards." If you ship OSS inside a product you sell, plan for it.

I sell components, not finished products — am I affected?

Quite possibly. A component with digital elements (an MCU module, a connectivity stack, a sub-assembly) can be a "product with digital elements" in its own right. And increasingly your customers will require CRA evidence — an SBOM, a security-update commitment — before they design you in. Being ready is becoming a sales requirement, not just a legal one.

What happens at the September 2026 date?

From 11 Sep 2026, manufacturers must report actively exploited vulnerabilities and serious incidents through ENISA's single reporting platform, on tight timeframes (a 24-hour early warning). This duty applies even before the full rules land in December 2027 — so a reporting process is the first thing to put in place.

We're outside the EU — does it matter?

If your product reaches the EU market — directly, through a distributor, or embedded in someone else's product sold in the EU — the CRA applies. Where you're based doesn't change that. Many non-EU makers feel it first through customers who demand compliance down the supply chain.

Is KnoDTec a notified body? Can you certify us?

No — and that's an honest, important distinction. We provide the technical readiness and implementation: secure firmware, SBOM and vulnerability processes, and the technical file. Formal third-party conformity assessment for higher-risk classes is carried out by accredited notified bodies. We get you ready for them and work alongside that process.

Get a tailored plan

Tell us about your product — get a tailored CRA readiness plan

We only use your details to reply to your enquiry. No spam, no sharing, no newsletter.