Am I In Scope? The CRA Question Only Engineers Can Answer

Note on creation: This article was researched, written, and validated with the assistance of Claude AI. The author remains responsible for the interpretation and conclusions; the AI contributed to research, reasoning validation, structure, and clarity.

When the Cyber Resilience Act comes up in a small software company, the question goes to whoever is closest to being a lawyer. Sometimes that is an actual lawyer. More often it is the founder, on a Sunday, reading a compliance blog.

The question is "does this apply to us?", and the answer that comes back is shaped by what the company does. We're a SaaS company, so we're probably fine. We're B2B, so this is for device makers. We're two people, so there must be an exemption.

Every one of those is the wrong axis.

What decides it is not your business model, your headcount or your customer segment. It is where your code executes, what remains on the user's machine after they close the tab, and whether an API you wrote is load-bearing for something you shipped.

Those are architecture questions. The person who can answer them is the person who drew the diagram.

What the CRA actually is

Regulation (EU) 2024/2847 entered into force on 10 December 2024. It is a product regulation built on the CE-marking model, the same machinery that governs toys and machinery, not a cybersecurity framework in the sense that NIS2 or ISO 27001 are. That distinction does real work: obligations attach to a product being placed on the market, a one-time legal event, rather than to an organisation's ongoing operations.

The object it regulates is a "product with digital elements" — a software or hardware product and its remote data processing solutions, including components placed on the market separately. Around it sit four roles: manufacturer, importer, distributor, open-source steward. Almost all the weight lands on the manufacturer, and one company routinely holds different roles for different products.

Be a manufacturer for something and you owe the essential requirements in Annex I Part I, the vulnerability handling requirements in Annex I Part II, a conformity assessment, a CE mark, an EU declaration of conformity, technical documentation, a declared support period of at least five years, and incident reporting.

Two things that are widely misunderstood.

There is no SME exemption from scope, though there is narrow relief on the edges. Article 33 lets microenterprises and small enterprises file technical documentation in a simplified format, and Article 64(10)(a) removes the fine for missing the 24-hour early warning in Article 14(2)(a) or 14(4)(a). Note what that does not cover: the duty to report still stands, and the 72-hour notification, the final report and every other obligation remain fully enforceable. Medium enterprises get none of it. Open-source stewards fare better, being carved out of administrative fines altogether under Article 64(10)(b), though their underlying duties survive. A one-person company shipping a desktop application gets the same scope answer as a multinational.

Open source is not automatically out, and not automatically in. The CRA bites when software is supplied in the course of a commercial activity. Code published to a public repository without monetisation is generally not placed on the market. That shifts if you take money for the code, build a paid business on top of it, or make access conditional on users handing over personal data. Foundations and similar bodies may fall into the open-source steward role, which carries lighter duties.

Article 2 adds a short, closed list of sectoral exclusions, each existing because another instrument already carries the cybersecurity duty: medical devices and IVDs, motor vehicles under the type-approval Regulation (EU) 2019/2144, certified civil aviation products, marine equipment under Directive 2014/90/EU, and products built exclusively for defence or national security. An excluded product is regulated elsewhere, not unregulated, and the carve-outs are narrower than they look.

Two dates, and the one most coverage gets wrong

Between them sits a transitional rule that reads as more generous than it is. Article 69(2) says products placed on the market before 11 December 2027 are subject to the Regulation's requirements only if substantially modified from that date, which sounds like your existing catalogue is untouched. Article 69(3) takes it straight back for reporting: by express derogation, the Article 14 obligations apply to all in-scope products placed on the market before that date, modified or not.

The two rules run on different axes, and the consequence is sharp. A product you shipped in 2023 and have not touched since may never need a CE mark. It still generates a 24-hour clock from 11 September 2026 if you become aware a vulnerability in it is being actively exploited. Your installed base is in scope for reporting even where it is out of scope for the product requirements.

It is not retrospective: exploitation you already knew about before 11 September 2026 needs no late filing. From that date forward, the whole back catalogue counts.

The clock runs early warning within 24 hours of awareness, fuller notification within 72 hours, final report within 14 days of a corrective measure being available, or within a month of the 72-hour notification for a severe incident. You file once, through ENISA's Single Reporting Platform, which routes to your CSIRT and ENISA simultaneously. Article 14(8) separately requires you to inform impacted users, which is a different channel needing its own runbook.

"Awareness" is the trigger, and the Regulation does not define it. The Commission's July 2026 guidance does, more aggressively than teams expect: the point at which, after a prompt initial assessment, you have a reasonable degree of certainty that a vulnerability in your product is being actively exploited. You cannot stall the assessment to delay the clock.

The four questions that decide scope

1. Does the software execute on hardware the user controls?

