Does the Cyber Resilience Act apply to us

Does the Cyber Resilience Act apply to us? The short answer and the questions that decide it

The Cyber Resilience Act applies to products with digital elements made available on the EU market in the course of a commercial activity, whether for payment or free of charge, where the product has a direct or indirect logical or physical data connection to a device or network. Under Article 2(1), that data connection is what brings most software and connected hardware into scope. Whether you carry the obligations depends on your role and on the product type. A manufacturer is anyone who markets a product under its own name or trademark, including free of charge (Article 3(13)). Making a product available means supplying it in a commercial activity (Article 3(22)), so a free app distributed as part of a business can still count. Importers and distributors take on manufacturer duties only in specific cases, which Article 21 sets out. The answer therefore differs by organization, and a product team cannot settle it by asking whether the company sells software. Start by listing each product, app, firmware image, appliance or software bundle, and asking whether it has a data connection in its intended or reasonably foreseeable use. Then ask whether a cloud backend the manufacturer designed is needed for the product to perform one of its functions, since remote data processing can bring that backend into scope under Article 3(2). For each product, record whether your organization is the manufacturer, an importer, a distributor, or a party that substantially modified a product, and whether any exclusion in Article 2(2) to (7) applies, such as medical devices or products made exclusively for defense.

Next, check timing and product category. Products already on the market before 11 December 2027 fall under the regulation only if they are substantially modified after that date, while the Article 14 reporting duty reaches all in-scope products regardless of when they were placed on the market. Confirm with your counsel or the market surveillance authority how each release date applies to your build variants. Finally, check whether the core functionality matches an Annex III or Annex IV category as described in Implementing Regulation (EU) 2025/2392, because that decides whether a self-assessment route is open. Document each answer in a scope register that names the product, your role, the exclusion or category reasoning, and the owner who signed it off. Your auditor or customer will ask for that register first.

How to decide step by step whether the CRA covers your product

This sequence tests each product against the regulation's scope rules in order, so you finish with a clear answer on whether the Cyber Resilience Act applies, from which date, and in what role.

Confirm the product has digital elements
Start with the product itself, not your company. Ask whether it is software, hardware with embedded software, standalone hardware, or a combination supplied to work together. Under Article 2(1), the regulation applies when the intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Commission guidance C(2026) 5252 (section 2.2) gives examples on both sides of the line. Browser extensions and locally installed desktop apps built with web technologies count, while a website or web application reached only through a browser does not count on that basis alone. Output: a written statement naming the product and the connection that brings it into scope, or the reason it is not in scope.
Check that the product is made available on the market
Next, establish whether the product is supplied in the course of a commercial activity, whether for payment or free of charge (Article 3(22)). Internal tools used only within your organization are not placed on the market. Note that a product offered free of charge still counts if it is supplied commercially. Also record who puts the product under its name or trademark, because Article 3(13) treats that party as the manufacturer even when nothing is charged. Output: a short record of each supply route, with the date of first supply and the entity that supplies it.
Screen out products excluded under Article 2
Compare the product against the exclusions in Article 2(2) to (7). These cover products within the medical device and in vitro diagnostic regulations, vehicle type-approval rules, aviation-certified products, marine equipment, identical spare parts, and products made exclusively for national security or defense or to process classified information. Check each exclusion against the exact wording in the regulation, because a product that resembles an excluded category may still be in scope. Output: a documented decision for each exclusion, with the reason it does or does not apply. Where the boundary is unclear, confirm it with counsel or your national market surveillance authority before relying on it.
Identify the placement date and any legacy status
Determine when the product was first placed on the EU market. Under Article 69, products placed on the market before 11 December 2027 are subject to the regulation only if they are substantially modified from that date. Commission guidance (section 2.1) says all copies of a standalone software version count as placed on the market when first offered, and that build variants with different components or features are separate products. Updates that are not substantial modifications do not change that date. Note that Article 14 reporting applies to all in-scope products, including legacy products, from 11 September 2026. Output: a product register entry with the first placement date, the build variants, and a legacy or new flag.
Assess remote data processing and cloud components
Under Article 3(2), remote data processing designed by or under the responsibility of the manufacturer becomes part of the product when the product could not perform one of its functions without it. Map each cloud backend, API or hosted service that the product depends on for its functions. A backend that the product cannot work without can bring that service into scope, even though the customer never installs it. Output: a list of remote services with a yes or no on whether the product depends on each one for a function, and the owner of each service.
Determine your role for each product
Assign a role to your organization for each product: manufacturer, importer, distributor, open-source software steward, or a party that substantially modifies a product. Under Articles 21 and 22, an importer or distributor becomes a manufacturer if it sells the product under its own name or trademark or substantially modifies it. Any other person who substantially modifies and makes a product available is treated as its manufacturer. Your role determines which obligations apply to you. Output: a role statement per product, with the article that supports it and a note on any product where more than one party holds a role.
Classify the product and record the answer
Compare the product's core functionality with the categories in Annexes III and IV, as described in Implementing Regulation (EU) 2025/2392. A product that matches an important or critical category follows a stricter conformity assessment route under Articles 7, 8 and 32. Every other in-scope product falls in the default category and may use self-assessment. Close the sequence by writing one decision record per product: in scope or not, placement date, legacy status, role, and category. Confirm any unclear result with counsel or a national market surveillance authority before you rely on it. Output: a signed decision record that a reviewer can trace back to each article.

