Applicability testEU Cyber Resilience Act

CRA applicability test for products with digital elements

Decide whether a hardware, software, firmware, connected component, or open-source release is likely in scope of the EU Cyber Resilience Act.

Work through product status, EU market availability, Article 2 exclusions, operator roles, remote data processing, and Annex III or Annex IV classification before starting conformity assessment.

Back to main artifact Review sources

Author

Sorena AI

Published

Mar 4, 2026

Updated

Jul 31, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Mar 4, 2026

Updated Jul 31, 2026

Overview

A is likely within CRA scope when it is commercially made available on the Union market, its intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network, and no Article 2 exclusion applies. Use this test to produce a cited product-by-product record showing the decisive facts, operator role, classification, applicable date, unresolved questions, and required follow-up.

Section 1

1. Is there a product with digital elements?

Start by identifying the actual product boundary. The CRA covers software or hardware products, their solutions, and software or hardware components that are placed on the market separately.

Do not stop at the device casing or the app name. A single CRA product can include hardware, embedded firmware, separately downloaded software, and manufacturer-controlled remote processing where those elements operate together to perform product functions.

Record whether the item is hardware, software, firmware, source code, a separately supplied component, or a combined hardware-software product.
List the functions the product is marketed or intended to perform, using technical documentation and user-facing materials rather than marketing labels alone.
Identify any app, API, database, cloud service, update service, identity service, or configuration portal that the product needs for one of its functions.
Keep model, version, edition, deployment mode, and sales channel separate because CRA scope and classification can differ across product variants.

Section 2

2. Does the product connect to a device or network?

Article 2 applies where the product's intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. The presence of electronics or firmware alone is not enough if the product does not exchange digital data.

For software, indirect connection can still matter. Commission FAQ examples include software that does not initiate communications itself but runs on a host operating system that connects to a network.

Describe each logical connection, such as APIs, network sockets, files, browser sessions, email protocols, or other software interfaces.
Describe each physical connection, such as USB, Ethernet, fibre, wired fieldbus, Wi-Fi, Bluetooth, NFC, or another data-carrying interface.
Separate data connections from signals that only power, charge, or trigger a function without conveying digitally encoded information.
If the product is offline on its own, document whether it is indirectly connected through a host system, larger product, deployment environment, or update mechanism.

Section 3

3. Is it made available on the Union market in commercial activity?

The CRA scope test also asks whether the product is supplied for distribution or use on the EU market in the course of a commercial activity. Products made only for the manufacturer's own use are generally not placed on the market.

Open-source status does not decide the answer by itself. Free and open-source software is assessed by asking whether it is supplied on the Union market in commercial activity; hosting code on an open repository or package manager does not, by itself, make it available on the market.

Record who supplies the product, to whom, through which channel, and whether EU distribution or use is intended or reasonably targeted.
For software and open-source releases, document whether access, binaries, updates, support, performance optimisation, monetised services, personal-data use, or donor-only benefits indicate commercial activity.
For unfinished test software, record whether it is limited to testing and visibly identified as non-compliant and not made available for other purposes.
For source code, record whether it is commercially supplied as code, or only shared as public review, tutorial, demo, or unfinished development material.

Section 4

4. Does an Article 2 exclusion remove the product from CRA scope?

Check exclusions before investing in conformity planning. Article 2 removes several product groups where other Union regimes apply or where the product is made for specific national security, defence, or classified-information purposes.

A product is not excluded merely because it can be used in a defence context. The CRA test is whether it was developed or modified exclusively for national security or defence purposes, or specifically designed to process classified information.

Check whether the product is covered by the EU medical devices or in vitro diagnostic medical devices regulations.
Check vehicle type approval, civil aviation certification, and marine equipment exclusions where the product is part of those regulated product groups.
Check whether the item is an identical spare part made to the same specifications to replace an identical component in a .
Check whether a delegated act limits or excludes the CRA because another Union framework addresses the same cybersecurity risks with an equivalent or higher level of protection.

Section 5

5. Which CRA role does each organisation have?

Applicability is also role-specific. The CRA distinguishes manufacturers, authorised representatives, importers, distributors, other economic operators, and open-source software stewards. The same company can have different roles for different products or sales channels.

The manufacturer role is broader than physical production. A business can be the manufacturer when it develops or has a product developed and markets it under its own name or trademark. Importers and distributors can also become manufacturers if they place the product on the market under their own name or trademark, or substantially modify it.

Name the legal entity marketing the product under its own name or trademark and the entity that controls product cybersecurity decisions.
For non-EU manufacturers, identify the EU-established operator performing the required market-surveillance contact tasks.
For importers, record the checks needed before placement: conformity assessment, technical documentation, CE marking, declaration of conformity, and required information and instructions.
For distributors, record the checks needed before making the product available, and note any facts that would turn the distributor or importer into the manufacturer.

Section 6

6. Is any cloud or backend service a remote data processing solution?

is in scope only when the processing is at a distance, its absence would prevent the product from performing one of its functions, and the software is designed and developed by the manufacturer or under the manufacturer's responsibility.

This does not automatically pull an entire cloud estate into the CRA product. The boundary covers software parts that directly support product functions, not the manufacturer's network and information systems as a whole.

