Does the Cyber Resilience Act apply to companies outside the EU?

Yes. The CRA applies to products with digital elements placed on the EU market, regardless of where the manufacturer is based. A manufacturer outside the EU can appoint an authorised representative in the EU, and importers have to check that the manufacturer met its obligations. The technical requirements are the same.

When do the CRA reporting obligations start?

They have applied since 11 September 2026, including for products that were already on the market before that date. Actively exploited vulnerabilities and severe incidents are reported to the national CSIRT and ENISA through the Single Reporting Platform: an early warning within 24 hours, a notification within 72 hours and a final report afterwards.

Do we have to publish our SBOM?

The CRA requires you to draw up a software bill of materials in a commonly used, machine-readable format, covering at least the top-level dependencies, and to keep it as part of the technical documentation. Market surveillance authorities can request it. The regulation does not oblige you to publish it; many manufacturers share it with customers on request.

Which products fall under the CRA?

Products with digital elements made available on the EU market: hardware with software, connected devices, embedded systems and software sold as a product. Some sectors with their own rules, such as medical devices, motor vehicles and aviation, are excluded. Most products fall into the default category and can be self-assessed; important and critical products need stricter conformity assessment.

Is open-source software covered?

Free and open-source software that is not made available on the market in the course of a commercial activity is outside the scope. If you ship open-source components inside a commercial product, you are responsible for them as part of your product, which is exactly why the SBOM and vulnerability handling matter.

How long do we have to provide security updates?

For the support period you declare. As a rule it has to be at least five years, unless the product is expected to be in use for less time. During that period you handle vulnerabilities and provide security updates for the product.

Are you a legal advisor or a notified body?

No. Krafteq is a technical implementation partner. We build the controls and produce the technical evidence; the legal interpretation belongs with your counsel, and formal third-party assessment, where your product needs it, with a notified body.

Can you work with teams outside Germany, in English?

Yes. The engineering work happens in your pipeline and your repositories, so it runs remotely, and technical communication in English is normal for us. Written offers and contracts are in German, as is our standard for all engagements.

What is the best way to start?

With the CRA technical assessment: two to three days at a fixed price. You receive your product category, a gap analysis against Annex I and a prioritised roadmap. After that you decide what to implement yourselves and what to hand to us.

Isometric illustration of a regulated software supply chain with SBOM generation, vulnerability scanning, and compliance reporting

Cyber Resilience Act (Regulation (EU) 2024/2847)

Cyber Resilience Act Compliance for Manufacturers Selling into the EU

CRA reporting obligations have applied since 11 September 2026. Full application follows on 11 December 2027.

Since 11 September 2026, every manufacturer selling products with digital elements in the EU has to report actively exploited vulnerabilities and severe incidents: an early warning within 24 hours, a notification within 72 hours. That applies to a machine builder in Stuttgart and to a device maker in Ohio or Shenzhen alike. By 11 December 2027 the rest of the regulation follows: secure development, a software bill of materials, vulnerability handling across the whole support period, technical documentation and the CE marking. Most of that is engineering work in your build pipeline, not paperwork. That is the part krafteq builds.

11 Sept 2026 Reporting obligations apply

11 Dec 2027 Full application of the CRA

5 years Minimum support period, as a rule

Talk to an engineer about your CRA scope

We ran the CRA self-assessment on our own products first: SBOM generation (CycloneDX 1.6), vulnerability scanning and a gap analysis against Annex I and II.

Who is affectedDoes the CRA apply to you?

The regulation follows the product, not the company's address. If a product with digital elements is placed on the EU market, the CRA applies to it: hardware with firmware, connected devices, embedded controllers, desktop and mobile software sold as a product.

Manufacturers inside the EU

You design or build the product, or have it built, and sell it under your own name or trademark. You carry the full set of obligations: risk assessment, secure development, SBOM, vulnerability handling, reporting, documentation and the CE marking.

Manufacturers outside the EU

The same obligations apply as soon as your product is sold in the EU. You can appoint an authorised representative established in the EU, but the engineering evidence still has to come from your own development process.

Importers and distributors

Importers have to check that the manufacturer met its obligations before a product goes on the market. In practice they pass that pressure on: they ask their suppliers for the SBOM, the support period and a contact for vulnerability reports.

Suppliers of components

If your firmware, library or module ends up inside someone else's product, your customer needs your vulnerability information to meet their own obligations. Expect CRA questions in purchasing and supplier audits even before your own product falls under the regulation.

TimelineWhat applies when

The CRA entered into force on 10 December 2024 and applies in stages. Two dates matter most for manufacturers: reporting has already started, and the full set of requirements follows fifteen months later.

10 December 2024: entry into force

Regulation (EU) 2024/2847 was published and entered into force. From here, the transition periods run.

The clock started

11 June 2026: conformity assessment bodies