What counts as a product with digital elements and what does not

The regulation reaches products that connect to a device or network, but the line between software, hardware and hosted service depends on how each piece is delivered and run. The cards below follow the categories in the Commission's guidance, section 2.2, so you can place each of your offerings on one side of the line and identify where your own architecture needs confirmation.

Standalone software such as apps

Apps and computer programs placed on the EU market are the most direct case. A mobile app, desktop program or server package you supply as a product with a data connection is in scope, even when you give it away. Check whether the intended purpose or foreseeable use includes a connection to a device or network, because that test under Article 2(1) decides scope. Confirm this for each distinct app and build variant you ship.

Hardware with embedded software

IoT devices, laptops and similar hardware that ship with firmware or embedded software are covered as a single product. The guidance treats the hardware and its software together, so a gap in either can bring the whole device into scope. Ask your engineering team which firmware runs on the device, who builds it, and whether the device can be reached over a network or local connection.

Standalone hardware components

Integrated circuits and other hardware sold without a finished device can be products with digital elements in their own right. If you supply a component that a downstream manufacturer integrates, your obligations and your customer's depend on how the component is placed on the market. Confirm with your customers whether they buy the part as a finished product or as a building block for their own product.

Separately supplied combinations

Hardware and software supplied separately but intended to work together can form one product. A controller sold with a companion application, or a sensor sold with a required cloud service, may be assessed as a combination. Map each element you supply, list what the customer must install to make it work, and record whether you designed the pairing. This is the case most often missed by teams that split products across different business units.

Locally installed software built with web technologies

Software downloaded or installed and run on the user's side is a product with digital elements, even when it is built with web technologies. This covers browser extensions and locally installed desktop apps packaged from web code. Check whether the code runs on the user's machine after installation, since that runtime location is what the guidance points to, not the programming language.

Web applications accessed only through a browser

A web application that users reach only through a browser, and a website, are not products with digital elements on that basis alone. The exclusion does not remove a hosted service from scope if it is part of an in-scope product, because remote data processing can be included under Article 3(2). Confirm whether any browser-based service is the backend of an app or device you sell, since that dependency changes the answer.

Does a SaaS or cloud backend bring us into scope?

A cloud backend can bring a product into the Cyber Resilience Act even when the software on the user's device looks unremarkable. Under Article 3(2), remote data processing forms part of a product with digital elements when it is designed by or under the responsibility of the manufacturer and the product could not perform one of its functions without it. The test turns on dependency, not on where the code runs. Your first decision is therefore to list every function each product offers and mark which of those functions would fail without a server-side service you operate or commission. A mobile app that cannot sign in, sync, receive alerts or update its data without your backend has that backend inside its scope.

A pure web service is treated differently. Software accessed only through a browser, with no installed component on the user's side, is not a product with digital elements on that basis alone, and the Commission's guidance treats browser-only web applications the same way. The contrast matters for companion products. If a desktop client, mobile app or IoT device is installed on the user's side and depends on your cloud service for a core function, the installed component and the backend are assessed as one product. If the cloud service stands alone and the customer only uses it through a browser, the analysis usually ends at the service boundary, but you should record the reasoning rather than assume it.

