Is Your Embedded Product in CRA Scope?

The EU Cyber Resilience Act (Regulation EU 2024/2847) has been in force since December 2024. Vulnerability reporting obligations begin 11 September 2026, with full enforcement from 11 December 2027. If you build embedded products that touch the EU market in any way, the clock is running.

The first question every product team needs to answer isn't about SBOM formats or vulnerability disclosure timelines. It's simpler: does the CRA even apply to us?

Getting this wrong in either direction is expensive. Assume you're out of scope when you're not, and you're exposed to fines of up to €15 million or 2.5% of global turnover. Over-scope your assessment and you'll waste engineering cycles on conformity activities that aren't required.

This post gives you a structured decision framework based on the actual CRA text.

What the CRA Covers: The "Products with Digital Elements" Definition

Article 2(1) sets the scope:

The Regulation applies to products with digital elements whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.

Article 3(1) defines a product with digital elements as any software or hardware product, and its remote data processing solutions, intended for use with a data connection to a device or network.

Two things jump out immediately:

1. Both hardware and software are in scope. A firmware image sold separately from the hardware it runs on is a product with digital elements.
2. The connection can be indirect. A device that doesn't itself connect to the internet but connects to a gateway device that does is still in scope.

The Direct vs. Indirect Connection Grey Area

This is where most embedded teams get caught. Article 3(1) and Recital 14 clarify what "indirect" means in practice.

Direct connection examples:

• Wi-Fi, Bluetooth, Ethernet, cellular (LTE/5G), Zigbee, Thread, Z-Wave connected devices
• USB-connected devices that expose a network interface (e.g., a USB NIC)

Indirect connection examples:

• A sensor node that communicates only via a proprietary RF protocol to a hub—the hub connects to the internet. The sensor is indirectly connected.
• A motor controller that receives commands from a PLC, which in turn has a SCADA uplink. The controller is indirectly connected.
• A Bluetooth peripheral (headset, HID device) that pairs with a smartphone. The peripheral has an indirect internet connection via the phone.

The practical test: Could data flow from your device to a network or from a network to your device, even through one or more intermediary devices? If yes, you're likely in scope.

Recital 12 specifically notes that products connecting to other products rather than directly to networks are still covered "where such products were intended or could reasonably be expected to be connected to a network."

What's Explicitly Out of Scope

Article 2(2) lists explicit exclusions. The most relevant for embedded teams:

Medical Devices

Products regulated under Regulation (EU) 2017/745 (MDR) or 2017/746 (IVDR) are excluded. Those regulations have their own cybersecurity requirements under MDCG guidance.

Aviation

Products covered under Regulation (EU) 2018/1139 (EASA framework) are excluded.

Automotive

Motor vehicles under Regulation (EU) 2019/2144 are excluded. Note this refers to the vehicle-level regulation; embedded components supplied into the automotive sector may still need CRA compliance if sold commercially outside the automotive type-approval chain.

National Security and Defence

Products intended exclusively for defence, national security, or classified information are out of scope.

Offline Products

Here is where many teams make a mistake. There is no blanket offline exemption. Article 2(2)(h) excludes only:

Products with digital elements developed or modified exclusively for national security or defence purposes, or specifically designed to process classified information.

A general-purpose industrial controller that happens to be deployed offline is still in scope if it's a commercially available product with the capability for data connection, even if a specific deployment doesn't use it.

The relevant test is intended purpose and reasonably foreseeable use, not actual deployment configuration. If your product's datasheet lists a Modbus TCP port, or your firmware includes an Ethernet driver, market surveillance authorities may treat that as evidence of connectivity capability.

When offline products are genuinely out of scope:

• The product physically cannot connect (no hardware interfaces, no radio, no comms stack in firmware)
• The intended purpose explicitly excludes any data connection
• The reasonably foreseeable use wouldn't involve network connectivity

If you're removing a Wi-Fi module from a product to try to get out of CRA scope, you need legal advice before proceeding—regulators are aware of this approach and the CRA's "reasonably foreseeable use" language was written to address it.

The Open Source Software Question

Recital 18 and Article 2(3) address open source software. OSS released free of charge and not commercially exploited by its developer is out of scope. However, if a company monetises OSS (through commercial support, SaaS delivery, or integration into a commercial product), it falls within scope.

For embedded product teams, this is almost always moot—if you're shipping a product with embedded software, you're a manufacturer, and the software inside that product is subject to CRA regardless of its licensing.

OEM and Component Manufacturer Liability

This is the area of greatest confusion, and the CRA text is more nuanced than many summaries suggest.

Article 13: Manufacturer Obligations

Article 13 establishes that manufacturers bear primary responsibility for CRA compliance. A manufacturer is defined in Article 3(13) as "a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets those products under their name or trademark."

Key implications:

• If you put your brand on a product, you are the manufacturer under the CRA, even if you didn't write the firmware
• If you have firmware written by a third party and white-label it, you're the manufacturer
• You can't contractually transfer manufacturer status to your ODM or firmware vendor