Mark a service as likely RDPS when it enables onboarding, configuration, synchronisation, remote commands, updates, identity access, or another product function and the manufacturer designed it or had it built for that purpose.
Treat general-purpose third-party SaaS differently unless it was designed and developed by or under the responsibility of the manufacturer.
Exclude ordinary informational websites and internal systems such as HR, payroll, CRM, CI/CD, pentesting, or threat-hunting tooling unless they meet the CRA remote-processing criteria for a product function.
Document third-party cloud dependency risks even where the service is not RDPS, because the manufacturer may still need due diligence for components and services that affect product cybersecurity.

Section 7

7. Is it default, important class I, important class II, or critical?

Once the product appears in scope, classification determines the conformity assessment route. Products with the core functionality of an Annex III category are important products; products with the core functionality of an Annex IV category are critical products.

The classification test is based on actual features and technical capabilities reflected in the product's intended purpose. Integrating an important or critical component does not automatically make the whole product important or critical.

Compare each core functionality of the product against the Annex III and Annex IV categories and the binding technical descriptions in Implementing Regulation (EU) 2025/2392.
Do not classify only by broad family names such as platform, gateway, browser, security tool, or embedded device; compare the actual product capability.
If the product only has ancillary overlap with a listed category, record why the listed category is or is not the product's core functionality.
If the product qualifies as free and open-source software and falls under Annex III, record whether the Article 32(5) public technical documentation condition is relevant.

Section 8

8. Which application and transition rule applies?

An in-scope answer does not mean every CRA duty already applies. Article 14 reporting starts on 11 September 2026. The rest of the Regulation generally applies from 11 December 2027, while the notified-body chapter has applied since 11 June 2026.

For a product placed on the market before 11 December 2027, Article 69 generally applies the remaining CRA requirements only if the product undergoes a substantial modification from that date. Article 14 is the exception: its reporting duties apply to all in-scope products placed on the market before 11 December 2027. Record placement dates and later modifications instead of treating the product family as one undated item.

Record the first placement-on-market date for each product version or unit covered by the assessment.
Prepare Article 14 triage and reporting for in-scope products before 11 September 2026, including products already placed on the market.
For products placed before 11 December 2027, assess later changes against the CRA substantial-modification definition before relying on the transition.
Do not use the transition to classify a product as out of scope; it changes when specified obligations apply, not the Article 2 scope test.

Section 9

Applicability record to keep

The page output should be a short scoping record that a product, security, legal, or compliance team can reuse when conformity assessment, technical documentation, supplier due diligence, and release planning begin.

If any answer depends on facts not yet known, mark the product as unresolved rather than forcing an in-scope or out-of-scope answer.

Product identifier, version, edition, deployment mode, sales channel, and intended EU availability.
Product-with-digital-elements analysis, including hardware, software, firmware, components, connection types, and RDPS boundary.
Market-availability and commercial-activity analysis, including open-source monetisation facts where relevant.
Article 2 exclusion check, economic-operator role map, Annex III or Annex IV classification outcome, and the source references used for each conclusion.
Outcome: record in scope, excluded under a named Article 2 provision, outside the connection or Union-market conditions, or unresolved pending specified facts. Keep timing and transition as a separate conclusion.
Reassessment triggers: a changed intended purpose or product function, a new data connection or remote service, separate marketing of a component, entry into an EU channel, rebranding, a new monetisation model, a changed Annex III or Annex IV capability, or a post-market modification.

Next step

Turn the CRA scope answer into a product assessment

Use the applicability result to open a product-level assessment covering role ownership, technical documentation inputs, RDPS boundaries, classification, conformity route, and release blockers.

Assessment workflow

Create a CRA product assessment

Convert the scope record into assigned evidence requests, role checks, and product cybersecurity assessment tasks.

Explore next step

Talk to Sorena

Review a CRA scope question

Use Sorena's contact route for product-specific scoping, RDPS, open-source, or important-product classification questions.

Explore next step

Primary sources

References and citations

Commission Implementing Regulation (EU) 2025/2392

eur-lex.europa.eu

Referenced sections

Supports the need to compare actual product features and technical capabilities against the technical descriptions for important-product categories.

Draft Commission guidance on the Cyber Resilience Act

ec.europa.eu

Referenced sections

Supports the practical boundary analysis for source code, public repositories, data connections, remote data processing solutions, product core functionality, and important or critical classification.

"Draft Commission guidance on the Cyber Resilience Act"

European Commission CRA FAQs, version 1.3, July 2026

ec.europa.eu

Referenced sections

Supports practical interpretations of CRA scope, standalone software, firmware, connection types, products made for own use, transition handling, open-source software, operator roles, and important or critical product classification.

"products with digital elements"

European Commission CRA reporting obligations

digital-strategy.ec.europa.eu

Referenced sections

Confirms that Article 14 reporting starts on 11 September 2026 and that manufacturers will report once through the CRA Single Reporting Platform.

Regulation (EU) 2024/2847, Cyber Resilience Act

data.europa.eu

Referenced sections

Supports the legal scope test for products with digital elements, Article 2 exclusions, economic-operator definitions, open-source steward status, remote data processing, Annex III and Annex IV classification, and conformity-assessment consequences.