This is a scoping question that you answer, and the answer should rest on your own architecture documentation. Gather the design records for each product, including component diagrams, API dependency maps, the data flows between device or client and backend, and the service ownership model showing who builds and operates each backend component. Note whether any backend element is supplied by a third party and whether you designed or configured it, since responsibility under Article 3(2) depends on that. Ask engineering to confirm which functions degrade or stop when each service is unreachable. Keep the signed-off record with the product file, because the same architecture will also drive the risk assessment and support period obligations if the product is found in scope.

Which role you hold: manufacturer, importer, distributor or steward

The CRA attaches obligations to the role you play in placing a product on the EU market, not to your company as a whole. Read the four roles below, decide which one fits each product, and remember that a single organization can hold more than one role across its portfolio.

Manufacturer

Under Article 3(13), a manufacturer is anyone who markets a product under its own name or trademark, and this applies even when the product is supplied free of charge. Most companies that build and publish software or devices fall here, and it carries the full set of Annex I and vulnerability handling duties. Check whether any product you distribute to EU users carries your name or brand, because that alone can make you the manufacturer. Obligations are covered on the obligations page.

Importer or distributor

An importer or distributor brings or supplies a product from outside the manufacturer's control, and under Article 21 it becomes a manufacturer if it sells the product under its own name or trademark or substantially modifies it. Resellers of hardware, and firms that rebrand or repackage third-party software, should check each product line against this test. If you stay a pure importer or distributor, confirm what the manufacturer has documented and what you must verify before you sell.

Substantial modifier

Article 22 treats any person who substantially modifies a product and then makes it available as that product's manufacturer, even if that person did not design the original. Integrators, consultants who customize platforms for a client, and teams that fork and redeploy open-source software for commercial use can fall into this role. Record each change you make and assess whether it is substantial before you release the result. The Commission's guidance on substantial modification gives worked examples to test against.

Open-source software steward

Under Article 3(14), a steward is a legal person that systematically supports free and open-source software intended for commercial activities, and Article 24 sets a lighter regime for that role. Foundations and companies that run maintained open-source projects used by businesses should confirm whether their support activity is systematic enough to qualify. Stewardship does not replace a manufacturer's duties for products it sells. The open-source guide explains how monetization and donations affect this test.

Sector exclusions, legacy products and the 2027 date

Start by checking whether your product falls into one of the sector exclusions in Article 2(2) to (7). The regulation does not apply to products covered by the medical device and in vitro diagnostic regulations, vehicle type-approval rules, aviation-certified products, marine equipment, identical spare parts, or products made exclusively for national security or defense or to process classified information. Read each exclusion narrowly. An exclusion removes a product from the regulation only when the product falls within the named regime. A product may be partly covered by another regime, so a connected medical device that also has a companion software app should be assessed component by component. Record the reasoning for each exclusion decision, because a market surveillance authority will ask for it, and confirm the exact wording with a lawyer familiar with the sector regime.

Next, establish when each product was first placed on the market. Under Article 69, products placed on the EU market before 11 December 2027 fall under the regulation only if they are substantially modified from that date. The Article 14 reporting duty already applies to all in-scope products since 11 September 2026, regardless of when they were first placed on the market. Commission guidance C(2026) 5252 (section 2.1) states that all copies of a standalone software version are placed on the market when that version is first offered, and that updates which are not substantial modifications do not change that date. Build the product inventory with a first-offered date for each version, and check which products already have a reporting contact and process in place.

Finally, treat build variants as separate products. Guidance section 2.1 says variants with different components or features are separate products, each with its own placed-on-market date and classification. For example, an illustrative firmware image for a base model and a premium model with an added networking module would be two products, even if most code is shared. Ask your engineering team to list every variant that is shipped, sold or offered free of charge, along with its components and the version date. That list becomes the scope baseline for both the 2027 date and any future substantial modification assessment.

How the answer changes by organization type

A company that offers only hosted software through a browser usually starts from a different place than a company that ships installed software. Web applications accessed only through a browser and websites are not in scope on that basis alone, but the Commission guidance and Article 3(2) mean that a cloud backend can become part of an in-scope app or device when the product could not perform a function without it. The first check is whether any installed component, such as a desktop client, mobile app or browser extension, is offered to users.

Browser-only access: Confirm that users reach the service only through a browser and that nothing is downloaded and run on their side.
Installed clients: Check whether a desktop, mobile or extension client is supplied, since that client may be a product with digital elements.
Remote data processing: Identify backend functions that a connected product needs in order to work, which can bring the cloud service into scope.
Commercial activity: Note whether any version is offered free of charge, because supply without payment can still count as making a product available.
Support and ownership: Record who designs and controls the hosted service, since that determines who is the manufacturer.

