For years, cybersecurity law has mostly behaved like tort law after a car crash. It asked who got hurt, who failed to disclose, who failed to patch, who failed to notify, and who should pay. The European Union’s Cyber Resilience Act, by contrast, starts earlier in the story. It asks why the product was allowed onto the market in insecure form in the first place. With the European Commission’s March 3, 2026, draft guidance, that question is no longer theoretical. The guidance is meant to help companies apply the CRA in practice, with particular attention to scope, support periods, remote data processing solutions, free and open-source software, and the overlap with other EU rules. In other words, the law has moved from aspiration to operations.
The CRA itself is Regulation (EU) 2024/2847. It establishes horizontal cybersecurity requirements for “products with digital elements,” meaning it is not confined to one sector, one kind of company, or one narrow category of device. It covers hardware and software placed on the EU market and requires those products to be secure by design and by default, supported over their lifecycle, and backed by vulnerability handling and incident reporting obligations. The regulation entered into force on December 10, 2024. Its reporting obligations begin on September 11, 2026, and the main obligations take effect on December 11, 2027. That timeline matters because many companies still talk about CRA compliance as though it were a future abstraction. It is not. The transition clock is already running.
What the CRA does, at bottom, is shift cybersecurity responsibility upstream. It does not primarily regulate how a hospital, retailer, factory, or law firm uses a product after purchase. It regulates the manufacturer, developer, importer, and distributor who place the product on the market. The product must be designed to reduce exploitable vulnerabilities, shipped with appropriate security defaults, supported for an identified period, and accompanied by processes for coordinated vulnerability disclosure and reporting of actively exploited vulnerabilities and severe incidents. That is a major conceptual change. The old model tolerated insecure products and then regulated the damage. The CRA tries to regulate the insecurity itself.
That means the CRA will not just affect “tech companies” in the narrow sense. It will affect ordinary businesses whose products now contain code, sensors, chips, cloud hooks, mobile apps, remote management features, or AI components. A company that once thought of itself as a toy company, appliance company, medical device company, industrial equipment maker, or consumer products company may suddenly discover that, in the eyes of the CRA, it is also a software lifecycle company. That is not a semantic change. It is an operating model change.
Take an everyday manufacturer of “smart” household products: Thermostats, baby monitors, connected doorbells, smart watches, or kitchen devices. Under the CRA, that company can no longer treat the software in the product as a marketing feature layered onto a hardware business. It has to know what software and components are in the device, maintain vulnerability management processes, define how long it will support the product, and be able to issue security updates during that support period. The Commission’s own description of the guidance uses exactly these kinds of ordinary connected products to make the point that digital elements are now part of daily life and therefore part of the regulatory problem. For such companies, compliance starts now with software bills of materials, secure development practices, patching infrastructure, and governance over third-party components.
Now consider a toy company. In the old world, the company worried about choking hazards, toxic materials, and product labeling. In the CRA world, once the toy has connectivity, microphones, cameras, a companion app, cloud access, or embedded software, cybersecurity joins the list of product safety issues. That means the company needs developers who understand secure coding, product managers who understand support periods, lawyers who understand regulatory overlap, and security teams who can run intake and triage for vulnerability reports. The practical business problem is that many such companies outsourced software development or treated the app as an accessory. The CRA makes that posture much harder to sustain because the legal obligation follows the product, not the organizational chart.
For companies that make products with integrated chips, the challenge is even more operational. Industrial controls, consumer electronics, medical wearables, routers, agricultural equipment, and vehicles frequently involve layered supply chains in which firmware, chipsets, operating systems, cloud services, and mobile interfaces come from different sources. The CRA effectively says that “we bought the module from someone else” is not the end of the inquiry. The manufacturer placing the product on the EU market still bears responsibility for conformity, vulnerability handling, and support. That pushes companies toward tighter supplier contracts, better component inventories, stronger update mechanisms, and more aggressive due diligence over embedded software. Supply chain opacity becomes a compliance problem, not just a technical annoyance.
Medical device companies face a particularly interesting convergence of safety law and cybersecurity law. Modern medical devices often depend on software, network connectivity, remote updates, and data exchange. A vulnerability can therefore become not merely a confidentiality issue, but a patient safety issue. The CRA does not replace sector-specific medical device regulation, but it adds a horizontal cybersecurity layer and, according to the Commission’s guidance, must be understood alongside other EU regimes. For a medical device manufacturer, that means security cannot be a post-market service issue delegated to IT. It must be integrated into device design, risk analysis, quality management, update planning, and vulnerability disclosure. The cybersecurity function and the product safety function are no longer separate islands.
Software developers, of course, sit at the center of this transformation. For them, the CRA means that secure development lifecycle practices move from “strongly recommended” to effectively mandatory for products in scope. Developers must know their dependencies, assess vulnerabilities, ship secure configurations, and support the software over time. It also means development teams need documentation discipline. A secure product that cannot demonstrate its conformity may have nearly the same regulatory problem as an insecure one. This is one of the least glamorous but most important aspects of the CRA: It rewards not only security work, but evidence of security work.
Artificial intelligence complicates all of this. The CRA is not the EU AI Act, and it does not purport to regulate AI as AI. But where AI is embedded in a product with digital elements, the cybersecurity of that AI-enabled product still matters. The Commission’s own materials explain that the CRA must be read in interplay with other EU legislation, including the AI Act. In practical terms, this means that companies adding AI features to existing products are not merely adding functionality; they are adding an attack surface, a model update problem, a data integrity problem, and potentially a new compliance intersection. An AI-enabled medical device, toy, customer support system, or industrial product may need to satisfy one regime for AI risk and another for cybersecurity resilience. That is not duplication so much as regulatory reality catching up with technical reality.
For U.S. companies, the usual temptation is to say that this is a European problem. It is not. Any company placing covered products on the EU market must comply, regardless of where it is headquartered. As a practical matter, many U.S. firms will not maintain separate “EU-secure” and “everywhere-else” product versions. They will harmonize upward. That is what happened with privacy after the GDPR, and the same dynamic is likely here. The CRA therefore functions not only as EU legislation but as a likely global design benchmark, especially for software publishers, device makers, and multinational manufacturers.
What should businesses be doing now? First, they need to decide whether they are in scope, and they should assume that if they sell a connected, software-enabled, or remotely managed product into Europe, the answer is probably yes. Second, they need a complete inventory of products, components, dependencies, and support obligations. Third, they need to identify who inside the company actually owns product cybersecurity: Engineering, product, legal, compliance, quality, security, procurement, and executive leadership all have pieces of it, which usually means nobody fully owns it unless the company makes that ownership explicit. Fourth, they need a vulnerability intake and triage process, because reporting obligations begin before the full 2027 compliance date. Fifth, they need supplier and contract remediation, since unsupported or opaque components become legal exposure points. These are not 2027 tasks. They are 2026 tasks.
In the future, compliance will look less like a one-time certification event and more like a continuous operating discipline. Companies will need recurring review of support periods, patching performance, incident handling, and product retirement. They will need to think harder before adding connectivity or AI features to products that do not have the organizational capacity to support them securely. One likely effect of the CRA is that some businesses will discover that the cheapest way to comply is not to make the product smarter, but to make it simpler. That may be frustrating to product marketers, but it is not irrational from a security perspective.
The role of cybersecurity professionals in this process is central, but it is also changing. Historically, many security teams were incident responders, auditors, or enterprise defenders. Under the CRA, they must become product architects, lifecycle advisors, and translators between engineering and law. They will need to help define secure defaults, evaluate threat models, assess supplier risk, design reporting pathways, and document conformity. They will also need to work with legal and compliance teams on what counts as a severe incident, an actively exploited vulnerability, a reportable event, and an adequate support period. Security people who cannot speak product, procurement, and regulation will be less effective in this environment.
AI will play a role here, too, but not as a magic compliance wand. AI can help with code review, vulnerability prioritization, SBOM analysis, anomaly detection, documentation drafting, and support triage. It can make already-capable teams faster. But it also creates its own governance and security questions. If AI is used to generate code, somebody still has to own the security of that code. If AI is used to automate triage or reporting, somebody still has to verify the output. In other words, AI can be a force multiplier in CRA compliance, but it does not eliminate the need for competent human judgment. If anything, it raises the premium on that judgment.
Is the CRA a good idea? Broadly, yes. The market has tolerated insecure products for too long because the cost of insecurity was pushed outward onto customers, hospitals, businesses, governments, and victims. The CRA tries to move those costs back toward the entities that design and profit from the product. That is sensible. The harder question is whether the compliance burden will be proportionate, especially for smaller firms and businesses that did not realize they had become software companies. The Commission’s March 2026 guidance expressly says it is trying to facilitate compliance for microenterprises and SMEs, which suggests regulators understand the burden problem. Whether they have solved it is another matter.
The deepest significance of the CRA is not that Europe has passed another cyber law. It is that Europe has decided product insecurity is no longer merely unfortunate. It is unacceptable. Once that principle is accepted, everything else follows: Development changes, procurement changes, supplier oversight changes, AI governance changes, and the job description of cybersecurity professionals changes. The companies that understand this now will have time to adapt. The ones that wait until December 2027 will discover that the CRA is not really about paperwork. It is about whether they know how to build technology responsibly at all.
