CRA Applicability Check: Does Your Product Fall Under the Cyber Resilience Act?

Does the Cyber Resilience Act apply to your product? Assess the concrete hardware or software product, its intended or reasonably foreseeable data connections, its availability on the EU market and any specific exclusions. Then determine your role, the product’s core functionality and the conformity route. Updated: 8 September 2026. Article 14 reporting starts on 11 September 2026; the main product requirements apply from 11 December 2027, subject to the transition rules.

This guide provides a systematic four-step applicability assessment that takes you from "does the CRA apply to my product?" to "what exactly do I need to do?" — with concrete examples for every product category.

Step 1: Is It a Product with Digital Elements?

The CRA defines a "product with digital elements" as any software or hardware product whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. This definition has three key components that determine applicability:

The Digital Element

The definition covers software and hardware products, their remote data processing solutions, and components placed on the market separately. Do not make the assessment depend solely on whether firmware is present: assess the electronic system’s ability to process, store or transmit digital data and the connection test in Article 2. A purely mechanical product without digital elements does not meet this definition.

The Connection Requirement

Assess whether a direct or indirect logical or physical data connection forms part of intended or reasonably foreseeable use. Relevant interfaces can include:

• Physical connections: Ethernet, USB, serial ports, HDMI with data capabilities
• Wireless connections: WiFi, Bluetooth, Zigbee, Z-Wave, cellular (4G/5G), LoRaWAN, NFC
• Logical connections: APIs, SDKs, drivers that enable communication with other software or services
• Indirect connections: Products that connect through a hub, gateway, or intermediary device

A service port requires a documented assessment of intended and reasonably foreseeable use. Record who can enable it, how it is used and what data it exchanges. Being disabled during normal operation does not, by itself, establish an exclusion; a purely theoretical connection is not a substitute for the legal use test either.

In-Scope Examples

• Smart home devices: Thermostats, door locks, cameras, lighting systems, voice assistants
• Consumer electronics: Smart TVs, connected speakers, gaming consoles, fitness trackers, smartwatches
• Enterprise software: ERP systems, CRM platforms, development tools, database management systems
• Network equipment: Routers, switches, firewalls, access points, VPN appliances
• Industrial products: PLCs with network interfaces, industrial sensors, SCADA components, connected meters
• Standalone software: Operating systems, browsers, office suites, mobile apps, desktop applications
• Software components: Libraries and SDKs distributed as standalone products for integration

Out-of-Scope Examples

• Purely mechanical or analog products without digital elements; the absence of firmware alone does not establish an exclusion for electronic hardware.
• Standalone SaaS services as such, provided they do not constitute a remote data processing solution of an in-scope product. Browser access alone is not a sufficient test; map the product and its cloud-dependent functions.
• Specific products covered by Regulations (EU) 2017/745, 2017/746 or 2019/2144; products certified under Regulation (EU) 2018/1139; and equipment within Directive 2014/90/EU. These are product-specific tests, not blanket exclusions for entire industries.
• Free and open-source software supplied outside a commercial activity. Assess the actual distribution and monetisation model; optional paid support alone does not make the software commercially supplied. Open-source software stewards have a separate regime.
• Products developed or modified exclusively for national security or defence purposes, and products specifically designed to process classified information.
• Products developed exclusively for research and development purposes that are not placed on the market

Step 2: Is the Product Placed on the EU Market?

The CRA applies when a product is "made available on the market" — meaning it is supplied for distribution, consumption, or use on the EU market in the course of a commercial activity, whether for payment or free of charge.

This has important implications:

• Digital distribution can constitute EU market availability. Assess whether the offer targets the Union market, the supply arrangements and the commercial context. Mere technical accessibility of a website from the EU is not sufficient on its own.
• A zero price does not automatically exclude a product. Check the concrete business model and distinguish a commercial edition from a genuinely non-commercial free and open-source product.
• Non-EU manufacturers can have CRA obligations when their products are supplied on the Union market. An importer’s duties do not replace the manufacturer’s duties. Article 18 allows a manufacturer to appoint an authorised representative; it does not itself impose a universal mandatory appointment.
• B2B products are included: The CRA applies regardless of whether the buyer is a consumer or a business

