Who the CRA actually covers: scope, exclusions and edge cases in plain language

The core rule

The CRA applies to 'products with digital elements' that are 'made available on the EU market' 'in the course of a commercial activity'. All three parts matter, and each has a plain-language meaning:

• ▸Product with digital elements: software or hardware that runs code — apps, games, plugins, libraries, firmware, devices. Including their 'remote data processing solutions' (your backend, when the product depends on it).
• ▸Made available on the EU market: EU users can get it. Selling from abroad through an app store that serves the EU counts. Location of your company is irrelevant.
• ▸Commercial activity: money is involved somewhere — price, subscription, ads, upsell to a paid service, monetised data. Genuinely free-and-nothing-else is not commercial.

The SaaS boundary (most misunderstood)

Pure cloud services — the user opens a browser, nothing installs — are not CRA products; they fall under NIS2 if you're big enough to matter there. The CRA reaches you through anything installable: the desktop client, the mobile companion app, the CLI, the on-prem version, the agent. Each installable artifact is a product in its own right.

The other reach: if your cloud backend is integral to a product's function (an IoT device useless without your API), the backend is assessed with the product as a 'remote data processing solution'.

The open-source exemption (second most misunderstood)

FOSS developed or supplied 'outside the course of a commercial activity' is excluded. Donations don't make it commercial. Foundation stewardship gets a light-touch regime. But dual licensing, paid hosting of the software, open-core paid tiers, or bundling the OSS into your commercial product all cross the line — for that supply, someone carries manufacturer obligations.

Corollary for companies: when you integrate OSS into your product, you own CRA compliance for those components. That's why every commercial vendor is suddenly interested in their dependencies' SBOMs and security posture.

Other exclusions and edge cases

• ▸Sector-regulated products: medical device software (MDR/IVDR), vehicles (UNECE R155), aviation, marine — excluded, their own stricter regimes apply.
• ▸Genuinely bespoke software built for one client's specifications: arguably not 'made available on the market'. Reuse it across clients and it is.
• ▸Internal tools never supplied outside your org: out of scope.
• ▸Spare parts that only restore functionality: out of scope.
• ▸Websites: a plain website is a service, not a product. A PWA packaged into app stores is a product.

Risk classes: does your product get extra scrutiny?

Roughly 90% of products are 'default class' — self-assessment, no notified body. Annex III lists 'important' products in two classes (identity management, browsers, password managers, VPNs, operating systems, routers, smart-home security devices… Class I; hypervisors, firewalls, tamper-resistant processors… Class II). Annex IV lists 'critical' products (smart meter gateways, smartcards, security boxes). Higher class = harder conformity route, same deadlines.

If you're unsure which class you land in, the free Risk Check walks the full Annex III/IV list in one question.