Four shapes qualify. Things a user installs: desktop applications, installers, agents, browser extensions. Things a developer pulls into their own build: CLIs, SDKs, libraries. Things a customer deploys onto their own infrastructure: on-prem server builds, container images, VM appliances. And firmware, on hardware you sell.

If yes, continue. If no, you are almost certainly outside the CRA and under NIS2 instead.

2. Is it genuinely free and open source, published outside any commercial activity?

If yes, it is generally not placed on the market, with the caveats above. If no, you are most likely a manufacturer for it, and vulnerability handling covers the product in its entirety, including every component you integrated.

3. Does that product depend on a backend you built to do one of its jobs?

If yes, the backend comes into scope with it as remote data processing. The test to apply: switch your servers off and see whether the product still does what you sell it for. If it cannot, the backend is not infrastructure sitting behind the product. It is inside the product boundary.

Here is where most people go wrong, and it is worth being blunt: a backend is never an independent route into the CRA. Remote data processing is in scope only as a component of a product with digital elements. If nothing you ship executes on hardware the user controls, there is no product for the backend to attach to, and Recital 12 keeps cloud services designed outside the responsibility of a product manufacturer out entirely, with pure SaaS, PaaS and IaaS under NIS2. The misreading runs "remote data processing is in scope, we have a backend, therefore we are in scope", and the inference is backwards. Having a backend puts your backend in scope for a product that was already in scope for other reasons.

4. Which role do you hold, for each product separately?

Manufacturer, importer, distributor, steward. Answer it per product, not per company.

Your architecture, looked up

When the copy is a chip

Firmware is the plainest case in the table and the one most often skipped, because "we make hardware" sounds like a different conversation from "we ship software." It is not. A chip carrying your own firmware is a product with digital elements, and vulnerabilities in it are your vulnerabilities.

The complication is that some markets are carved out and some are not. Motor vehicles sit under the type-approval regime, marine equipment under its own directive, and both exclusions are narrower than they sound. The vehicle carve-out covers systems delivered inside an approved vehicle, so the same component sold separately into the aftermarket can stay in CRA scope. The same silicon lands in scope or out depending on which market the unit ships into and how it got there.

One consequence worth naming, because it is decided years upstream: security updates have to reach users free of charge for the whole support period. If the firmware cannot be updated in the field, the only way to deliver one is to send an engineer. Field-updatability is a compliance decision wearing an engineering hat.

Why the line falls where it does

The offline browser app is the case people get stuck on, and the usual arguments for putting it in scope do not survive scrutiny.

The first argument is that code executes on the user's device. But a plain React SPA already executes substantial code on the user's device and can persist data in local storage. Nobody thinks a plain SPA is a product with digital elements. Local execution cannot be the line, because it is already true of nearly every modern web application, and a test that catches everything catches nothing.

The second argument is that the app works offline, so a copy must have been transferred. That is closer, but still not the thing that matters.

Look instead at what the CRA's machinery is actually built to solve. Support periods of at least five years. Security updates that stay available for a decade. Technical documentation retained for ten years. Conformity assessment before the product goes out. Every one of those exists because of a single problem: once a copy of your software is in someone else's hands, you have lost the ability to fix it. You cannot un-ship a firmware image. You cannot force a customer to upgrade the container image running in their datacentre. You cannot make someone install your patch. That is why those products need a declared support window and a decade of records.

An offline-capable browser app has the opposite property. The service worker cache is browser-managed, evictable, versioned against your server, and replaced unilaterally the moment the user reconnects. You never lose control of the running copy. The support-period concept barely parses for it — what would "we support this version for five years" mean when you could not keep an old version alive if you tried?

The Commission's guidance arrives at the same place by a different route. Section 2.2 puts software in scope where it is supplied to the user and executes on the user's side, and outside where it executes remotely and is merely accessed. Web applications and progressive web apps accessed exclusively through a browser are the guidance's own worked example of what is not a product with digital elements. They enter only where they qualify as remote data processing supporting some other product, such as a back end an installed app cannot function without.

That is worth pausing on, because it means the service worker was never the deciding fact. A PWA with full offline caching, accessed through a browser, is out. The same codebase wrapped in Capacitor and pushed to a store is in. Nothing about the software changed. What changed is whether the user acquired a copy.

That one idea regenerates the whole table. Firmware, desktop apps, CLIs, SDKs, on-prem and container distributions: the user holds a copy and can pin an old version indefinitely, so in. Mobile apps and extensions: a held copy with store-mediated, declinable updates, so in. Web apps, offline-capable or not: you replace the running version unilaterally on next connect, so out. Headless APIs: nothing is handed over, so out.

