Cyber Resilience Act: Am I Affected?

The Cyber Resilience Act (Regulation (EU) 2024/2847) has been in force since 10 December 2024. The first hard deadlines take effect on 11 September 2026 — reporting obligations for actively exploited vulnerabilities and severe security incidents. Full product requirements must be met by 11 December 2027. The critical question for every company is therefore: Am I subject to the CRA?

The answer depends on three factors: your role in the supply chain, the nature of your product, and the market on which you operate. This article walks you through the assessment steps systematically.

Step 1: What is your role in the supply chain?

The CRA addresses three distinct roles. Your obligations differ significantly depending on which role applies — so clarifying your role is the first and most important step.

Manufacturer

A manufacturer is typically any person who develops or has a product with digital elements developed and places it on the EU market under their own name or brand. It makes no difference whether the product is free of charge or sold commercially — freely available software also falls within scope if it is made available in the context of a commercial activity. Manufacturers bear the most extensive obligations: security by design, vulnerability handling, SBOM, technical documentation, CE marking, and reporting duties.

Importer

Importers bring products with digital elements from third countries into the EU. They must verify that the manufacturer has fulfilled their CRA obligations before placing the product on the market. Importers may become liable if they bring a non-compliant product into circulation.

Distributor

Distributors make products available on the EU market without making substantial modifications. Their obligations are lighter than those of manufacturers and importers — but they generally have to verify that the product bears the CE marking and that the manufacturer is identifiable.

Important: Anyone who relabels a product under their own name or makes substantial modifications is typically treated in law as a manufacturer — even if the original development took place elsewhere. This situation frequently arises with white-label products and OEM arrangements.

Step 2: Is it a "product with digital elements"?

The CRA applies to products with digital elements — hardware and software products, and related remote data processing solutions, that have a direct or indirect logical or physical data connection to a device or network.

This definition is intentionally broad. In practice, it typically covers:

• Proprietary software products (desktop, mobile, web applications) marketed as standalone products
• Embedded software and firmware in hardware products
• Network devices (routers, switches, firewalls)
• IoT devices with network connectivity
• Industrial control systems with digital interfaces
• Security products (VPN clients, antivirus software, password managers, PKI components)
• Cloud services directly linked to a physical product (remote data processing solutions)

Pure SaaS services without a product-bound component do not fall directly within the CRA's scope — however, they may be captured as part of a broader product (remote data processing solution). Hybrid offerings warrant careful delineation.

Step 3: Does an exception apply?

Certain product categories are not subject to the CRA because they are already covered by equivalent sector-specific regulations. These exceptions should be understood as boundary markers — they concern specific, already-regulated industries:

• Medical devices under the MDR (Regulation (EU) 2017/745) and IVDR (Regulation (EU) 2017/746)
• Motor vehicles subject to the EU type-approval regulation
• Aviation products covered by the EASA Regulation (EU) 2018/1139

If your product falls into one of these categories, sector-specific law — not the CRA — typically governs the relevant cybersecurity aspects. However, if you develop software products sold to regulated industries but not themselves covered by sector regulation, the CRA generally remains applicable.

Open-source software considerations

Open-source stewards (foundations and comparable organisations that provide open-source software without commercialising it) are exempt from the CRA's penalty provisions. Companies that integrate open-source components commercially into their own products are, however, generally liable as manufacturers — particularly for vulnerability handling of those components.

Considerations for micro and small enterprises

The CRA contains no general size-based exemption: SMEs are subject to the same requirements as large enterprises. Micro and small enterprises do benefit from targeted easements in specific areas — for instance, in relation to certain aspects of reporting obligations and sanctions. This does not exempt them from the core product requirements or the reporting obligations taking effect in September 2026. For concrete action steps tailored to mid-sized companies, see our CRA page for SMEs.

Step 4: A systematic assessment framework

The following four questions provide a rapid orientation framework. They do not replace a legal assessment of your individual situation, but they offer a sound initial indication.

1. Role: Are you placing a product on the EU market under your own name, importing a product from a third country into the EU, or making a product available without substantially modifying it?
2. Product type: Does your product have a direct or indirect connection to a network or another device?
3. Exception: Is your product already subject to sector-specific EU regulation with equivalent cybersecurity requirements (MDR, IVDR, vehicle type-approval, aviation)?
4. Market: Is the product made available on the EU market — regardless of where your company is established?

If you answer Yes to questions 1, 2, and 4, and No to question 3, it is likely that your product typically falls within the scope of the CRA. For a more granular assessment of your specific situation, you can use our interactive CRA check.

What follows from being in scope?

Once it is established that the CRA applies to your product, the specific obligations depend on the product class. The CRA distinguishes:

• Default products — self-assessment by the manufacturer (Module A)
• Important products Class I (Annex III) — self-assessment only under specific conditions (application of harmonised standards or an EU cybersecurity certification scheme); otherwise third-party assessment by a notified body
• Important products Class II (Annex III) — involvement of a notified body always mandatory
• Critical products (Annex IV) — mandatory EU certification scheme or notified body in every case

A detailed explanation of product classes and the corresponding conformity assessment procedures is available in the article CRA Product Classes: Default, Class I/II and Critical.

The first hard deadline: September 2026

Regardless of product class, all affected manufacturers are subject to reporting obligations from 11 September 2026: actively exploited vulnerabilities and severe security incidents must be reported within 24 hours (early warning), within 72 hours (full notification), and — depending on the type of event — with a final report within 14 days (vulnerabilities, once a corrective measure is available) or one month (severe incidents). Reports are submitted via the CRA Single Reporting Platform (SRP), operated by ENISA; notifications are made to the relevant CSIRT and made available to ENISA.

This means that even though full product requirements only apply from late 2027, the necessary processes and internal structures (PSIRT, escalation paths, documentation requirements) must be in place before September 2026. Full details on timelines and operational requirements are available in the article CRA Reporting Obligations from 11 September 2026.

Scope confirmed — what next?

The next step after confirming that the CRA applies is a structured gap analysis: where does your product stand today relative to CRA requirements — in security by design, vulnerability handling, SBOM, and technical documentation? The SBOM obligation in particular is frequently underestimated in practice. Detailed requirements and format specifications (CycloneDX, SPDX, TR-03183-2) are explained in the article SBOM Requirements under the CRA.

Blackfort Technology supports manufacturers of digital products in structured CRA preparation — from scope analysis and gap assessment through to the implementation of reporting processes and SBOM infrastructure. Christian Gebhardt, Managing Director and co-author of the ACS/BSI guidance on pentesting LLMs and member of the ACS AI working group, brings hands-on implementation experience from PKI, DORA, NIS2, and ISMS engagements.

All CRA obligations at a glance — or go straight to the interactive CRA check.