The first check is whether any installed or device-side component exists, and if so, whether the backend is needed for it to function.

Scope checklist: the facts to confirm for each product

This table lists the facts you must establish for each product before deciding whether the Cyber Resilience Act applies, which role you hold and which conformity route follows. Work through the rows in order, because the data connection and commercial activity questions decide whether the regulation reaches the product at all.

Question	Where the answer comes from	Who answers it
Does the product have a direct or indirect logical or physical data connection?	Intended purpose and reasonably foreseeable use, Article 2(1), including remote cloud backends under Article 3(2)	Product management with engineering sign-off
Is the product supplied in the course of a commercial activity, free of charge or for payment?	Making available on the market, Article 3(22), and manufacturer definition, Article 3(13)	Legal or commercial owner of the product
Does a sector exclusion in Article 2(2) to (7) apply?	Medical device, vehicle, aviation, marine, spare parts and national security rules, checked against the exact product scope	Regulatory affairs with legal counsel
When was each version or build variant first offered on the market?	First-offer date per standalone software version, Commission guidance C(2026) 5252, section 2.1, and the 11 December 2027 cut-off in Article 69	Release management and product records
Has any version been substantially modified, and by whom?	Change history compared with the substantial modification criteria in the Commission guidance, and Article 22 for third parties	Engineering leads and the team that approves major releases
What role does the organization hold for each product?	Manufacturer, importer or distributor status under Articles 21 and 22, including use of its own name or trademark	Legal, procurement and the product owner together
Which product class applies: default, important (Annex III) or critical (Annex IV)?	Core functionality compared with the categories in Implementing Regulation (EU) 2025/2392, which sets the conformity assessment route	Product security lead, confirmed by a notified body or legal counsel where the category is unclear

When to bring in outside help to confirm scope

Deciding whether the Cyber Resilience Act applies to a product, and in which role, is the organization's decision and it should be recorded as one. An implementation partner can support that work by mapping each product's intended purpose, its data connections, the architecture of any cloud backend that the product depends on, and the supply chain roles that apply to each release, such as whether the organization is a manufacturer, importer, distributor or steward. DeployOpen does this kind of mapping as part of readiness work and prepares the resulting scope record, with the product inventory, architecture diagrams and the reasoning behind each in-scope or excluded decision. DeployOpen does not issue legal opinions, declarations of conformity or conformity assessments. Only an independent conformity assessment body can issue those, and the organization remains responsible for its own determinations.

Some cases will not resolve from the text alone. Examples include a product that sits near one of the sector exclusions in Article 2, a web application that also ships a locally installed component, or a legacy product where a planned update might count as a substantial modification. For these, the organization should ask its national market surveillance authority for its view or take advice from qualified counsel familiar with EU product law, and record the answer in the scope record. Ask any counsel or consultant to state in writing which facts they relied on, because the conclusion is only as reliable as those facts.

Any outside work should start from a written scope that lists the products, the business units and the questions to be answered, with deliverables and timing agreed before work begins. DeployOpen's engagements are fixed-scope, so the quote follows from that written scope rather than from a published price list. When requesting a quote, ask what the scope record will contain, which product and architecture sources the partner will need from your team, what it will not decide for you, and how borderline cases will be escalated to counsel or the authority.

Questions buyers ask about CRA applicability

Does a free app still fall under the Cyber Resilience Act?

Yes, it can. The regulation covers products made available in the course of a commercial activity, and Article 3(22) counts supply free of charge as making available. Article 3(13) likewise treats anyone who markets a product under their name or trademark as a manufacturer, even when nothing is charged. The product must also have a logical or physical data connection to a device or network, as Article 2(1) sets out. A free app that connects to a service or another device usually meets that test. Open-source software is treated differently. Under Article 3(14), free and open-source software that is not monetized is not placed on the market, but commercial use changes the analysis. Check whether your app is distributed in a commercial activity, and document that reasoning before you rely on it.

Do we need a notified body to decide whether the regulation applies?

