Cyber Resilience Act scope is a product-and-market question, not a synonym for every cloud security duty in Europe. Regulation (EU) 2024/2847 generally addresses hardware and software products with digital elements that are made available on the Union market and whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical connection to a device or network. A downloadable desktop application, commercial mobile app, operating system, network appliance, separately sold library, and connected sensor can therefore enter the analysis through different routes. A pure internal tool, a stand-alone professional service, and remote processing that is merely incidental require different treatment.
The practical objective is to produce a traceable scope record for each product family, release model, legal entity, and EU route to market. The Commission's legislative summary explains that final products and components placed separately on the market can qualify, while the CRA legal text controls where an accessible summary leaves uncertainty. Do this analysis before teams choose a conformity route, promise a support period, or assume that a supplier carries the obligation. The result should name the product boundary, role, evidence, unresolved interpretations, and review trigger.
Screen Cyber Resilience Act scope through six gates
Begin with a product register rather than the company website. Record what the customer obtains, how it is identified, whether it is supplied for payment or in another commercial activity, which entity uses its name or trademark, and whether the item can connect directly or indirectly. Include installers, firmware, command-line tools, SDKs, mobile clients, paid plugins, container images, and components offered independently. Separate these from professional configuration, hosting operations, and bespoke work products. A single commercial offer may contain several products with digital elements plus services, and each boundary can lead to a different obligation.
For every candidate, preserve a concise rationale and the material supporting it: product terms, architecture, package identifiers, distribution channel, pricing model, trademark, intended-purpose statement, and connection paths. Use the broader compliance-ready delivery guide to make the decision part of release governance. Scope is not a one-time counsel memo. A new marketplace listing, acquisition, white-label arrangement, remote feature, or separately distributed component can change the facts even when source code changes little.
| Question | Evidence to inspect | Likely direction | Escalate when |
|---|---|---|---|
| Is identifiable software or hardware supplied? | Package, device, image, installer, license and product terms | A product candidate exists | The offer combines bespoke services and reusable software |
| Is supply in a commercial activity? | Payment, monetisation, support, marketplace and business model | Market availability may be present even if free of charge | Free distribution supports a paid ecosystem |
| Can it connect to a device or network? | Intended use, foreseeable use and architecture | Direct or indirect connection supports scope | Connectivity is optional, indirect or enabled by another component |
| Is remote processing functionally necessary? | Feature dependency and responsibility for remote software | Necessary manufacturer-controlled processing may join the product boundary | The service is shared, replaceable or operational rather than product-specific |
| Does sector legislation displace or modify CRA treatment? | Product sector, certifications and applicable EU acts | Special rules may apply | Medical, automotive, aviation, marine or other regulated products are involved |
Define the product with digital elements boundary
The boundary should follow the product placed on the market, not merely a repository. The CRA definition includes software or hardware and remote data-processing solutions that are designed and developed by, or under the responsibility of, the manufacturer and whose absence would prevent the product from performing one of its functions. Ask whether the remote element is necessary to a marketed function, who controls its design, and whether the local product still performs that function when the service is unavailable. Document APIs, hosted decision engines, update services, and account infrastructure separately rather than declaring all SaaS automatically included or excluded.
Components matter when placed on the market separately. A library bundled only inside your product belongs in the product's component analysis; the same library offered independently under your name may itself require a scope decision. Build a component-to-product map with version, supplier, license, integration purpose, and independent distribution status. The supply-chain security operating guide helps structure ownership and supplier evidence, but the CRA record must additionally state whether your organization is the manufacturer of the component or a manufacturer exercising due diligence when integrating it.
Test Union market availability and commercial activity
The central market concepts are placing on the market, meaning first making available on the Union market, and making available, meaning supply for distribution or use in the course of a commercial activity, whether paid or free. Capture who supplies the product, to whom, in which territory, under what transaction, and on what date. A global download page, EU app-store availability, bundled device, reseller channel, and enterprise master agreement create different evidence. Do not use customer headquarters alone as the answer; map the actual distribution and use channel.
Internal development that is not supplied on the market is generally outside this product regime, although other laws and contractual controls may apply. Conversely, zero price is not decisive when distribution is connected to monetisation, paid support, a commercial platform, or a business offering. Record the commercial context rather than relying on the license label. Where a custom deliverable is developed exclusively for one customer, assess whether the arrangement is a product supply or service in light of the final facts and obtain legal interpretation for borderline cases. Preserve the assumptions so a later repeat sale triggers review.
Assign the manufacturer, importer, and distributor roles
The manufacturer is the person that develops or manufactures a product, or has it designed, developed, or manufactured, and markets it under its name or trademark. This can make a brand owner the manufacturer even when a contractor writes the code. An EU-established party placing a non-EU manufacturer's product on the market can be an importer; another supply-chain party making it available without changing its properties can be a distributor. The Commission's manufacturer guidance distinguishes duties before placement, at placement, and during the support period.
Create a RACI per legal entity and product, but do not let contractual wording substitute for the statutory role. Record trademark owner, design authority, release signer, EU importer, distributors, authorised representative, vulnerability contact, and conformity-document custodian. Importers must check specified manufacturer and conformity conditions; distributors have verification and non-compliance duties. A party that substantially modifies a product may assume manufacturer obligations for the modified product. Procurement should therefore route rebranding, functional forks, and security-relevant customisation through the scope owner before commercial release.
Handle free and open-source software without shortcuts
Free and open-source code is not a blanket exclusion. Software developed or supplied outside a commercial activity receives special treatment, while commercial distribution under a manufacturer's name can still bring a product into scope. The Regulation also creates the role of open-source software steward: a legal person other than a manufacturer that systematically and sustainably supports specific free and open-source products intended for commercial activities and ensures their viability. The Commission's open-source page is a useful starting point, but project facts determine the role.
For each open-source project, document maintainers, legal home, funding, governance, paid services, release authority, trademark, commercial integrations, and whether your company distributes a product under its own name. Distinguish contributing upstream from selling a supported distribution or embedding the code in a commercial appliance. Also preserve component notifications and vulnerability-handling contacts; manufacturers integrating third-party components must exercise due diligence. A public repository and permissive license do not answer who places the resulting product on the market or who controls its security support.
Classify important and critical products after scope
Classification determines conformity options; it does not decide whether ordinary products are regulated. First establish that an item is an in-scope product with digital elements. Then compare its core functionality with the categories in Annexes III and IV and applicable technical descriptions. Important class I products may use internal control only under specified routes such as applicable harmonised standards; important class II and critical products generally require third-party assessment or an available applicable certification route. Most other products can use internal control, provided the manufacturer actually demonstrates compliance.
| Product position | Core question | Conformity implication | Evidence to retain |
|---|---|---|---|
| Default in-scope product | No listed important or critical core functionality | Internal control may be available | Classification comparison, risk assessment and technical documentation |
| Important class I | Core functionality matches an Annex III class I category | Internal control depends on the permitted standards or specification route | Technical description mapping and chosen conformity basis |
| Important class II | Core functionality matches an Annex III class II category | Third-party or applicable certification route | Notified-body or scheme records and product configuration |
| Critical product | Core functionality matches Annex IV | Enhanced third-party or applicable certification route | Critical classification rationale and complete assessment trail |
| Open-source important product | Qualifying FOSS product meets an important category | Special self-assessment condition may apply when documentation is public | FOSS status, public technical file and classification evidence |
Write the classification against core functionality, not isolated features or marketing nouns. A general platform containing authentication may not automatically be an identity-management product, while a product whose primary purpose is privileged access management may fit a listed category. Have product, engineering, security, and regulatory counsel review the description together. The Commission conformity-assessment guidance should be tracked for implementation updates, and the record should identify the version of each legal or technical source used.
Manage substantial modification and transition dates
The main CRA obligations apply from 11 December 2027; Article 14 reporting applies from 11 September 2026. Products placed on the market before the main application date generally become subject to the Regulation from that date if they undergo a substantial modification, while reporting reaches products already made available on the Union market. A substantial modification is not simply every patch. The analysis should examine whether a post-market change affects compliance with essential requirements or changes the intended purpose. Feature additions, changed trust boundaries, new connectivity, or altered security controls deserve explicit review.
Add a CRA gate to change management: identify the released product and baseline, describe the modification, test intended-purpose and compliance effects, decide whether a new conformity assessment is required, and record the approver. Keep pre-2027 installed-base identifiers because reporting teams must know which historical versions remain in use. A vulnerability fix should not be delayed by an overbroad process; define an expedited route that preserves the assessment after urgent release. The vulnerability-management guide provides operational prioritisation, while the CRA record adds product, market, and regulatory consequences.
Key takeaways
- Inventory identifiable products, components, remote dependencies, distribution channels, and legal entities before deciding scope.
- Treat market availability, commercial activity, connectivity, and product boundary as separate evidence questions.
- Assign manufacturer, importer, distributor, representative, or steward roles from facts, not contract labels alone.
- Analyze open source through commercial context, governance, distribution, and branding rather than license type alone.
- Classify important and critical core functionality only after establishing product scope.
- Revisit the decision when branding, functionality, connectivity, distribution, or post-market modification changes.
Cyber Resilience Act scope FAQ
Is every SaaS product within CRA scope?
No. Analyze whether identifiable software is made available on the Union market and whether remote data processing belongs to an in-scope product boundary. Pure remote services are not automatically products with digital elements, while downloadable clients, necessary manufacturer-controlled remote processing, and separately supplied software can change the result. Record the architecture and commercial facts rather than using the label SaaS as the conclusion.
Does free software always fall outside the CRA?
No. Supply in a commercial activity can occur without a direct price, and products marketed under a manufacturer's name may be in scope. Non-commercial free and open-source development receives special treatment, and qualifying open-source software stewards have a distinct set of duties. Funding, monetisation, distribution, trademark, and governance facts should be assessed together.
Can a software component be a separate regulated product?
Yes, when the component is itself placed on the market separately and the other scope conditions are met. A component only integrated into another product still matters to the final manufacturer's due diligence and vulnerability handling. Maintain separate records for independent distribution and embedded use so teams know which organization holds which obligation.
Conclusion
A defensible CRA scope decision connects a named product to its connection behavior, market route, commercial context, responsible economic operator, classification, and release history. That record lets engineering and compliance act on the same boundary. It also exposes the cases that genuinely need specialist interpretation before the organization commits to conformity, support, reporting, and customer obligations.