Bespoke software supplied to a single business customer can be in scope: a custom contract is not a general exclusion. A genuinely internal tool that is not supplied on the Union market may fall outside the market-availability criterion. Assess later supply to customers, partners or other legal entities separately and record which party markets the product under its name.

Step 3: What Product Category?

If your product is in scope (Steps 1 and 2), the next question is: which risk category applies? The category determines the conformity assessment path — and the associated effort and cost.

Default Category (Self-Assessment)

The default category covers products whose core functionality does not match a category in Annex III or IV. Module A internal control is available, alongside other permitted routes. The manufacturer must demonstrate conformity with Annex I and prepare the required documentation, declaration and CE marking. Integrating a listed component does not by itself place the complete product in that component’s category.

Important Products — Class I (Self-Assessment or Third-Party)

Listed in Annex III, Part I. These are products with higher security significance:

• Identity management systems and privileged access management software
• Standalone and embedded browsers
• Password managers
• VPN software and hardware
• Network management systems
• Security information and event management (SIEM) systems
• Boot managers and BIOS/UEFI firmware
• Operating systems
• Routers and modems intended for internet connection
• Microcontrollers with security-relevant functionality

Conformity route: Module A may be available when the relevant harmonised standards, common specifications or qualifying European cybersecurity certification schemes under Article 27 are properly applied. Otherwise, Article 32(2) generally requires Module B plus C or Module H. Also check the free and open-source software rule in Article 32(5).

Important Products — Class II (Article 32 Routes)

Listed in Annex III, Part II. Products with the highest security impact short of critical:

• Firewalls and intrusion detection or prevention systems
• Hypervisors and container runtime systems
• Tamper-resistant microprocessors
• Tamper-resistant microcontrollers
• A smart meter is not automatically Class II; check its core functionality and the specific smart-meter gateway category in Annex IV.
• Industrial deployment alone does not establish Class II classification.
• Connected sensors and robot components require their own core-function assessment against the listed categories.

Conformity route: Module B plus C, Module H, or an available and applicable European cybersecurity certification scheme meeting Article 32(3). Article 32(5) permits other Article 32(1) routes, including Module A, for qualifying free and open-source products in Annex III if their technical documentation is publicly available when placed on the market.

Critical Products — Annex IV

Listed in Annex IV. Currently a very narrow category:

• Hardware devices with security boxes, as specified by the applicable technical description
• Smartcards or similar devices, including secure elements
• Smart-meter gateways within smart metering systems and other devices meeting the Annex IV gateway description

Conformity route: mandatory European cybersecurity certification depends on the delegated act and conditions under Article 8(1). Where those conditions are not met, Article 32(4) points to the routes in Article 32(3). Do not treat the existence of a certification scheme alone as a universal certification mandate.

Step 4: What Are Your Obligations?

Once you know your product category, the obligations fall into place:

All Categories (Universal Obligations)

• Meet the applicable Annex I requirements on the basis of the product’s documented cybersecurity risk assessment, including secure defaults, access protection, update capability and attack-surface reduction.
• Establish vulnerability handling process with coordinated disclosure policy
• From 11 September 2026, Article 14 requires reporting of actively exploited vulnerabilities and severe incidents affecting product security to the coordinating CSIRT and ENISA through the prescribed mechanism. Initial stages include a 24-hour early warning and a 72-hour notification; the later report depends on the trigger.
• Prepare a machine-readable SBOM covering at least top-level dependencies. The CRA does not impose a general obligation to publish the SBOM publicly.
• Determine and document the support period under Article 13: generally at least five years, unless expected use is shorter, and potentially longer where justified by expected use. Security updates are generally free; Annex I Part II point 8 includes an agreement-based exception for tailor-made products supplied to a business user.
• Prepare technical documentation (Annex VII)
• Prepare EU declaration of conformity
• Affix CE marking
• Retain the technical documentation and EU declaration for ten years after placing on the market or for the support period, whichever is longer.

