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. Charging for it, monetising services around it, or conditioning its use on the processing of personal data can change that. 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?

Downloaded applications, locally installed clients, CLIs and SDKs, browser extensions, firmware, agents, installers — and software your customer runs on their own infrastructure: on-prem server builds, container images, VM appliances.

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. If your desktop or mobile application is useless without your API, that API is part of the product.

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?

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.

It also tells you what flips a browser app into scope: wrapping it in Electron, Capacitor or Tauri, shipping it through an app store, anything that turns a URL into an artefact the user acquires and controls. Installability via a web manifest is the grey middle. A home-screen icon is still a shortcut to a cache you control, so I would say still out, but it is the closest call here and not one to rely on without writing down why.

One honesty constraint. This principle is my explanation of why the line falls where it does. It is not a test written in the Regulation and no market surveillance authority will cite it. The legal test is whether the product is placed on the market, read against the Article 3(1) definition. What the principle offers is a way to reason about cases nobody has ruled on, and it predicts the settled cases well enough to be worth trusting on the unsettled ones. Do not mistake it for clearance.

And one thing that holds whichever way this resolves. Near-term exposure is Article 14 reporting, not 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. That asymmetry makes "probably out, but filing-ready anyway" the honest position for anything near the line.

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. Fifteen days for critical and thirty for high is defensible if you meet it and can prove it. An undocumented intention to be quick is not.

A filing runbook with named people. A 24-hour clock does not survive an ambiguous escalation path discovered at 2am on a Saturday.

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. Whatever you do not record is unrecoverable.

None of it blocks the September work, which needs no standard, no notified body and no finished platform. 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.
• Cyber Resilience Act policy page and CRA reporting obligations — European Commission.
• CRA implementation timeline — European Commission, for standardisation and platform milestones.