US software and hardware vendors operate at home without a horizontal cybersecurity law for products. Security obligations arrive sectorally and mostly after the fact: the Federal Trade Commission treats unreasonable security as an unfair practice under Section 5 of the FTC Act, particular sectors carry their own regulators, and frameworks such as the NIST Secure Software Development Framework remain, for most vendors, voluntary. The EU Cyber Resilience Act is not that posture extended across the Atlantic. It is product-safety law applied to cybersecurity: a product with digital elements may not be placed on the EU market unless it meets essential cybersecurity requirements, carries the CE marking, and is supported with security updates for years after it is sold.1Regulation (EU) 2024/2847 (Cyber Resilience Act) [2024] OJ L 2024/2847. The shift is structural rather than procedural, and it is the kind of shift a US vendor tends to discover after a product is already shipping into the EU.
1. What Counts as a Product With Digital Elements
The threshold question looks deceptively settled. The Regulation applies to products with digital elements made available on the EU market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network, and it defines a product with digital elements as a software or hardware product and its remote data processing solutions. The reach of that definition is the first surprise. The remote-data-processing limb captures software designed and developed by the manufacturer, or under its responsibility, whose absence would stop the product performing one of its functions, which pulls cloud-delivered functionality inside the perimeter wherever a vendor's own product depends on it, even where the vendor thinks of itself as selling a service rather than placing a product on a market. The limb stops at the manufacturer's own product: a cloud service designed and developed outside the responsibility of a product manufacturer sits outside the Regulation, so the boundary between a regulated remote data processing solution and an unregulated standalone service turns on who built the service and whether the product can perform its functions without it. Components placed on the market separately are themselves products with digital elements, so a library, a module, or a firmware image can be in scope on its own terms.
Whether a US vendor is a manufacturer, an importer, or out of scope entirely turns on facts the Regulation does not resolve in the abstract, and the same corporate group can occupy all three roles across a single product line.
The exclusions complicate rather than clarify. Products to which the EU Medical Device Regulation2Regulation (EU) 2017/745 (MDR) [2017] OJ L117/1; excluded by Art. 2(2)(a) CRA. or the In Vitro Diagnostic Regulation3Regulation (EU) 2017/746 (IVDR) [2017] OJ L117/176. applies are excluded from the Cyber Resilience Act by Art. 2(2) CRA, on the theory that those regimes already address cybersecurity through their own conformity assessment. The exclusion runs by instrument coverage, not by sector, and that distinction is where the difficulty sits. A connected diagnostic that is a medical device sits under the MDR and outside the CRA, but a health or fitness wearable that falls outside the medical-device regimes is pulled into the CRA as an important product, and software that ships alongside a device yet is not itself regulated as a medical device travels with the Cyber Resilience Act rather than with the device framework. A US company that thinks of itself as a regulated medical manufacturer may find that parts of its portfolio answer to a cybersecurity regime it has not mapped.
A parallel boundary runs along the AI Act.4Regulation (EU) 2024/1689 (AI Act) [2024] OJ L 2024/1689, Art. 6, 15, 43. The Cyber Resilience Act draws that interface in Art. 12 CRA. A product with digital elements that is also a high-risk AI system under Art. 6 AI Act must meet the CRA essential requirements, and conformity with them is deemed to satisfy the AI Act's own cybersecurity requirement under Art. 15 AI Act to the extent the declaration covers it. The conformity-assessment procedure ordinarily runs through Art. 43 AI Act, except that important and critical products with digital elements that would otherwise be assessed under the AI Act's internal-control procedure are pulled back into the CRA procedures for the cybersecurity requirements. The result is that a single product can be assessed against overlapping requirement sets through procedures drawn from two regulations, and the answer to which procedure governs which requirement is itself a structural question rather than a formality. The obvious response, that satisfying one cybersecurity regime should satisfy the others, assumes the regimes are coextensive. They are not.
2. The Classification Fork: Self-Assessment, Notified Bodies, and Capacity
How a product demonstrates conformity depends on where it sits in a three-tier classification, and the tier is not always something the vendor controls. A product with digital elements that is neither important nor critical can be assessed by the manufacturer under its own responsibility, through the internal-control procedure built on module A of the EU's New Legislative Framework.5Decision No 768/2008/EC [2008] OJ L218/82 (conformity-assessment modules A, B, C, H). Important products with digital elements are divided into two classes, listed by category, and the route hardens with the class. For class I, the manufacturer may still self-assess, but only where it applies the relevant harmonized standards, common specifications, or a European cybersecurity certification scheme at an assurance level of at least substantial; where it has not applied them, has applied them only in part, or where they do not exist, a third party must be involved. For class II, a third party must always be involved, even where standards have been applied in full. Critical products with digital elements sit higher still: the Commission may, by delegated act, require them to hold a European cybersecurity certificate at an assurance level of at least substantial under the Cybersecurity Act.6Regulation (EU) 2019/881 (Cybersecurity Act) [2019] OJ L151/15 (European cybersecurity certification framework).
The category boundaries do heavy work, and they were settled only late. The Regulation sorts important products by core functionality, placing firewalls and intrusion detection or prevention systems in the higher of its two classes, and it left the detailed technical description of the class I, class II, and critical categories to a Commission implementing regulation adopted on 28 November 2025.7Commission Implementing Regulation (EU) 2025/2392 (technical descriptions of the important and critical product categories) [2025] OJ L 2025/2392. Even with the categories specified, the judgment at the edges remains. Classification turns on a product's core functionality rather than its ancillary or embedded features, so whether a particular product falls inside a listed category, and which conformity route follows, is a fact-specific call the vendor has to make and document.
Two practical constraints compress the timeline further. The self-assessment route for class I depends on harmonized standards, and the standards on which a presumption of conformity rests had not been cited in the Official Journal as of publication; the work programme the European standardization organizations adopted in response to the Commission's standardization request sets adoption deadlines of 30 August 2026 for the two horizontal standards on secure development and on vulnerability handling, 30 October 2026 for the product-specific standards, and 30 October 2027 for the remaining horizontal set of generic security requirements, six weeks before the Regulation applies in full. The third-party route, in turn, depends on notified bodies, and the framework for designating them only begins to apply on 11 June 2026, with Member States required to strive for a sufficient number by 11 December 2026. The pattern will be familiar to anyone who watched the EU Medical Device Regulation's notified-body bottleneck: the route a manufacturer is told to use can be unavailable in practice because the institutions that operate it are still being stood up. A product whose self-assessment depends on standards that do not yet exist, and whose fallback depends on bodies that are not yet designated, occupies a gap the Regulation's fixed dates do not acknowledge.
Underneath the procedural question sits a substantive one that the conformity label can obscure. The essential requirements in Annex I are not a one-time gate. They require a product to be made available without known exploitable vulnerabilities and to be secure in its default configuration, and they require the manufacturer to identify and document the product's components in an SBOM covering at least its top-level dependencies, a record that belongs in the technical documentation and reaches a market-surveillance authority on reasoned request rather than the customer, while the vulnerability-handling requirements run for the whole support period rather than ending at the point of sale. A manufacturer that treats conformity as a launch milestone misreads the obligation, because the duty to identify, remediate, and disclose vulnerabilities, and to keep the bill of materials up to date, persists for as long as the product is supported. The cybersecurity risk assessment that determines which requirements apply, and which are justifiably excluded, has to live in the technical documentation and remain defensible to a market-surveillance authority years after the product first shipped. And because a change that affects a product's compliance with the essential requirements in Part I of Annex I, or that modifies the intended purpose against which the product was assessed, counts as a substantial modification, and a substantial modification calls for the product's compliance to be verified and, where applicable, for a fresh conformity assessment, the conformity question reopens with significant functional updates rather than closing at first release. The recitals carve risk-reducing security updates out of that concept while leaving feature changes that touch compliance inside it, and for a vendor that ships continuous updates, where that line falls is a judgment of its own.
3. The Reporting Clock Starts First
The most immediate exposure is not the substantive requirement but the duty to report, and it arrives first. The Regulation as a whole applies from 11 December 2027, but the reporting obligation under Art. 14 CRA applies from 11 September 2026, fifteen months earlier, and it reaches the installed base: the transitional provision that spares products placed on the market before 11 December 2027 from the substantive requirements expressly withholds that relief from Art. 14 CRA. From 11 September 2026 a manufacturer that becomes aware of an actively exploited vulnerability in its product, or of a severe incident affecting the product's security, must notify both the computer security incident response team designated as coordinator and the European Union Agency for Cybersecurity, simultaneously, through a single reporting platform that ENISA is to operate.8Directive (EU) 2022/2555 (NIS2 Directive) [2022] OJ L333/80, Art. 12 (coordinated vulnerability disclosure; European vulnerability database). The clock is short and staged, and it forks at the end: an early-warning notification within 24 hours and a fuller notification within 72 hours on both tracks, then a final report no later than 14 days after a corrective or mitigating measure is available for an actively exploited vulnerability, but within one month of the incident notification for a severe incident.
For a US reader, the instinct is to map this onto familiar breach-notification machinery, and the mapping misleads. US notification regimes generally turn on a breach of personal data, run to state attorneys general and affected individuals on timelines measured in days to weeks, and trade in a vocabulary of harm to data subjects. The Cyber Resilience Act clock is not a data-breach clock. It runs on an actively exploited vulnerability or a severe security incident in the product itself, whether or not any personal data is involved, and it runs to cybersecurity authorities rather than to privacy regulators. The trigger is the manufacturer becoming aware, a standard the Regulation does not define with precision, and the content of the obligation reaches information a company may regard as acutely sensitive, namely that one of its products is being exploited in the wild. The Regulation builds in narrow grounds on which dissemination of that information can be delayed, which is itself a signal that the drafters understood the tension between mandatory disclosure to a network of national authorities and the security cost of circulating live exploit information.
Each operative term in that duty is a question rather than a given. What makes an incident severe, when a vulnerability counts as actively exploited, and the precise point at which a manufacturer becomes aware are the kind of thresholds that look clear until an actual event forces a same-day judgment under a 24-hour clock. A vendor with a global product will often learn of exploitation through a US security team operating on US assumptions about who to tell and when, and the Regulation inserts a parallel obligation to a European coordinator and to ENISA that does not wait for the domestic process to conclude. The staged notifications that follow then compound the coordination problem across legal, security, and communications functions that may not answer to a single decision-maker, and the assessment of whether the threshold was even crossed is one the company has to make and document in real time.
The stakes attach directly to this clock. Non-compliance with the essential requirements of Annex I and with the obligations in Art. 13 and Art. 14 CRA sits in the top penalty tier, exposed to fines of up to EUR 15 million or, for an undertaking, 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. A missed 24-hour notification is not a paperwork lapse; it is a breach in the same band as shipping an insecure product. For a US-listed vendor, the exposure does not stay in Europe. The same exploited vulnerability that triggers an Art. 14 CRA notification to ENISA can, on its own facts, raise a securities-disclosure question at home and a notice obligation under customer contracts, so a single event propagates across regimes that were never designed to be coordinated.
4. Where the Open-Source Steward Line Falls
The Regulation reaches open-source software, but it does so along a line that does not match how most US engineering organizations think about their dependencies. It creates a category that has no US analogue: the open-source software steward, defined as a legal person other than a manufacturer that systematically and on a sustained basis supports the development of specific open-source products intended for commercial activities and ensures their viability. Stewards include certain foundations and entities that develop and publish free and open-source software in a business context, including not-for-profit ones. They are subject to a deliberately light-touch regime under Art. 24 CRA: a documented cybersecurity policy, cooperation with market-surveillance authorities, and attenuated reporting duties under Art. 14 CRA, the vulnerability duty applying to the extent a steward is involved in development and the severe-incident duty only where the incident affects systems the steward itself provides for that development. A recital records that administrative fines do not apply to stewards for any infringement, though Art. 64(10) CRA states the derogation as an exception to the lower fine tiers rather than to the tier that carries the Art. 14 CRA duties a steward does bear; and, not being manufacturers, stewards may not affix the CE marking.
The line matters because of where it leaves everyone else. An individual or community maintainer contributing outside any commercial purpose is not a steward and not a manufacturer. A company that integrates open-source components into its own commercial product is a manufacturer, full stop, and inherits the vulnerability-handling obligations for the product in its entirety, including every integrated component, for the support period the Regulation requires the manufacturer to determine and which is to be no less than five years unless the product's life is shorter. The Regulation expects that manufacturer to have exercised due diligence on the components it integrates, including open-source ones, by checking matters such as whether a component bears the CE marking, receives regular updates, or appears in a vulnerability database. The difficulty is that this duty often has no contractual counterparty. A vendor cannot flow an obligation down to a volunteer maintainer with whom it has no agreement, and the due-diligence duty cannot be discharged by a clause in a contract that does not exist. The reflex that open-source risk belongs to someone upstream collides with a Regulation that places it on the entity that ships the finished product.
The awareness gap is itself a risk factor. Survey work across the open-source ecosystem has reported that 59% of developers who contribute outside any commercial activity are unsure whether the Regulation reaches their contributions at all, and that, among respondents reporting some familiarity with the Regulation, 56% do not understand the distinction between a manufacturer and a steward.9Adrienn Lawson and Stephen Hendrick, 'Unaware and Uncertain: The Stark Realities of Cyber Resilience Act Readiness in Open Source' (The Linux Foundation, March 2025). For a US vendor whose product rests on a deep dependency tree, the uncertainty is not academic: the legal characterization of each upstream relationship feeds into who carries the vulnerability-handling and reporting duty when a component is exploited.
5. Strategic Considerations
The questions that determine exposure are not the ones the Regulation answers on its face. The first is identity. Across a white-label arrangement, an original-equipment supply chain, or a cloud-delivered product assembled from several vendors' contributions, who is the manufacturer for a given product with digital elements, and does the same corporate group occupy that role for one stock-keeping unit while sitting as importer or distributor for another? The role assigns the duty, and the role is not always where commercial intuition places it.
The second is duration. A support commitment of at least five years, and longer where a product is expected to remain in use beyond that, is a multi-year obligation to keep handling vulnerabilities, and it behaves like a balance-sheet liability that US product-lifecycle and end-of-life practice does not ordinarily price. How that commitment is valued in a transaction, allocated across an original-equipment relationship, or honored when a product line is discontinued are questions that standard US templates do not reach, because the obligation they would need to allocate did not previously exist.
The third is the seam between regimes. Where a connected-health product or a high-risk AI system meets the medical-device, AI, and cybersecurity frameworks at once, where does each obligation begin and end, and which conformity-assessment procedure and which reporting calendar govern when they diverge? Satisfying one regime's cybersecurity expectation does not discharge another's, and the entity that has to reconcile the divergent calendars is the manufacturer, not the regulator. The fourth is the feedback loop into US law. An EU enforcement action, or a notified actively exploited vulnerability, can become a US-side disclosure or oversight question under securities rules, customer contracts, and directors-and-officers coverage that may not extend cleanly to foreign regulatory exposure. Whether that loop has been mapped before the event, rather than after, tends to determine how expensive the event becomes. Underlying all of these is the timing question raised by the staggered dates: what does a vendor do in the months when the reporting duty is live but the standards and notified-body capacity that the substantive route depends on are still arriving. These questions require analysis tailored to specific facts and commercial context.