No. Deciding scope is the manufacturer's own determination, based on the product's intended purpose and reasonably foreseeable use under Article 2(1). A notified body is involved only in the conformity assessment route for certain products, set out in Article 32, and only after the product is already classified. Classification itself depends on whether core functionality matches an Annex III or Annex IV category, as described in Implementing Regulation (EU) 2025/2392, and that determines whether self-assessment is available. If the answer is unclear for a border product, ask a lawyer familiar with EU product regulation or the relevant market surveillance authority for a view, and keep the written reasoning. No independent body will issue a scope certificate for you, so the file you keep is your evidence.

Does a SaaS-only company need to comply with the CRA?

It can, but the answer depends on what is downloaded or installed. Commission guidance C(2026) 5252 says a web application accessed only through a browser is not a product with digital elements on that basis alone. Locally installed software, including desktop apps built with web technologies and browser extensions, is in scope. The cloud side matters too. Under Article 3(2), remote data processing designed by or under the responsibility of the manufacturer becomes part of the product when the product could not perform one of its functions without it. A company that sells a pure browser service may fall outside the regulation, while a company that also ships an agent, client or device that depends on its backend may be inside it for that component. Map each deliverable separately.

What does scoping cost, and how long does it take?

The cost of scoping depends on how many products, release lines and distribution channels you have, how much of the product architecture is documented, and whether legal interpretation is needed. Scoping has a one-time cost, while the obligations it reveals recur over each product's support period. No supplied figure gives a price or duration for scoping, so ask for one. DeployOpen does not publish prices, and a quote follows from the written scope, which is normally agreed in writing before work starts. Ask any provider to itemize the product inventory, architecture review, classification memo, role analysis, and the handover of documented findings. For timing, the regulation applies from 11 December 2027 under Article 71(2), and Article 14 reporting applies from 11 September 2026, so scoping should start early enough to find reporting exposure first.

What do we need to provide to scope our products properly?

Gather the facts that decide the answers, not the full compliance file. You need a product inventory listing each standalone software version, hardware model and build variant, since Commission guidance C(2026) 5252 treats different builds as separate products. Provide architecture diagrams that show every data connection and any remote backend the product depends on, as Article 3(2) requires. Document how each product reaches users, whether for payment or free, and which entity places its name or trademark on it, because Article 3(13), 21 and 22 turn that into a manufacturer, importer, distributor or modifier role. Include a release history that shows when each product was first placed on the market and which updates changed it significantly. List the third-party and open-source components that ship with the product.

Can we determine CRA applicability in house, or do we need outside help?

Your organization can do the scoping itself, and many do. The decision depends on the people available and on how complex the product portfolio is. In-house teams usually hold the architecture knowledge, and that matters most for Article 3(2) and substantial modification questions. Outside help is most useful when you need legal interpretation of Articles 2, 3 and 21, a second view on border products, or a structured record that will hold up under review. An implementation partner such as DeployOpen can prepare systems, inventories and documented evidence within a fixed scope, but the organization still owns its classification and its controls. Only an independent auditor, assessor or notified body issues a report, certificate or conformity assessment result. Ask any provider which parts of the work they will hand over in writing.

How DeployOpen scopes CRA products and prepares the evidence

DeployOpen starts by working out which of your products the Cyber Resilience Act covers and in what role, before any technical work begins. Where your products run on self-hosted open-source platforms in your own infrastructure, we prepare the systems and records that support your position, while your organization keeps ownership of every classification decision.

How we scope

We map each product, build variant and remote backend against the scope questions in the written engagement plan.
The written scope names the products, roles, deliverables and timelines agreed before work starts, so nothing is assumed.
Engagements are fixed-scope, and any classification question we cannot settle is flagged for your counsel or a notified body.

How we build

We set up the open-source platforms and component inventories that record which software versions reach users and when.
We document the placing-on-the-market date, substantial modification history and supplier roles for each in-scope product.
We test the configurations and interfaces that determine whether a product is connected, so the scope record reflects how the product actually runs.

How we hand over

You receive the scoping memo, product inventory, role analysis and evidence files, organized so your reviewers can trace each conclusion.
Open items are listed with an owner and the source you need to confirm, such as the Commission guidance or Implementing Regulation (EU) 2025/2392.
We do not issue declarations, classifications or certificates; your legal team and any independent assessor make those decisions.

How we support

Ongoing support, upgrades and continuous testing are available as retainers when your product portfolio or guidance changes.
We can refresh the scope record when a product is updated, rebuilt or moved to a new deployment model.
Ask us to confirm the support scope, response expectations and review cadence in the written quote before engagement starts.

Does the Cyber Resilience Act apply to us