Eight years after GDPR became enforceable, there are still companies explaining at conferences that the regulation “caught them off guard.” For people who like to describe themselves as disruptors willing to move fast and break things, the pace of adaptation to a known legal requirement is, let’s say, instructive.

cover

The same dynamic is playing out now with connected product security, except the stakes are higher because the attack surface is physically embedded in homes, hospitals, vehicles, and critical infrastructure. The EU’s Cyber Resilience Act (CRA), applying from September 2026, is the instrument that closes the gap.

In brief

  • The CRA requires security by design for all connected products sold in the EU, with auditable documentation and mandatory update support.
  • NIS2 already imposes visibility and provable security controls on manufacturers of connected products; the CRA extends these to cover the full product lifecycle including end-of-life.
  • PLD2, applying from December 2026, makes software a product in the legal sense, meaning whoever includes it in a product assumes liability for defects.
  • Together with DSA, DMA, DORA, and the AI Act, these regulations form what can reasonably be called a Digital Compact: a coherent framework that ends the era of connected products as accountability-free zones.
  • The practical consequence is the end of routinely shipping IoT hardware with hardcoded credentials, unencrypted traffic, and no update commitment, and getting away with it.

The problem the CRA is solving

The IoT security problem is not obscure. It has been documented, demonstrated, and exploited for over a decade. The Mirai botnet in 2016 made headlines worldwide by hijacking hundreds of thousands of cameras and routers with default credentials. Nothing structurally changed. Surveillance cameras with hardcoded passwords or no authentication at all remain trivially exploitable, as demonstrated repeatedly in conflict zones and criminal investigations alike. Modern vehicles contain telemetry components with documented vulnerabilities that researchers have been flagging for years without triggering any serious manufacturer response.

The reason nothing changed is straightforward: there was no reason for it to change. A manufacturer that ships an insecure connected product bears essentially zero liability when that product is exploited. The cost of the breach falls on the victim, the network operator, or the downstream service provider. The manufacturer keeps the revenue and the market share. Under those conditions, investing in security is a competitive disadvantage, not an advantage. You spend more, your product costs more, and the market buys the cheaper insecure alternative. The structural incentive problem explains this outcome, not a failure of individual ethics.

What the CRA actually requires

The CRA operates on several levels that, taken together, make the previous model unworkable.

First, security by design becomes mandatory rather than optional. A connected product must be designed from the ground up with security controls appropriate to its risk class. This is not a post-hoc assessment but an engineering requirement embedded in the development process.

Second, manufacturers must maintain auditable documentation of the product’s security posture throughout its lifecycle. This means maintaining a software bill of materials (SBOM), tracking known vulnerabilities in components, and demonstrating that identified vulnerabilities have been addressed in a timely manner.

Third, update support is mandated for a period commensurate with the product’s expected use. This is the formal end of planned obsolescence as a security strategy: you cannot ship a product, sell it for five years, and then announce that security patches are no longer available while the devices remain deployed and connected.

Fourth, end-of-life planning must be documented before the product reaches the market. If a manufacturer intends to stop supporting a product, users must be informed in advance and given reasonable options. The model where a company quietly exits a product line and leaves thousands of connected devices unsupported and unpatched in the field becomes legally untenable.

Critically, the CRA places liability not just on the legal entity but on corporate management. The people making decisions about security investment, or the decision not to invest in security, are personally in scope. This is the mechanism that actually changes behavior, because it moves the incentive structure from abstract corporate risk to direct personal accountability.

How it fits into the broader digital compact

The CRA does not exist in isolation. It is one layer in a regulatory stack that the EU has been building systematically over the past several years, and understanding it in isolation misses the architecture.

NIS2 covers organizations operating essential services and digital infrastructure, imposing incident reporting obligations and requiring demonstrable security controls across the supply chain. For manufacturers of connected products that feed into critical infrastructure, NIS2 and the CRA overlap deliberately: the CRA mandates security in the product, NIS2 mandates security in the operational deployment.

