An engineering manager at a medical-device subsidiary somewhere in the APAC manufacturing belt has been told, with confidence, that the Cyber Resilience Act doesn’t apply to him. The reasoning is straightforward: medical devices are governed by Regulation (EU) 2017/745. Their products are CE-marked under MDR. The legal team has cross-referenced the CRA scope article and confirmed that medical devices are excluded. The CRA project he was assigned to lead has been quietly de-prioritised.
Then he reads Article 2 himself, slowly, and stops at paragraph (2). The wording isn’t “medical devices are excluded.” The wording is “this Regulation shall not apply to products with digital elements to which Regulation (EU) 2017/745 applies.” That phrasing has a hinge in it. Some of his product lines are full medical devices regulated end-to-end by MDR. Some are accessories, components, and standalone software products that are used with medical devices but don’t themselves carry MDR classification. The exclusion catches the first group. It does not catch the second.
That moment — the moment a confidently-asserted exclusion turns out to apply only to part of a product portfolio — is what Article 2 is for. It is the article that decides which other seventy articles you have to read.
§ 01Scope is not a fence. It’s three overlapping fences.
Most regulations have a scope article that does one job: define what the regulation applies to. Article 2 of the CRA does three things at once, and it does them in a structure where each one is a separate test that has to be passed. You are inside the CRA if all three tests catch you. You are outside the CRA only if all three tests release you.
The three tests are the product test (Art 2(1) read together with Art 3(1)/(2)), the conduct test (Art 2(1) again, focused on “made available on the market”), and the exclusion test (Art 2(2)–(7), with deliberate cross-references to other EU regulations). The instinct of most operators is to read Article 2 once and decide “in” or “out.” The correct posture is to read it three times, once for each test, and to record three separate answers.
Why this matters: the failure modes are different on each fence. A product-test failure means a thing isn’t a PwDE at all and CRA never engages. A conduct-test failure means the thing exists but you didn’t place it on the EU market in a way that triggers the regulation. An exclusion-test failure means the thing is a PwDE, you did place it on the market, but another EU regulation displaces the CRA for that specific product. These three exits sit at very different places in the legal landscape and can’t be reasoned about as one decision.
For an APAC manufacturer scoping a CRA programme, the practical implication is that “is my product in scope?” is the wrong question. The right question is three questions, asked separately: Is the thing a product with digital elements? Did we place it on the EU market? Is there a regulation-specific exclusion that applies? All three have to be answered before any conclusion is drawn.
§ 02The product fence: “made available on the market” is wider than it looks
Art 2(1) states that the Regulation applies to “products with digital elements made available on the market.” Two terms are doing the work: product with digital elements, defined in Art 3(1), and made available on the market, defined in Art 3(22) and Art 3(23). Both definitions are wider than their colloquial reading suggests, and the gap between the colloquial and the legal reading is where APAC manufacturers most often misjudge whether they are inside or outside the regulation.
The product term covers software or hardware, plus components placed on the market separately, plus the remote data processing solutions that are necessary for the product’s function. The product fence is wide; this gets covered in detail in the Article 3 commentary and the practical implication for Art 2 is simply that the fence catches more things than “the box we ship.”
The conduct term — made available on the market — is where APAC operators tend to underestimate the reach. Art 3(22) defines it as “any supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge.” The interesting words are “any supply,” “in the course of a commercial activity,” and “free of charge.”
“Any supply” means the conduct fence is not limited to direct sales. A free firmware download offered to EU users is a supply. A SaaS service offered to EU customers is a supply. A trial version of a connected device demonstrated at a trade show in Munich, then left with the prospect for evaluation, is a supply. The instinct that “we don’t sell directly to Europe, we sell to a distributor” doesn’t exit the conduct fence — the product still ends up made available on the EU market, just through one more hop.
“Free of charge” closes the most common loophole. Open-source projects, evaluation kits, freeware tools, free firmware updates — none of these are excluded by virtue of being free. The exemption for non-commercial open-source software comes through Recital 18 and the open-source steward regime in Article 24, not through Art 2’s conduct fence.
“In the course of a commercial activity” is the only narrow door. Art 2(7) explicitly excludes products with digital elements developed exclusively for national security or defence purposes. Beyond that, almost any product placed by a commercial entity, whether priced or free, paid or sampled, is on the inside of the conduct fence.
§ 03The exclusion fence: where partial sometimes looks like full
Art 2(2) through Art 2(7) list five categories of products that are excluded from CRA. Read carelessly, the list looks like a clean set of doors marked “not your problem.” Read carefully, every one of them has a hinge. The exclusions are regulation-specific, not product-category-specific. They release the product from CRA only to the extent that the named upstream regulation actually catches it. Where the upstream regulation catches part of a product portfolio and not all of it, Article 2’s release applies to the same partial slice. The rest stays inside the CRA.
Four cases worth working through.
Medical devices — Art 2(2). The exclusion applies to products with digital elements “to which Regulation (EU) 2017/745 [MDR] or Regulation (EU) 2017/746 [IVDR] applies.” A bedside patient monitor classified as a Class IIa medical device under MDR is squarely excluded. But a workstation software product that integrates with a hospital information system, displays patient data alongside other clinical data, and is sold separately from any medical device, may not itself be regulated under MDR. If it isn’t, MDR doesn’t catch it, and Art 2(2) doesn’t release it. The CRA applies to that workstation software, even though the company’s primary regulatory framework is medical-device regulation. Cybersecurity-only accessories, third-party connectivity gateways used in clinical environments, and pure data-management software products are common examples of items that sit in this gap.
Vehicles — Art 2(3). The exclusion targets products with digital elements that are type-approved under Regulation (EU) 2018/858 (vehicle type-approval) and the cybersecurity portions of UN Regulation No 155 / 156 attached to it. Type-approved vehicles and the components type-approved as part of vehicle homologation are excluded. Aftermarket telematics units that get installed into vehicles after type approval, third-party diagnostic dongles, fleet-management gateways that connect over the OBD-II port — these are not vehicle components for type-approval purposes. They are products with digital elements made available on the EU market and they are inside the CRA. The same logic applies in reverse: an OEM Tier-1 supplying an ECU that is type-approved as part of the vehicle is outside CRA for that ECU, but if the same supplier sells a related diagnostic tool to garages, the diagnostic tool is inside.
Aviation — Art 2(4). Civil aviation products covered by Regulation (EU) 2018/1139 are excluded. The framework that catches certified avionics, drones in the “certified” category, and air-traffic management systems is broad enough that the typical commercial aviation product is genuinely outside CRA. The interesting cases sit on the edges: drones in the “open” category and the “specific” category for which Regulation 2018/1139 does not impose product-level certification, ground-control-station software sold to commercial drone operators, drone aftermarket payloads. None of these is necessarily caught by the aviation exclusion, and several of them are ordinary IoT products that the CRA captures fully. APAC drone OEMs in particular cannot assume the aviation exclusion covers their consumer and prosumer lines.
Marine equipment — Art 2(5). The exclusion targets equipment covered by Directive 2014/90/EU on marine equipment — bridge electronics, navigation systems, and other equipment subject to Wheelmark certification on EU-flagged vessels. The same partial-exclusion logic applies here as in vehicles and aviation: only the equipment specifically caught by the marine equipment regime is excluded. Ancillary connected products that happen to be installed on vessels but aren’t covered by the Marine Equipment Directive are inside the CRA.
Defence and national security — Art 2(6) and Art 2(7). Products developed exclusively for defence purposes, or for national security, or for processing classified information are excluded. The word doing the work is exclusively. A product line developed primarily for commercial sale, even if it is later sold to a defence customer, is not excluded. Dual-use products that have both a commercial and a defence variant are inside CRA for the commercial variant. The defence exclusion is narrow and the language is intentional — the legislator did not want commercial cybersecurity to become unregulated by virtue of incidental military procurement.
The pattern that runs through all four categories is the same: the exclusion is a release valve, not a category boundary. Read each one as “is the upstream regulation actually catching this specific product?” If yes, CRA is displaced. If no, even when the company’s primary business is in the named sector, the CRA applies.
To make this concrete, here are the slices that stay inside the CRA in each of the four cases — the parts of a sector portfolio that an APAC manufacturer most often misses on a first read of Art 2(2)–(7):
Inside CRA, even in the medical-device sector: standalone clinical workstation software not regulated under MDR/IVDR; cybersecurity-only accessories sold separately from a medical device; third-party connectivity gateways used in clinical environments without their own MDR classification; pure data-management software products that handle clinical data but are not themselves medical devices.
Inside CRA, even in the automotive sector: aftermarket telematics and OBD-II dongles installed after type approval; third-party diagnostic tools sold to garages and fleet operators; charging-station software not type-approved as part of the vehicle; companion mobile apps that connect to a vehicle but are not part of the vehicle’s type-approval scope.
Inside CRA, even in the aviation sector: drones in the “open” and “specific” categories not subject to product-level certification under Reg 2018/1139; ground-control-station software sold to commercial drone operators; aftermarket payloads, sensors, and modules attached to drones; consumer-grade drones marketed as toys or photography devices.
Inside CRA, even in the marine sector: vessel-monitoring software not covered by the Marine Equipment Directive; aftermarket connected sensors retrofitted onto vessels; fleet-management platforms used by shipping operators; non-Wheelmark navigation aids sold to recreational and small commercial craft.
Inside CRA, even in the defence sector: dual-use products with a commercial variant; commercial-off-the-shelf hardware later repurposed for defence procurement without being “exclusively” developed for that purpose; the commercial side of any product line that has both a commercial and a defence version.
The discipline is to read every Art 2(2)–(7) exclusion paired with this question: which slice of my portfolio does the upstream regulation actually catch, and which slice does it not? The slice it doesn’t catch is the slice CRA does.
§ 04The grey zones: research, prototypes, non-commercial supply
The conduct fence has a small set of grey zones that come up often enough to deserve their own treatment. None of them are exclusions in Art 2; they sit in Recitals and in the boundary cases of “making available on the market.”
Pure research and development is the cleanest case. A product that is being developed, tested internally, and never made available to anyone outside the developing entity is not on the market and the CRA does not apply. The instant the product is supplied to anyone outside — even for testing, even free of charge — the question becomes whether that supply was “in the course of a commercial activity.” A purely academic research collaboration where a university partner receives a prototype for evaluation is, in most readings, not commercial activity. A beta-testing programme where a commercial vendor distributes prototypes to selected EU customers, even free of charge and even labelled “not for production use,” is much closer to commercial activity and is likely captured.
Prototypes shown at trade shows are a recurring grey case. Demonstrating a prototype on a stand — without leaving units with attendees — is generally not making available on the market. Handing a prototype to a prospect for further evaluation, with the expectation of a sales conversation, is closer to a supply. The colloquial “it’s just a demo unit” doesn’t exit the conduct fence on its own; the question is whether the unit was supplied for distribution or use.
Non-commercial open-source software has a partial answer in Recital 18. Pure individual hobbyist contributions, code shared among developers without a commercial relationship, and forks maintained by volunteers without monetisation generally fall outside “commercial activity.” Code maintained by an entity that derives commercial benefit from the project — even indirectly, even through paid services on top of the code — can be inside. The Commission Guidance circulated in February 2026 began clarifying these boundaries; the categories will continue to be refined through 2026 and 2027 as Commission FAQs and implementing acts arrive.
The practical takeaway for APAC operators is that the conduct fence has a thin layer of genuine exits but a thick layer of exits that look genuine and aren’t. “It’s a prototype,” “it’s only for one customer,” “we’re not selling it commercially yet” — each of these warrants a careful re-read against Art 3(22)’s “any supply … for distribution or use … in the course of a commercial activity” before being treated as an exit.
§ 05Article 2 is the article you have to answer before any of the others matter
The point of Article 2 is not to be read once and filed. It is the article that decides which other seventy articles you have to read. A product that the three fences release is a product for which Article 13’s manufacturer obligations don’t apply, Article 32’s conformity assessment routing doesn’t engage, Article 14’s reporting obligations don’t bind. A product that the three fences catch is a product for which all of those engage with full force.
The mistake the medical-device engineer at the start of this essay was about to make — quietly de-prioritising the CRA project on the strength of a confident exclusion claim — is the most expensive class of Article 2 misreading. It is expensive because it is silent. The product portfolio doesn’t arrive at a conformity assessment moment that forces the question. The question only surfaces when something else triggers it: a market surveillance information request, an Article 14 incident, a customer asking for an EU declaration of conformity for a product the company didn’t think needed one. By that point the runway to remediate is whatever is left of the calendar before December 2027.
The cheapest move — in legal cost, in operational cost, in time — is to do the three-fence analysis once, properly, for every product line, and to record the answer with the reasoning. For each product, write down: does the product test catch it? Does the conduct test catch it? Does any exclusion test release it? Three answers. The first two are usually yes; the third is the one that does the work. And the third has to be answered against the upstream regulation, not against a colloquial sense of “we’re a medical-device company.”
Article 2 is not throat-clearing. It’s the question every other article in the CRA presupposes you’ve already answered. Answering it badly is the cheapest way to get the rest of the regulation wrong.