The rules for notifying conformity assessment bodies apply. This is what makes third-party assessment possible for important and critical products.

Third-party assessment becomes available

11 September 2026: reporting obligations

Actively exploited vulnerabilities and severe incidents have to be reported to your national CSIRT and ENISA through the Single Reporting Platform. An early warning within 24 hours, a notification within 72 hours, a final report within 14 days of a fix being available for a vulnerability, or within one month for a severe incident. This applies to products already on the market.

In force now

11 December 2027: full application

Every essential requirement of Annex I applies to products placed on the market: secure by design and by default, vulnerability handling, SBOM, technical documentation, conformity assessment and the CE marking.

Everything has to be in place

What it means in practiceWhere manufacturers usually get stuck

The legal text is the easy part to read. The hard part is that most requirements only hold up if they are produced automatically, with every release, by the pipeline that builds the product.

24 hours is not enough time to find out who to call

An early warning within 24 hours only works if the path is set up in advance: who decides that a vulnerability is actively exploited, who submits the report, who signs it off, and what goes into it. Without that, the first real incident becomes the rehearsal.

An SBOM that is out of date the day after release

Annex I asks for a software bill of materials in a commonly used, machine-readable format, covering at least the top-level dependencies. A one-off spreadsheet does not survive the next release. It has to be generated with every build and stored with the release it belongs to.

Vulnerability handling for the whole support period

The support period is, as a rule, at least five years. That means scanning, triage and security updates for versions that are already in the field, not only for the one under development.

Evidence scattered across tools

The technical documentation has to show how the product was designed, built and tested for security. When the evidence lives in tickets, chat threads and people's heads, putting it together for an assessment takes weeks.

Nobody owns the topic internally

Legal owns the regulation, engineering owns the pipeline, product management owns the support period. The CRA needs all three at once, and in many companies that seat is empty.

Our ApproachBuild the evidence into the pipeline

We are a technical implementation partner. We build the controls the CRA asks for into your existing CI/CD setup, so that every release produces its own evidence: an SBOM, a scan result, a record of which vulnerabilities were accepted or fixed and why.

Reporting as a prepared workflow: templates for the 24-hour, 72-hour and final reports, a clear decision path for what counts as actively exploited, named people and approvals. Written down, tested and handed to the team that will use it.

Your team keeps it running. We work alongside your engineers, document every step and hand over runbooks. If you prefer, we take over ongoing monitoring and SBOM updates as a service instead.

What we do not do: legal advice or certification. We work with your legal counsel and, where your product needs one, with a notified body. They make the legal and formal calls, and we supply the technical evidence.

ProcessFour steps from assessment to handover

Each step ends with a result you can use on its own. You can stop after any of them.

CRA technical assessment (2 to 3 days)

Gap analysis of your development process, pipeline and dependency management against Annex I. We determine the product category (default, important class I or II, critical) and the support period you can realistically commit to. You receive a prioritised roadmap.

Your scope, your category and a plan in writing

SBOM and vulnerability handling (week 1 to 2)

SBOM generation in CycloneDX or SPDX as a pipeline step, versioned per release. Scanning of dependencies, containers and code. Risk-based triage with target fix times, for example critical within 24 hours, high within 7 days, medium within 30 days.

An SBOM and a scan record for every release

Reporting workflow and secure development (week 2 to 4)

The 24h, 72h and final report workflow for the ENISA Single Reporting Platform. A coordinated vulnerability disclosure policy with security.txt and a triage process. Security gates in the pipeline: static and dynamic analysis, secrets detection. Technical documentation generated from pipeline artefacts where possible.

Ready to report, with a development process you can show

Handover or ongoing service (week 3 to 4)

Your team takes over with documented processes, runbooks and a handover workshop. Or krafteq keeps running monitoring and SBOM updates for you.

CRA work that keeps running after we leave

ServicesWhat we implement

Each item maps to a concrete CRA requirement. We start with what your assessment shows is missing, not with the full list.

SBOM generation

CycloneDX or SPDX, generated automatically in the pipeline and stored with each release. Covers at least the top-level dependencies, as Annex I requires, and usually far more.

Vulnerability handling

Automated scanning of dependencies, containers and code. Prioritisation by severity, exploitability and whether the vulnerable code is actually reachable. Target fix times per severity.

Reporting workflow

Decision path, templates and approvals for the early warning, the notification and the final report to the ENISA Single Reporting Platform.

Secure development lifecycle

Security gates in the pipeline: static and dynamic analysis, secrets detection, secure default configuration. A documented cybersecurity risk assessment for the product.

Coordinated vulnerability disclosure

A disclosure policy, security.txt, an intake channel for external reports, a triage workflow and published security advisories.

Technical documentation

The documentation required by Annex VII, assembled from pipeline artefacts and version history wherever possible, so it stays current with the product.