DORA, applying to financial entities since January 2025, introduced the logic of cascading supply chain obligations: a regulated financial institution’s security requirements flow down to every ICT supplier in its chain. This created a template that the CRA generalizes: product security obligations attach to the manufacturer and flow through the entire distribution chain to whoever places the product on the EU market.

PLD2, entering force in December 2026, completes the picture by making software legally equivalent to a physical product for liability purposes. A manufacturer that incorporates a third-party software component into a connected device assumes liability for defects in that component. The business model of assembling products from cheap, unvetted software components and disclaim responsibility for what they do becomes impossible to sustain. Practically, this also means the era of sourcing IoT components from manufacturers with no security track record and no auditable supply chain ends, because the importer who places the device on the EU market owns the liability.

The AI Act, DSA, and DMA complete the framework. The EU is establishing that technology does not operate in a legal vacuum, that the same principles of product liability, consumer protection, and market regulation that apply to physical goods and telecommunications apply to connected software-driven products. This is a belated application of existing principles to a sector that had managed to avoid them for an unusually long time, not a reinvention of how technology works.

The supply chain argument

The objection that gets raised repeatedly is supply chain complexity. Modern connected products are assembled from components sourced globally, often from manufacturers with no EU presence and no interest in EU compliance. A camera sold under a European brand label might contain firmware written in China, running on chips from Taiwan, with cloud infrastructure hosted in the United States. Where exactly does liability attach?

The CRA’s answer is clear: it attaches to whoever places the product on the EU market. The importer or distributor who brings a non-compliant product into the EU market is responsible if the original manufacturer is not addressable. This is the same logic that applies to product safety under existing EU frameworks. It does not make supply chain complexity disappear, but it does ensure that complexity cannot be weaponized as an excuse for impunity.

The practical effect is that sourcing decisions change. If incorporating an unvetted component means owning the liability for its security defects, the cost-benefit calculation for choosing the cheapest available option shifts. Security audits and supply chain due diligence stop being optional overhead and become necessary business practice. This has happened in other sectors when product liability frameworks were applied seriously. There is no structural reason it will not happen here.

The parallel with the EU Court ruling on platform editorial responsibility is worth noting. The European Court recently held that a platform which participates in content selection or shares in the revenue that content generates cannot claim neutral conduit status and falls within editorial liability frameworks. The logic is identical: you cannot design a system to extract value from a process and simultaneously disclaim responsibility for that process. Applied to connected products, the manufacturer who designed telemetry into a device to collect behavioral data and monetize it cannot then argue that the security of that telemetry is not their problem.

What changes in practice

For security practitioners, the CRA changes the conversation with product teams and management in ways that matter operationally. Vulnerability disclosure and patch management stop being best-effort activities that product managers can deprioritize. The SBOM requirement creates an auditable record that regulators can inspect, which means security debt becomes visible in a way that abstract risk assessments never were.

The compliance theater problem that plagued GDPR and, to a significant extent, NIS2, remains a real risk. An organization can technically satisfy the CRA’s documentation requirements without substantially improving the security of its products. The audit trail requirement creates at least the precondition for meaningful enforcement, but enforcement quality will determine whether the regulation achieves its intent or becomes another checkbox exercise.

The management liability provision is the most significant structural change. Security investment decisions that were previously framed as cost-versus-risk calculations become decisions where the downside includes personal legal exposure for the executives making them. This does not guarantee good outcomes, but it does change the incentive structure in a way that corporate risk framing alone never did.

FAQ

What does the EU Cyber Resilience Act require from IoT manufacturers?

The CRA requires manufacturers of connected products to implement security by design, maintain auditable logs of product behavior, provide regular security updates, and plan for responsible end-of-life, with liability extending to corporate management.

How does the CRA differ from NIS2?

NIS2 focuses on organizational security posture and incident reporting for operators of essential services. The CRA targets the products themselves, imposing obligations on manufacturers to build and maintain security throughout a product’s lifecycle.

What happens if a manufacturer ships a connected product that does not comply with the CRA after September 2026?

Non-compliant products cannot be placed on the EU market, and liability for security failures extends to the manufacturer’s management structure, not just the company as a legal entity.