Which means "PWA" is not a CRA category at all. Three deployment models shelter under that one word and they get three different answers. Accessed in a browser tab, service worker or not: out, and the guidance says so directly. Wrapped in Electron, Capacitor or Tauri and shipped through a store: in, because the user now acquires and controls a copy. Installed to the home screen from a web manifest: the grey middle, and the only one still genuinely open.

That middle case deserves a moment. A home-screen PWA launches from an icon rather than a tab, which strains the guidance's "accessed exclusively through a browser" wording. But it is still the browser engine rendering it, still a cache you replace unilaterally on next connect, and still nothing the user obtained from a store. My reading is that it stays out. It is the closest call on the list, and not one I would lean on without writing the reasoning down first.

One honesty constraint. The principle above is my explanation of why the line falls where it does, not a test written in the Regulation. The legal test is whether the product is placed on the market, read against the Article 3(1) definition and now Section 2.2 of the guidance. The principle earns its place by predicting where the guidance landed, and by extending to the cases the guidance does not name, which is most of them. Do not mistake it for clearance.

And one thing that holds regardless. If you land anywhere near the line, your near-term exposure is Article 14 reporting rather than conformity assessment, and reporting readiness is cheap: know which CSIRT covers your main establishment, get an EU Login account, name a primary and a backup authorised to file. Conclude you are out and be wrong, and you have missed a 24-hour clock with no process to fall back on. Conclude you are out and be right, and you spent an afternoon on a runbook you never use.

If you want a second read on your own product, cetome's CRAscoping.com takes a description of your architecture and returns a classification with the provisions it relied on. It is strongest on IoT, embedded and network products, which is where its authors work. Give it an accurate description rather than a marketing one: the words you use for your own architecture are what it reasons from, and "installable" is doing more work in that sentence than you might think. Treat the result as a structured second opinion, not a determination — the same way you should treat this article.

What being in scope actually costs

If the answer comes back "in", four things become engineering work rather than paperwork.

A software bill of materials. Annex I Part II(1) wants components documented in a commonly used machine-readable format, covering at minimum the top-level dependencies. Everything else in vulnerability handling runs on this artefact, and generating it is a build-pipeline change.

A remediation policy with numbers in it. Annex I Part II(2) requires vulnerabilities to be addressed without delay and sets no timeframe. What gets assessed is whether you set a policy calibrated to risk, followed it, and can show it. Pick numbers your release cadence can actually survive, two weeks for critical and a month for high being a reasonable starting point, then hold to them. A slower policy you can evidence beats a faster one you cannot.

A filing runbook with named people. Nobody works out who has authority to file while the clock is running. Settle it beforehand, name a primary and a backup, and write down what each of them actually does.

Decision records that survive a decade. Technical documentation and the EU declaration of conformity stay available to market surveillance authorities for ten years, or for the support period if that runs longer, and that includes the decisions not to act. The triage concluding a vulnerability was not exploitable in your product is exactly the record you will want later. A decision you never wrote down is, eighteen months on, a decision you cannot show you made.

None of this sits between you and the September deadline. Reporting readiness depends on nothing that is still being drafted. It is worth knowing where the ceiling sits, though: no CRA harmonised standard has yet been cited in the Official Journal, so the Article 27 presumption of conformity is unavailable and the Article 32(2) self-assessment route for Class I products cannot be relied on.

The diagram is the answer

The CRA scoping question gets asked as a legal question and answered by people who ask what your company does. It is not a legal question in any useful sense. It is a question about where your code runs, what the user is left holding, and which parts of your system stop working when the network does.

Sources

• Regulation (EU) 2024/2847 (Cyber Resilience Act), full text — EUR-Lex. Provisions relied on here: Arts. 2(2)–(4), 3(1), 3(2), 13, 14, 24, 27, 32, 33, 64(10), 69(2), 69(3), 71(2); Recitals 12, 18, 34; Annex I Part II (1), (2); Annexes III and IV.
• Commission guidance on the application of the CRA — C(2026) 5252, published 27 July 2026. Non-binding, but the clearest signal on scope, "substantial modification", support periods and the meaning of awareness. Section 2.2 is the one to read if you build web software: it is where web applications and progressive web apps are addressed directly.
• CRAscoping.com — cetome's CRA scoping tool. Useful as a second opinion, strongest on IoT, embedded and network products. My thanks to Cédric Lévy-Bencheton for the exchange that sharpened the browser-app section of this article.
• Cyber Resilience Act policy page and CRA reporting obligations — European Commission.
• CRA implementation timeline — European Commission, for standardisation and platform milestones.
• What the EU CRA actually asks of your engineering team — Arkadiy Kondrashov and Patrick Nack-Lehman, Kilo Blog, 19 August 2026. The piece that sent me to the Regulation in the first place, and the clearest engineering-facing account of the reporting mechanics I have read. This article takes a different line on scope, and a different view of the Article 69(2) / 69(3) interaction.