Supply Chain Obligations

The CRA addresses supply chain responsibilities across several articles. Article 13 establishes the core manufacturer obligations, which include ensuring that components integrated into your product meet the essential requirements. Article 20 specifically covers distributor obligations (due diligence, CE marking verification, corrective measures for non-compliant products), while Article 19 covers importers.

For component integration, the key provisions are in Article 13 and the essential requirements themselves. When a manufacturer integrates a component (hardware or software) into a product, the integrating manufacturer is responsible for:

• Ensuring the component meets CRA essential requirements as part of the overall product
• Having a process to receive vulnerability notifications from component vendors
• Passing security updates through to your customers

The integrating manufacturer is not exempted from responsibility by using third-party components. If your product includes third-party firmware components (e.g., a cellular module with proprietary stack, a Wi-Fi chipset with vendor firmware, a Bluetooth SoC with closed-source BLE stack), you need contractual security commitments from those vendors.

The Integrator vs. Manufacturer Distinction

One important nuance: Article 3(13) distinguishes manufacturers from importers (Article 3(20)) and distributors (Article 3(21)). If your company only imports and resells products without modification, different rules apply (Article 19 for importers). But if you modify firmware, add features, or rebrand the product, you become the manufacturer.

A Practical Decision Framework

Work through these questions in order:

Step 1: Is it a product with digital elements?

Does your product have any of the following?

• A network interface (Ethernet, Wi-Fi, cellular, Zigbee, Thread, Z-Wave, LoRa, BLE, etc.)
• A wired serial interface that could connect to a networked device (RS-485, CAN, Modbus, EtherCAT, PROFINET)
• A USB port or interface
• Any RF capability

If no to all of the above and the firmware has no networking stack: likely out of scope. Document this assessment.

If yes to any: proceed to Step 2.

Step 2: Is it sold or placed on the EU market?

The CRA applies to products placed on the EU market. If you sell only in the US, Japan, or other non-EU markets and have no plans for EU sales, the CRA doesn't apply. However:

• If your distributors sell into the EU, you're on the EU market
• If your end customers are based in EU countries, you're on the EU market
• If a European B2B customer uses your product internally (even without resale), it may still be "placed on the market" depending on the commercial arrangement

If you're not on the EU market now but have EU expansion plans: start your CRA compliance programme now, as the timeline to December 2027 is not long for embedded firmware teams.

Step 3: Does an explicit exemption apply?

Check the Article 2(2) exclusion list:

• Medical device under MDR/IVDR?
• Aviation product under EASA regulation?
• Automotive vehicle under EU 2019/2144?
• National security / defence product?

If yes to any: consult the applicable sectoral regulation for its cybersecurity requirements.

Step 4: What's your role?

• Manufacturer (you design/build/brand the product): full CRA obligations under Article 13
• Importer (you import and sell a third-party product under your name): Article 19 obligations
• Distributor (you resell without modification): Article 22 obligations (lighter, but you must verify the manufacturer has a CE mark and compliant declaration)
• Component supplier (you supply a module or software that others integrate): Article 20 obligations

Most embedded product companies are manufacturers or importers with full Article 13 obligations.

What Comes Next If You're In Scope

If your product is in scope, your next steps are:

1. Classify your product — Default (self-certify), Class I (third-party audit), or Class II (notified body). This depends on Annex III product lists. (See our post on CRA product classification.)
2. Gap-assess against Annex I — The essential requirements cover secure design, vulnerability handling, security updates, SBOM, and technical documentation. Our Annex I essential requirements checklist maps every requirement to concrete firmware engineering tasks.
3. Implement secure boot — Annex I requires firmware integrity protection. For MCU-based products, this means a verified boot chain with code signing. (See our post on CRA secure boot and firmware signing.)
4. Set up vulnerability reporting — Article 14 requires a 24-hour initial notification to ENISA for actively exploited vulnerabilities, with a 72-hour follow-up. (See our post on Article 14 vulnerability reporting.)
5. Generate an SBOM — Annex I Part II requires a machine-readable SBOM of all components. For firmware teams, this means integrating SBOM generation into your build system. (See our post on CRA-compliant firmware SBOMs.)
6. Prepare the technical documentation and EU Declaration of Conformity — Required before placing the CE mark.

The scope analysis is the foundation everything else builds on. If you're uncertain, use the Stack Canary assessment tool — it will classify your product and identify your specific gaps in about 2 minutes.

This post is based on the final text of Regulation EU 2024/2847. It does not constitute legal advice. The CRA harmonized standards are still being developed by CEN/CENELEC; consult qualified legal counsel for definitive compliance guidance.

Sources

• Regulation (EU) 2024/2847 — Cyber Resilience Act (full text)
• European Commission — Cyber Resilience Act summary
• CRA full text (HTML) — see Articles 2, 3, 13, 19, 20
• CRA full text (PDF)