Additional for Class I

• Document the route selected under Article 32(2), including relevant standards, common specifications or qualifying certification, and assess Article 32(5) where applicable.
• More rigorous documentation of conformity assessment methodology

Additional for Class II and Critical

• Select the applicable route under Article 32(3)–(5) and Article 8; engage a notified body where the selected or required procedure calls for one.
• Provide the notified body with full access to technical documentation, source code (where required), and testing infrastructure
• Maintain ongoing relationship with notified body for product updates that affect conformity

Practical Examples: Applying the Decision Tree

Example 1: Enterprise SaaS with Desktop Client

Illustrative case: a project-management product combines a desktop client with cloud synchronisation. The client can be an in-scope software product. If the manufacturer develops the cloud software, or has it developed under its responsibility, and the product could not perform a function without it, that remote processing belongs to the product assessment. Do not restrict the review to the client. A separate standalone web service needs its own scope assessment; classification depends on core functionality.

Example 2: Industrial IoT Sensor

Illustrative case: a temperature sensor with Bluetooth is sold to EU industrial customers. Its intended data connection and commercial supply support CRA scope, absent a specific exclusion. Industrial use does not automatically make it Class II. If temperature measurement is its core function and no Annex III or IV category applies, the default category may be appropriate. Record the product boundary and classification rationale before selecting Module A or another permitted route.

Example 3: Open-Source Library Published on npm

Illustrative case: a freely licensed JavaScript utility library is supplied without commercial activity. Check the actual monetisation and distribution model, rather than relying on the licence or the developer’s legal form alone. Separately offered optional paid support is not by itself decisive. A manufacturer integrating the library into a commercial product must exercise due diligence and address the security of the complete product; the upstream actor’s own role must be assessed separately.

Example 4: Network Firewall Appliance

Illustrative case: a network appliance whose core function is a firewall falls within Class II in Annex III, not Class I. Assess Module B plus C, Module H or an applicable qualifying certification route under Article 32(3); check any relevant Article 32(5) exception. Article 14 reporting begins on 11 September 2026, including for covered existing products.

Example 5: Mobile Banking App

Illustrative case: a banking app includes customer login. That authentication feature does not automatically make identity management the product’s core function. Assess the app’s actual core functionality and technical description against Annex III and IV, along with its manufacturer-controlled remote processing. The presence of a listed component alone does not determine the whole product’s class.

The SaaS Trap: CRA vs. NIS2

The CRA expressly includes a product’s qualifying remote data processing solutions. Standalone cloud services are a different assessment. Test whether the remote software is designed and developed by or under the manufacturer’s responsibility and whether its absence prevents a product function. Hardware is not required: a software product can also have remote processing.

• CRA scope follows the defined product, including qualifying remote data processing; it does not automatically extend to the manufacturer’s entire IT environment.
• NIS2 scope is assessed separately at entity level under the applicable national rules, considering activities, size and relevant exceptions.
• Delivering SaaS and downloadable software can create overlapping regulatory questions, but it does not automatically establish that both CRA and NIS2 apply.

The practical takeaway: do not assume SaaS exemption from all cybersecurity regulation. Map your product architecture against CRA scope AND your organization against NIS2 scope.

A scope record your product team can complete

1. Product boundary: record product and version, separately supplied components and an architecture diagram. Identify each cloud-dependent function and who designs and develops the remote software.

2. Market and role: identify the legal manufacturer, importer and distributor, the name under which the product is marketed, first EU market placement, and the licensing, payment and distribution model. Include bespoke software supplied to a single customer.

