Does the Cyber Resilience Act apply to my product? What Article 2 asks
The scope decision comes before any other CRA work. Before a team plans essential requirements, technical documentation or vulnerability handling, it has to establish whether the product is in scope at all. Article 2(1) applies Regulation (EU) 2024/2847 to products with digital elements made available on the EU market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Two tests sit inside that sentence: the product must be placed on the market in the EU, and it must have a connection that is part of its intended or foreseeable use. Making a product available covers supply for distribution or use in a commercial activity, whether paid or free of charge, so a free tool distributed to customers can still count.
The harder part is that the definition of a product is wider than most teams expect. Article 3(1) covers software or hardware along with its remote data processing solutions, and Article 3(2) describes remote data processing as processing at a distance, designed by or under the responsibility of the manufacturer, without which the product could not perform one of its functions. A cloud backend that a device depends on may therefore sit inside the product, while a web application used only through a browser may not, unless it supports the product's functions. Article 2(2) to (4) exclude products already covered by the medical device regulations, the vehicle type-approval regulation, the aviation regulation and Directive 2014/90/EU on marine equipment, and Article 2(6) and (7) exclude certain spare parts and products developed exclusively for national security, defense or classified information.
Write the scope decision down, with the reasoning, before classification starts. For each product, record the intended purpose, the data connections in normal use, the remote services it depends on, and the exclusion it may fall under, then have legal and product owners sign off. Ask for the Commission's non-binding guidance (C(2026) 5252) to be read against the specific cases, particularly for remote processing and open-source components, because it addresses those edges directly. Confirm with national market surveillance authorities or qualified counsel any point the guidance leaves open for your product.
Which products, services and third parties sit inside the scope decision
Article 2 turns on a short set of questions about connectivity, how software reaches the market, and who uses it. Each question below can move a product in or out of the regulation, so answer them in writing before any compliance work is scoped.
Products with a data connection
Article 2(1) covers 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. A connected device, a desktop application that phones home for updates, or a product reachable only through a gateway can all qualify. Check the intended purpose in product documentation and marketing, not only the default configuration.
Software placed on the market separately
Article 3(1) includes software or hardware components placed on the market separately, so a library, agent or firmware package sold on its own can be a product with digital elements in its own right. Confirm whether each component is supplied for distribution or use in a commercial activity, free of charge or not, because Article 3(22) makes that the trigger. Open-source components supplied only through public repositories need a separate review.
Sector exclusions and their boundaries
Article 2(2) to (4) exclude products covered by the medical device regulations, the vehicle type-approval regulation, the aviation regulation and Directive 2014/90/EU on marine equipment. An exclusion applies to the product that falls under those regimes, not to every software product a company sells into those sectors. Map each exclusion to a named product so a companion app or analytics service is not carved out by accident.
Spare parts and identical replacements
Article 2(6) excludes spare parts that replace identical components and are made to the same specifications as the original. The exclusion is narrow: a replacement module with new functions, new firmware or a different specification does not inherit it. Record the specification match for each part, since an assessor will ask how the identity was established.
National security and classified use
Article 2(7) excludes products developed or modified exclusively for national security or defense, and products specifically designed to process classified information. The word exclusively matters: a commercial product later adapted for a defense customer may still be in scope. Ask the customer and your legal team to confirm the purpose in writing, and keep that record with the scope decision.
Remote data processing supporting product functions
Article 3(2) defines remote data processing as processing at a distance, designed by or under the responsibility of the manufacturer, without which the product could not perform one of its functions. Commission guidance C(2026) 5252 says a browser-only web application or website is not a product with digital elements on that basis alone, unless it is remote data processing supporting a product's functions. Cloud backends that a device depends on are the usual point of dispute, so document each function and its dependency.
Where the exclusions apply and where they stop
Article 2(2) to (4) take certain products outside the regulation because a separate EU regime already governs them. The exclusions cover products within the scope of the medical device regulations (EU) 2017/745 and (EU) 2017/746, vehicles approved under the type-approval regulation (EU) 2019/2144, products certified under the aviation regulation (EU) 2018/1139, and marine equipment under Directive 2014/90/EU. An assessor first asks whether the product actually falls within the named sector regime, not whether it resembles a regulated product. A connected device that is a medical device for one purpose and a general consumer gadget for another needs a documented split by intended purpose.
- Regime match: Confirm the product is covered by the named regulation or directive, not merely used in the same industry.
- Intended purpose: Record the intended purpose and the reasonably foreseeable use that places the product inside or outside the sector regime.
- Partial coverage: Identify any software or connected component sold separately that the sector regime does not cover.
- Certification evidence: Keep the sector conformity documents that show the product is within that regime.
- Boundary decisions: Note where a legal reviewer confirmed the boundary and why.
Before relying on any sector exclusion, confirm the boundary with the relevant competent authority or your legal counsel, and document that conclusion in the product file.
Article 2(6) excludes spare parts that replace identical components and are made to the same specifications as the original product. The exclusion protects the replacement market for components that were already placed on the market under the regulation. It does not exempt a new component that adds functions, changes interfaces, or is sold as an upgrade. An assessor compares the replacement part with the original design and checks whether the part is identical in function and specification.
- Identical component: Show that the part replaces a specific component of the original product without adding functions.
- Same specifications: Keep the design or specification records that tie the spare part to the original.
- Upgrades excluded from the exclusion: Treat firmware updates, new modules, or changed interfaces as separate products or modifications with their own analysis.
- Supplier documentation: Record the source of the component and the specification it was built to.
- Change control: Re-check the exclusion whenever the spare part design or firmware changes.
If the component carries software that changes behavior, ask counsel and your notified body contact whether the exclusion still applies before shipping it as a spare.
Article 2(7) excludes products developed or modified exclusively for national security or defense purposes, and products specifically designed to process classified information. The wording is narrow. Exclusive development for those purposes is the test, so a commercial product later sold to a defense customer does not automatically fall outside the regulation. An assessor looks at the development record, the intended market, and whether the product is also offered for ordinary commercial use.
- Exclusive purpose: Show that the product was developed or modified only for national security or defense use.
- Classified processing: Document the specific design features that make the product suited to classified information.
- Commercial overlap: Identify any commercial version, shared codebase, or general-purpose release that would bring the product back into scope.
- Authority records: Keep any government contract or designation that supports the national security purpose.
- Access controls: Record how the product is distributed, since that is often the evidence an assessor requests.
Because this exclusion depends on how a product is developed and sold, confirm the position with the competent national authority and your legal counsel before relying on it.
Commission guidance C(2026) 5252, section 2.2, explains that software which runs remotely and is only accessed by the user, such as a web application used exclusively through a browser or a website, is not on that basis a product with digital elements. The exception is remote data processing that supports a product's functions. Article 3(2) defines that as processing at a distance, designed and developed by or under the responsibility of the manufacturer, without which the product could not perform one of its functions. The line therefore runs between a hosted service a customer merely uses and back-end processing that a connected product depends on to work.
- Browser-only access: Confirm the software is used only through a browser and does not form part of a physical or networked product.
- Functional dependency: Test whether the product would lose a function without the remote processing.
- Manufacturer responsibility: Record who designs and develops the remote processing.
- Device pairing: Map every case where a device, app, or gateway relies on a cloud back end.
- Boundary review: Note the date and reasoning behind each decision, since the guidance is non-binding.
Read the guidance section directly, and have counsel confirm how it applies to each hosted component before you rely on the exclusion.
How remote data processing and browser-only web services are treated
A browser-only web application is not automatically a product with digital elements, but remote processing that a product needs in order to perform its functions can bring that product into scope. The test turns on what the software does and how it is connected, not on where the code runs. Article 3(1) defines a product with digital elements as a software or hardware product together with its remote data processing solutions. Article 3(2) defines remote data processing as processing at a distance, designed and developed by or under the responsibility of the manufacturer, without which the product could not perform one of its functions. Read together, a backend service is part of the product only when the device or software depends on it to work.
Commission guidance C(2026) 5252 (section 2.2) says that software which runs remotely and is only accessed by the user, such as a web application used exclusively through a browser or a website, is not on that basis a product with digital elements. The exception is remote data processing that supports a product's functions. For a team reviewing its portfolio, the practical question is whether a hosted component is required for a function of a connected product, and whether the manufacturer designed and runs it. Document that answer for each product and each backend service, and confirm the reading against the guidance text and any national authority interpretation before relying on it.
Illustrative example: a manufacturer sells a networked thermostat whose schedules and temperature control only work when its cloud service processes the device's data. The cloud service is remote data processing that supports a function of the product, so it falls within the product's scope. A separate web dashboard that shows the same company's marketing content, with no role in operating any device, is a browser-only service outside that analysis. Teams should record which backend functions each product cannot operate without, because that record decides which services the conformity file must cover.
How an assessor tests a scope decision
This table compares five scope checks an assessor runs on an Article 2 decision, what each one reviews, the evidence it asks for and where scope decisions usually go wrong. Read each row as a question the assessor will put to the manufacturer's written scope memo and the records behind it.
| Test approach | Evidence requested | Common findings |
|---|---|---|
| Product inventory check: confirms every product, variant and firmware line is listed and assigned a scope outcome | Product register with versions, intended purpose statement, and a one-line scope decision per item | Products missing from the register, or variants grouped together without checking whether their connectivity differs |
| Data connection test: checks whether the intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical connection | Architecture diagrams, interface list, network and Bluetooth or USB specifications, and documented foreseeable misuse cases | Scope set to no connection based on the marketing description, while the device still ships with a network port or companion app |
| Making-available test: confirms the product is supplied for distribution or use in a commercial activity, free of charge or not, and identifies the manufacturer under the Article 3(13) criteria | Distribution contracts, licence terms, release records and naming or trademark records showing who markets the product | Open-source projects treated as out of scope without checking whether a commercial entity supplies them, or whether a branded build is distributed |
| Exclusion checks: tests claimed carve-outs for medical, vehicle, aviation, marine, spare part and national security products against the cited legal basis | Certificates or approval documents for the excluded regime, purpose statements, and records showing the exclusion applies to this specific product | Exclusion claimed for a whole product family when only one model holds the approval, or spare parts that differ in specification from the original |
| Remote processing review: tests whether back-end services, cloud components or web applications are needed for the product to perform one of its functions | Functional analysis showing which features fail without the remote service, service design documents, and ownership of the back end | Web-only or cloud services assumed to be outside scope without showing that the product does not depend on remote data processing for its functions |
Steps to make a defensible scope decision
This sequence turns a loose question about whether the Cyber Resilience Act applies into a documented, reviewable scope record. Each step leaves an artifact that an auditor, market surveillance authority or legal reviewer can follow back to the Article 2 tests.
Inventory every product and service in play
Product management and engineering list each hardware product, software product, standalone component and remote service that carries the company's name or trademark or is supplied to others. Include free-of-charge releases, open-source projects published under the company's name, and components sold separately. The output is a register with one row per product or version line, its owner, its intended purpose and the markets where it is or will be made available. The step is done when product owners have signed the register and no shipped or planned item is missing.
Map each product to the Article 2 tests
Compliance and product security take each register row and answer the core questions in order. Does the product, or software or hardware that runs it, have a direct or indirect logical or physical data connection to a device or network? Is it made available on the EU market in a commercial activity? Does it fall within a sector exclusion, the spare parts rule or the national security exclusion? The output is a test sheet per product showing the answer and the source article for each test. Ask engineering to confirm the connection question with evidence from the architecture, not from marketing material.
Record exclusions with written reasons
Where a product is excluded, legal or compliance records the exact exclusion relied on, the facts that support it and the person who approved it. Exclusions for medical devices, vehicles, aviation, marine equipment, spare parts and national security each need different evidence, such as a certificate reference, a supply contract or a specification showing the item replaces an identical component. The output is an exclusions log that can be shown to a market surveillance authority. An exclusion without a reason on file is not a finished exclusion.
Review remote data processing dependencies
Architects trace each in-scope product's functions and identify any remote processing that is designed by or under the responsibility of the manufacturer and without which the product could not perform one of its functions. Separate web applications that users access only through a browser, which Commission guidance C(2026) 5252 treats differently, from backend services that the product depends on. Record each dependency, its owner and whether it is a cloud service the company operates or a third party's service. The output is a dependency map linked to each product row. Confirm the guidance wording with counsel before relying on it for a boundary case.
Confirm the category and the conformity route
For each in-scope product, the team checks whether it falls within the Annex III important classes or Annex IV critical categories, using the Commission's technical descriptions and the Article 7(4) implementing regulation. Products outside those lists are default products. The output is a category field per product that determines whether self-assessment under module A applies or a notified body is needed. This classification is an input to the compliance plan, and it should be confirmed with the notified body or a legal adviser before anyone commits budget.
Obtain legal sign-off on the scope record
Legal counsel reviews the register, the test sheets, the exclusions log and the dependency map as one package. Counsel confirms the reasoning on boundary cases, such as hosted services, open-source releases and products that are only partly in scope. The output is a dated sign-off memo that names the products covered, the exclusions relied on and the open questions. Keep the memo with the register so that the reasoning survives staff changes. An auditor or authority will ask for the record, not for an account given from memory.
Set a review trigger for substantial modification
Because products placed on the market before 11 December 2027 fall under the regulation only if they are substantially modified from that date, the team defines what counts as a substantial change for each product line and who must be told when one is planned. Product management, engineering and legal agree on the trigger and add it to the change process. The output is a written trigger rule and a named owner for each product. Re-run the Article 2 tests whenever the trigger fires, and keep the Article 14 reporting obligations in view, since they apply to in-scope products whenever they were placed on the market.
Scope evidence that holds up at review
An assessor or market surveillance authority will test Article 2 Scope by asking which products you placed on the market, why each one is in or out, and how you know. The six artifacts below answer those questions, and each one needs an owner and a trigger for review so it stays accurate between reviews.
Product inventory with intended purpose
List every product, version and software or hardware component you make available, with its intended purpose and reasonably foreseeable use written in plain terms. Article 2(1) turns on whether a data connection is part of that purpose, so the inventory should record the connection type for each entry. Review it at every release and whenever a new product line or market is added.
Written scope memo per product
For each inventory entry, record a short memo that states whether the product is a product with digital elements, which Article 2 limb applies, and what the default, important or critical classification is. Name the person who approved the decision and the date. Re-open the memo when the intended purpose, connectivity or distribution model changes.
Data connection diagrams
Draw how each product connects to devices, networks or services, both directly and indirectly, including pairing apps, update channels and cloud back ends. Assessors use these diagrams to test whether a logical or physical connection exists at all. Keep them under version control next to the code or hardware design they describe.
Exclusion rationale records
Where a product or component is excluded because of a medical device, vehicle, aviation, marine, spare part or national security rule, record the exact exclusion relied on and the evidence behind it. Include the boundary between excluded and covered functions. Review the record whenever a regulated certificate, contract or end use changes.
Remote processing register
List each remote data processing service your product needs to perform one of its functions, the team responsible for it, and where it runs. Separate these from browser-only web applications that the Commission guidance treats differently, and record the reason for each decision. Refresh the register whenever a backend service is added, moved or retired.
Change log tied to substantial modification
Keep a dated log of changes to hardware, software, configuration and connectivity, with a substantial modification assessment for each change. Products placed on the market before 11 December 2027 fall under the regulation only if substantially modified from that date, so this log is how you show whether a change crossed the threshold. Assign a reviewer for every entry and link each one to the scope memo it affects.
What a scope assessment costs in money and effort
This table breaks down the cost components of deciding whether and how the Cyber Resilience Act applies to your products, who is paid for each, and whether the cost is one-time or recurring. Use it to build a written scope and to check what each quote covers before you agree to it.
| Cost component | Who is paid or who spends time | One-time or recurring | Drivers and what to ask for in a quote |
|---|---|---|---|
| Internal product and legal time | Your product owners, legal and compliance staff | One-time, then recurring at each product change | Driven by product count and how many features are in scope. Ask the provider to list the internal inputs they expect from you and the review points they will sign off. |
| External legal or regulatory review | Outside counsel or regulatory advisers | Usually one-time, with occasional follow-up | Driven by the number of exclusions you claim, such as medical, vehicle, aviation or marine products, and by unresolved questions in the guidance. Ask whether the review covers each exclusion you rely on and who writes the final memo. |
| Engineering time to map data connections | Your engineers, or an implementation partner for your systems | One-time mapping, recurring updates with releases | Driven by the number of products, interfaces, cloud back ends and third-party services. Ask for a written inventory method and the list of systems the mapping will cover. |
| Remote back end analysis | Your cloud and platform engineers | One-time, then recurring when architecture changes | Driven by how much processing happens remotely and whether it is needed for a product function. Ask the provider how they will decide whether each remote service is remote data processing under Article 3(2). |
| Classification and category check | Your product team with legal or compliance review | One-time per product, recurring when a product changes | Driven by whether a product may fall in Annex III or Annex IV. Ask what evidence will be used to place each product in a category before any conformity route is chosen. |
| Periodic re-review | Your compliance owner, legal team and engineering leads | Recurring | Driven by new guidance, harmonized standards and product releases. Ask how often the scope will be rechecked, who triggers an update and how changes are logged. |
| Written scope document and record keeping | Your compliance team, with any partner preparing the document | One-time, then recurring updates | Driven by the number of decisions recorded and their supporting reasoning. Ask for the document format, version control and the approver named for each product. |
Scope mistakes that cause rework later
Most scope errors under the Cyber Resilience Act are not about whether a product is covered at all. They come from treating one part of a product as out of scope, or from assuming a scope decision made at launch still holds after the product changes. Each card below names a gap, why it matters under Article 2 and Article 3, and the check to run before the product reaches the EU market.
Treating SaaS as out of scope
A hosted service that users only reach through a browser is not automatically a product with digital elements. The question is whether the remote processing is designed by the manufacturer and is needed for the product to perform one of its functions, as Article 3(2) describes. Map each backend service to the functions it supports, and record the reasoning before deciding that the service sits outside the regulation.
Ignoring separately sold components
Article 3(1) covers software or hardware components placed on the market separately, so a firmware module, plug-in or companion gateway sold on its own can carry its own obligations. Teams often scope the flagship product and miss the add-ons that ship through a different catalog or channel. Inventory every item sold with a digital element, including accessories and optional modules, and assess each one.
Assuming sector exclusions cover every module
The exclusions for medical devices, vehicles, aviation and marine equipment under Article 2(2) to (4) apply to the products those sector rules cover, not to every connected module built into them. A device may be excluded as a medical device while its separate software, companion app or networking module remains in scope. Confirm which component the sector regulation covers and document the boundary between the two.
Missing the making-available test for free software
Article 3(22) treats supply for distribution or use in a commercial activity as making a product available, and that applies whether or not payment is taken. Free or open-source software published by an organization as part of a commercial offering can therefore fall within scope even though no price is charged. Check whether the software is supplied in the course of a commercial activity before concluding that it is outside the regulation.
Failing to re-check scope after modification
A product placed on the market before the application date may fall under the regulation if it is substantially modified, and a change in intended purpose or connectivity can alter the scope analysis even without a new version number. Teams that treat scope as a one-time launch decision often miss these changes in later releases. Set a trigger in change management that repeats the Article 2 analysis for every significant feature, connectivity or deployment change.
Who decides scope, who prepares the evidence and who checks it
Your organization owns the scope decision. Only you know what the product is for, how it connects to devices or networks, which features depend on remote services you operate, and whether it is placed on the EU market under your name or trademark. Article 2(1) turns on the intended purpose and reasonably foreseeable use, and those facts sit with product management, engineering and legal, not with an outside party.
- Product facts: Record the intended purpose, supported configurations and the data connections each one uses, both direct and indirect.
- Exclusion analysis: Decide, with legal counsel, whether medical, vehicle, aviation, marine, spare part or national security exclusions apply, and document why.
- Remote processing: Identify which backend services are designed by or under your responsibility and are needed for a product function, since Article 3(2) makes them part of the product.
- Market placement: Confirm who supplies the product for distribution or use in a commercial activity, including free-of-charge supply.
- Sign-off: Assign a named owner who approves the scope statement and revisits it when the product changes.
Confirm with counsel that the scope statement matches the product as it is actually sold and supported.
An implementation partner prepares the material that lets your team and an assessor see the product clearly. This includes inventories of components and connections, architecture diagrams, data flow records and evidence files. The partner works inside your environment and reports to your team. It does not decide whether the regulation applies, and it should not be asked to sign a legal conclusion on your behalf.
- Inventories: Build component and interface inventories that show every data connection the scope analysis relies on.
- Diagrams: Draw architecture and data flow diagrams that match the running system, including remote processing services.
- Evidence files: Collect configuration exports, build records and deployment records that support each factual statement in the scope memo.
- Gap notes: Flag facts that are unclear or missing so your team can resolve them before the decision is recorded.
- Change tracking: Update the inventories and diagrams when releases or deployment models change, so the scope position stays current.
Ask the partner to state in writing which parts of the scope memo are factual inputs and which parts are decisions reserved for your organization.
Independent checking is done by a notified body or conformity assessment body where one is required, or by a national market surveillance authority when it inspects a product. Under the market surveillance framework, these authorities enforce the regulation in their Member State, and they can ask for the reasoning behind a scope position. Their role is to test your decision, not to make it or to prepare it.
- Testing the facts: The checker compares the scope memo against the product as it actually runs, the documentation and the data flows.
- Testing the reasoning: The checker asks whether each exclusion was applied as written and whether the intended purpose is stated consistently across documents.
- Independence line: An implementation partner that prepared the evidence cannot also issue the independent assessment of the same product.
- Authority role: National authorities decide enforcement actions, and their interpretation of the regulation is shaped by the Commission guidance and the cooperation group.
- Retained records: Keep the scope memo, inputs and change history so a checker can trace each conclusion.
Confirm with your intended conformity assessment body which records it will need and how it treats evidence prepared by outside advisers.
Questions buyers ask about CRA Article 2 scoping
Can an in-house team complete CRA Article 2 scoping alone?
Yes, a capable in-house team can work through Article 2 scoping alone, provided it has the product knowledge and legal reading to support the conclusions. The test is whether the team can show, for each product, how it connects to a device or network, what its intended purpose is, and which exclusion (if any) applies. Outside help usually adds value where the product has unusual architecture, sits near a sector exclusion, or where the conclusion must withstand challenge from a customer or authority. Whatever the route, the organization owns the scoping decision. An implementation partner can prepare the analysis and records, but only the manufacturer can decide what falls within the regulation.
How long does a CRA scope review take?
The duration depends mainly on how many products are in scope for review, how many distinct architectures they share, and how quickly product owners can answer questions about data flows. A single product with a clear connection profile can be reviewed in a short working session, while a portfolio with shared cloud back ends and embedded components takes longer because each dependency must be traced. No researched timeline applies here, so ask any provider to state the expected duration in the written scope, listing the products, the number of workshops and the documents they will review. Because most engagements are fixed-scope, the agreed deliverables and dates should be fixed before work starts.
What does a scope review need from product and legal staff?
A scope review needs product managers and engineers to describe what each product does, how it connects to devices or networks, and which functions depend on remote data processing. Legal and compliance staff are needed to confirm how products are made available on the market, whether free distribution counts as a commercial activity, and whether any sector regulation or national security exclusion may apply. Specifically, the team should gather:
- Product descriptions, intended purposes and foreseeable uses
- Architecture diagrams showing data connections and cloud components
- Distribution and licensing arrangements, including open-source releases
- Sector certifications already held, such as medical or aviation approvals
The scoping record should name the people who approved each conclusion.
Is a SaaS product covered by the Cyber Resilience Act?
A SaaS product is not automatically covered, and the answer depends on how it runs and what it does for connected products. Commission guidance (C(2026) 5252, section 2.2) states that software that runs remotely and is only accessed by the user, such as a web application used exclusively through a browser, is not on that basis a product with digital elements. The position changes where the cloud service is remote data processing that supports a product's functions, meaning the product could not perform one of its functions without it. For example, an illustrative IoT device that depends on a vendor cloud service to operate would need that service assessed as part of the product. Teams should document this reasoning for each service rather than rely on a general statement about SaaS.
How are sector exclusions documented for CRA scoping?
Sector exclusions are documented by recording which product is excluded, which exclusion applies, and the regulation that supports it. Article 2(2) to (4) exclude products covered by the medical device regulations, the vehicle type-approval regulation, the aviation regulation and marine equipment under Directive 2014/90/EU. Article 2(6) and (7) cover spare parts and products developed exclusively for national security or defense. A clear record names the product, quotes the matched exclusion by article number, states the evidence (such as an existing certificate or approval), and notes the date and approver. Teams should also record products that are close to an exclusion but remain in scope, because an assessor or market surveillance authority may ask for the same reasoning.
What drives the cost of CRA scope work up?
Cost is driven mainly by the number of products, the complexity of their architecture and the number of exclusions that need careful reasoning. Costs rise when products share components or cloud services, when data flows cross many vendors, or when the organization has no current inventory of its software and hardware. Cost is one-time for the initial scope record, but it recurs when products are substantially modified, when new products launch or when exclusions must be re-checked. Organizations paying for outside help should ask for a written scope listing products, workshops, deliverables and the staff they need from each team, and should confirm whether the quote covers updates after the first review. No researched figure applies, so compare quotes on the written scope rather than on headline rates.
How DeployOpen prepares scope evidence for CRA reviews
DeployOpen's part in a Cyber Resilience Act scope review is preparation. Before any work starts, the team and the client agree in writing what will be examined: which products, product versions and deployment models are in view, which parts of each product are developed by the client, and which are supplied by third parties. The client then owns the scope decision. DeployOpen plans the work, documents the facts that bear on it and prepares systems and evidence so the client can show how each product was assessed against the Article 2 tests. DeployOpen does not issue scope determinations, legal opinions, assessments or certificates. Those remain the responsibility of the organization, its legal counsel and, where a formal review is required, the competent national authority.
The evidence package usually starts with a product inventory: a written record of each product or service, its intended purpose, the hardware and software it contains, and every data connection it has, whether direct, such as a Bluetooth or USB link, or indirect, such as a cloud API. For each connection, the record should state whether the remote component is a web application used only through a browser, which Commission guidance C(2026) 5252 treats differently, or remote data processing that the product needs to perform one of its functions. DeployOpen can help assemble these records from repositories, deployment manifests and architecture diagrams, and can flag gaps. The client should confirm each entry with the product owner, because only the manufacturer knows the intended purpose and reasonably foreseeable use.
Ask for three things in any quote: a named list of products and exclusions to be documented, the review deliverables with their format, and a statement of what the client must supply and approve, such as legal interpretations, market placement details and sign-off on the final scope memo. Budget for one-time preparation, then decide whether a retainer is needed for scope changes, new releases or substantial modifications, which can move a product into the regulation's scope. Confirm the final interpretation with qualified counsel or a notified body before relying on it.
