A Four-Step Determination Method, with Case Studies on Semiconductors, Modules, SaaS, and T-Boxes
When an email arrives from an EU customer requesting “proof of CRA compliance,” most manufacturers’ first reaction is not to open the Regulation — it is anxiety: “Do I really have to pay a consultant just to find out whether I can even answer this question?”
Not necessarily. Determining whether a product falls within the scope of the CRA follows a four-step logic that most manufacturers can walk through on their own. Run through it first, establish roughly where your product lands, and then decide whether a formal gap analysis is worth commissioning — a far more time- and cost-efficient path than outsourcing the entire question at the outset.
This logic is not something we invented. It is distilled from the official text of Regulation (EU) 2024/2847 (the Cyber Resilience Act), combined with the practical experience consultants have accumulated helping manufacturers of every kind make this determination. Here is the breakdown, step by step.
The CRA applies to products made available on the EU market in the course of a commercial activity (Art. 2(1)). The operative concept is commercial value, not price: even a product supplied free of charge is a commercial activity if it serves a commercial purpose — harvesting user data, for instance, or bundling paid services. Conversely, products used purely for research and never circulated on the EU market drop out at this first step.
The CRA governs “products with digital elements” — legally defined in Art. 3(1) as software or hardware products and their remote data processing solutions, including software or hardware components placed on the market separately. Hardware products with embedded electronic components or firmware are covered. In other words, it is not only apps and system software: a home appliance with a built-in MCU, or a sensor shipping with firmware, can fall squarely within the definition.
The test is whether the product is capable of a direct or indirect logical or physical data connection to an external device or network — via Wi-Fi, Bluetooth, USB, or similar interfaces (this condition sits in Art. 2(1), the scope provision, rather than in the definitions). Any single connection capability is enough to satisfy this step. Products that are entirely isolated, with no external data exchange capability of any kind, are rare in practice — which is why most manufacturers find at this step that they are firmly inside the CRA conversation.
The CRA expressly excludes product categories whose cybersecurity requirements are already covered by other EU legislation (Art. 2(2)–(8)). The main exclusions are:
Two further categories are frequently mistaken for entries on the exclusion list, but they are different in kind — they are not excluded by the list; they never cross the CRA’s threshold in the first place:
One reminder before the case studies: belonging to a given industry does not mean automatic exclusion. The CRA does not recognize industries — it recognizes whether the product’s cybersecurity requirements are already covered by other EU legislation. Within the same industry, some products are excluded and others are not; each must be checked individually.
Two MCUs can land in dramatically different places. An MCU with tamper-resistant design — the kind used in bank cards and payment applications — falls under Important Class II, requiring third-party assessment by a Notified Body. A general-purpose MCU with only basic security functions and no tamper-resistance falls under Class I, where self-assessment is available — but only where the manufacturer fully applies the relevant harmonised standards; until those standards are cited in the Official Journal, that route is not yet open in practice, and a Class I product needing to demonstrate conformity in the meantime still has to go through a Notified Body. The distinction is not “whether it is a chip,” but the level of security functionality the chip carries. For semiconductor makers, the first task is to inventory the security positioning of each part number across the product line — not to make a blanket judgment at the company or product-line level. The matching vertical harmonised standards are handled by CENELEC (CLC/TC 47X): microprocessors and microcontrollers with security-related functionalities map to prEN 50765, their tamper-resistant variants to prEN 50766, and smartcard platforms and secure elements to prEN 50764 (a Critical category). All three have closed their public enquiry and are under approval — which is precisely why the Class I self-assessment route above is not yet practically available: the standards a manufacturer would need to apply in full are not yet cited in the Official Journal.
A communication module sold to multiple downstream brand customers exists, by its very nature, to exchange data with the outside world — Step 3 is all but automatically satisfied. Such modules generally need to obtain CRA compliance independently; a module maker cannot assume the downstream brand’s certification will cover it “on the way through.” The question this case most often raises: “Aren’t these modules already regulated under the RED — and haven’t we already completed EN 18031 certification? Under the Step 4 logic, shouldn’t coverage by another EU regulation mean exclusion?” That question lands squarely on the most easily misread special case in Step 4, and it deserves its own section — see below.
Pure SaaS is, as a rule, outside the scope of the CRA. But there is one critical exception: if removing the cloud service would cause the product’s security functions to fail — for instance, if the product depends on the cloud to receive security updates — then that cloud platform constitutes the product’s “remote data processing solution” (defined in Art. 3(2); Recital 12 illustrates the boundary with the example of a smart home device’s cloud-enabled remote control) and must be brought into the assessment scope together with the product. A practical recommendation: submit general-purpose apps or platforms for assessment separately from individual products, so that each new product launch does not force a reassessment of the entire platform. On the standards side, cloud components and general software map primarily to the horizontal EN 40000 series; where the software itself belongs to a specific category (operating systems, browsers, password managers, and the like), ETSI is drafting corresponding vertical standards in the EN 304 6xx series.
Vehicles covered by EU type-approval legislation (Regulation (EU) 2019/2144) are excluded from the CRA — but that exclusion does not necessarily extend to components. If a T-Box is manufactured independently and sold externally to multiple vehicle makers, it may still need to obtain CRA compliance on its own. “Parent product excluded” does not mean “component excluded” — the same logic as in our article on reporting obligations: whether a component is in scope is an independent determination. There is no dedicated vertical standard for T-Boxes; the horizontal EN 40000 series applies — while the communication module and security chip inside a T-Box may each map to the module and semiconductor standards discussed above.
The exclusion logic in Step 4 rests on one premise: the EU has chosen to leave another piece of legislation in charge. Medical devices belong to the MDR/IVDR; vehicles to type-approval legislation; aviation and marine equipment to their own regimes. In those sectors, cybersecurity requirements remain covered by the original legislation, and the CRA expressly steps aside.
The RED took the opposite path. Rather than excluding radio equipment from the CRA, the EU decided to hand the RED’s cybersecurity requirements over to it. In February 2026, the Commission adopted Delegated Regulation (EU) 2026/339 (published in the Official Journal on 29 April), which repeals the RED cybersecurity delegated regulation (Delegated Regulation (EU) 2022/30) with effect from 11 December 2027 — the very day the CRA becomes fully applicable. A seamless handover, with no double obligation. In other words, the correct reading of “covered by the RED” is not “excluded from the CRA” — it is “your governing regulation is changing to the CRA.”
For manufacturers already within RED scope, the timeline runs as follows. From 1 August 2025, the RED cybersecurity requirements (Art. 3(3)(d), (e) and (f)) apply, with EN 18031 as the basis for presumption of conformity (EN 18031-1/-2/-3 were cited in the Official Journal by Commission Implementing Decision in January 2025, subject to certain restrictions). From 11 September 2026, the CRA’s Article 14 reporting obligations take effect, and the two regimes enter a parallel period — the same module must maintain EN 18031 compliance while also meeting CRA reporting obligations. On 11 December 2027, the RED cybersecurity delegated regulation is repealed and the CRA takes over in full.
Investment already made in EN 18031 certification does not reset to zero. The three parts of EN 18031 (network protection, personal data protection, financial transaction security) overlap substantially with the technical requirements in CRA Annex I, Part I — access control, encrypted communications, secure update mechanisms, secure default configurations — so existing technical controls and test evidence are ready-made starting material for the CRA technical documentation and gap analysis. But the CRA’s newly added obligations are genuinely new: vulnerability handling processes and a CVD policy, the Article 14 reporting obligations, SBOM, and the support period commitment — none of which EN 18031 covers.
One further point on the timeline: after 11 December 2027, conformity will be demonstrated primarily against the CRA harmonised standards rather than through EN 18031’s presumption of conformity. Those standards are still in development – both the horizontal series applicable to all products with digital elements (EN 40000, whose generic technical requirements part, EN 40000-1-4, is understood to draw on the technical groundwork of EN 18031, according to the direction CEN/CENELEC has signalled) and the category-specific vertical standards (the ETSI EN 304 6xx series for software and networking categories; EN 50764–50766 from CENELEC for semiconductors). Because the harmonised route continues to build on the same technical base, the work done under EN 18031 stays directly usable — what changes is the legal basis on which conformity is demonstrated, not the underlying engineering.
Finally, this section illuminates another group of readers: manufacturers whose products have no radio interface at all — wired-only devices and pure software. These products were never within RED scope, have never faced EU product cybersecurity legislation, and are therefore the most likely to assume “cybersecurity compliance has nothing to do with us.” The CRA is technology-neutral: once the four steps confirm a product is in scope, this will be the first time EU product cybersecurity law catches them — with no existing certification to build on, which makes early stocktaking all the more important.
Misconception 1: “My product is an older model — it should be exempt.” Legacy products already on the market and never substantially modified are indeed unaffected. But the moment a substantial modification is made, the modified version must comply. “Older model” is not a permanent exemption — it is a status that expires with the next significant revision.
Misconception 2: “Customs didn’t stop my shipment, so I should be fine.” Customs inspection is merely one checkpoint at the point of import. Once a product is on the EU market, Member State market surveillance authorities can still carry out spot checks — responsibility does not vanish because the product got past customs.
Misconception 3: “The customer downloaded it from a US website — that’s not the same as the EU version.” CRA applicability has nothing to do with the download source. As long as the product circulates on the EU market with commercial value, it falls within scope — no matter which website, or which region’s distribution channel, the user obtained it from.
Scope determination is just step one. Once a product is confirmed to be within CRA scope, a sequence of further work follows: confirming the product’s risk classification (Default, Important, or Critical), selecting the conformity assessment module (self-assessment or third-party assessment), and building the internal processes required by the vulnerability reporting obligations — which other articles in this series cover in detail.
If you have walked through the four steps and still cannot pin down where your product lands — or if you have reached a conclusion and would like a professional second opinion — we’d be glad to talk it through. You are also welcome to join the in-person seminar in Taipei on Friday 18 September, where you can put questions directly to a CRA expert from Spain and learn more about planning for 2027 compliance and estimating the time and cost of implementation. Registration: Register for the seminar
Q: How do I tell whether a product falls within CRA scope? Check it in four steps: (1) is it made available on the EU market with commercial value; (2) does it contain digital elements; (3) is it capable of exchanging data with the outside world; (4) does it fall on the exclusion list (medical, vehicles, aviation, marine use and the like)? If the answer to the first three steps is yes and to the fourth no, the product is in scope.
Q: Does pure SaaS need the CRA? Pure SaaS is not, as a rule, a “product” as the CRA defines one, and sits outside the scope. But where it constitutes a product’s remote data processing solution — take it away and the product’s security functions stop working — it is pulled into that product’s assessment scope.
Q: Our product already conforms to the RED / EN 18031 — do we still have to do the CRA? Yes. “Covered by the RED” does not mean “excluded from the CRA” — the RED’s cybersecurity requirements hand over to the CRA on 11 December 2027. Existing EN 18031 technical controls and test documentation remain usable, but the obligations the CRA adds — vulnerability handling, SBOM, reporting, the support period — still have to be filled in.
Q: Do legacy models need CRA conformity? The essential cybersecurity requirements do not apply retroactively to legacy products already circulating on the market that have not been substantially modified. However, once a substantial modification affecting security functions is made, that version onwards must comply with the CRA; the Article 14 reporting obligations, by contrast, take no account of the placing-on-the-market date and apply across the board.
All legal provisions and dates cited in this article are based on the following official documents:
By the Secure Vectors Surveillance Inc. (SV Surveillance) × Applus+ Laboratories consulting team
* This article is regulatory commentary, not legal advice. Final scope determinations for individual products should be based on the official EU texts and the interpretations of the competent authorities.