3. Legal rationale: record the connection and use test, the exact provision supporting any exclusion, and the core-function comparison with Annex III/IV and the technical descriptions in Implementing Regulation (EU) 2025/2392. Cite the supporting document and section.

4. Decision and action: classify the result as in scope, out of scope with reasons, or unresolved. Record the conformity route, market-placement date, substantial-change assessment, Article 14 reporting readiness, decision owner and review date. An unresolved question is not a confirmed exclusion.

For an ADVISORI enquiry, prepare the product group, business model, architecture and your main unresolved question. These inputs help determine whether the next step is a scope assessment, detailed classification or a technical gap analysis; timing depends on portfolio complexity and available evidence.

Sources and review date

Reviewed on 8 September 2026. The regulation is binding; Commission guidance and FAQs support interpretation and do not replace assessment of the actual product.

Regulation (EU) 2024/2847: scope, classification, reporting and transition rules

Commission guidance of 27 July 2026 (C(2026) 5252)

Commission FAQ, version 1.4 of 4 September 2026

What to Do Next

1. Prioritise the product inventory and Article 14 reporting readiness for 11 September 2026, including covered existing products. Assign an owner and deputy for assessing reportable events.
2. For each in-scope product, classify the risk tier (default, Class I, Class II, critical) based on Annex III and IV
3. Prioritise products by reporting exposure, planned market dates, technical gaps and conformity route. Where third-party assessment is required, include external assessment capacity in the plan.
4. Validate the 24-hour and 72-hour reporting workflow before 11 September 2026, including trigger assessment, decision ownership and the prescribed reporting mechanism.
5. Begin SBOM generation for all products — this is foundational for both conformity assessment and vulnerability management
6. Engage legal counsel for borderline cases, especially SaaS/on-device hybrid products and products that may be covered by both the CRA and sector-specific regulation

Frequently Asked Questions

Our product is sold globally — can we ignore the CRA?

An EU market connection can bring a non-EU manufacturer into scope. Assess targeted supply and the commercial model; website accessibility alone does not settle the question. Identify manufacturer, importer and distributor separately. Article 18 permits appointment of an authorised representative but is not a blanket mandatory-appointment rule.

We use third-party components — who is responsible for their CRA compliance?

The final-product manufacturer is responsible for the security of the complete product and must exercise due diligence when integrating third-party components. Not every discovered vulnerability triggers Article 14: assess active exploitation or a qualifying severe incident. Coordinate remediation and disclosure with the component provider; the provider may also have obligations depending on its own role and product.

How do I classify a product that spans multiple categories?

Start with the complete product’s core functionality, then compare it with Annex III and IV and the technical descriptions in Implementing Regulation (EU) 2025/2392. Integrating a listed component does not by itself change the complete product’s class. A router with a genuine firewall core function requires assessment against the Class II firewall category; a routine login feature does not automatically turn an unrelated application into an identity-management product. Record unresolved multi-function cases explicitly.

What if harmonized standards are not yet published for my product category?

For default products, Module A does not require a harmonised standard. For Class I, Article 32(2) also recognises common specifications and qualifying European certification schemes, subject to the relevant conditions. If these conditions are not met, Module B plus C or Module H is generally required. Article 32(5) provides an additional rule for qualifying free and open-source Annex III products with public technical documentation.

Is a product sold before December 2027 exempt from the CRA?

Article 69(2) contains a transition rule: products placed on the market before 11 December 2027 are generally subject to the other CRA requirements only if substantially modified after that date. Article 69(3) expressly preserves Article 14 reporting for covered existing products from 11 September 2026. Distinguish existing units from units first placed on the market later, and assess software versions and substantial changes using the Commission guidance.

Does the CRA apply to internal tools we build for our own use?

A genuinely internal tool not made available on the Union market may fall outside the market-availability criterion. Document the legal entity and actual use. Later commercial supply, including free supply in a business context, needs reassessment. Custom software supplied to a single customer is not automatically exempt.