Does the CRA apply to your product? A 10-minute check

The most common first question I hear about the Cyber Resilience Act is also the most reasonable one: does this even apply to us? The answer is usually yes — the CRA has one of the broadest scopes of any EU product regulation — but "usually" is not "always," and the follow-up question of how it applies matters just as much.

Step 1: Is it a product with digital elements?

The CRA covers products with digital elements placed on the EU market — meaning any software or hardware product, and its remote data processing solutions, whose intended or reasonably foreseeable use includes a direct or indirect connection to a device or network.

In practice, that includes connected devices, embedded firmware, standalone software, mobile apps, and many industrial components. It does not matter whether your company is based in the EU — what matters is whether the product is sold there.

Some categories are carved out because they are covered by their own regulations: medical devices, civil aviation, motor vehicles under the type-approval regime, and certain marine equipment. If your product lives entirely under one of those regimes, your obligations come from there instead.

Step 2: Which risk class?

Most products fall into the default category, where the manufacturer can self-assess conformity. Two lists in the regulation's annexes define important products (class I and class II — things like password managers, VPNs, firewalls, and operating systems) and critical products, which face stricter conformity routes, up to mandatory third-party assessment or certification.

Getting the classification right early is worth real money: it determines whether you can self-declare or need to budget time and cost for a notified body.

Step 3: What role do you play?

Obligations differ for manufacturers, importers, and distributors — and if you substantially modify a product or sell it under your own name, you can inherit manufacturer obligations without realizing it. White-label arrangements deserve particular attention here.

The open-source question

Open-source software developed or supplied outside a commercial activity is not in scope, and the regulation created the lighter "open-source steward" role for foundations and similar organizations that support development. But the moment open-source components are integrated into your commercial product, their vulnerabilities become your responsibility — which is one reason the SBOM requirement exists.