The Product Hat: Every Unit You Shipped Is Still Your Problem

The first blog in this series took the enterprise hat, where cyber risk turned into a board-level duty carrying personal liability and turnover-scale fines. This blog moves to the product itself, the connected device you shipped, and the liability that rides with every unit still running in the field.

The enterprise hat covers the company. The product hat covers the thing the company sells, and for a manufacturer of connected hardware that is a different and harder exposure. A software vendor ships a bug and pushes a patch. A hardware manufacturer ships a controller with updatable firmware into a substation, a factory, or a battery site, and that unit runs for a decade or more under someone else’s roof. The vulnerability you shipped in year one is still yours in year eight. This post is about that hat.

Where the exposure comes from

Two things make the product hat distinct from ordinary software liability.

The first is that the product is a cyber-physical system. When it fails, the consequence is not only lost data. A manipulated battery management system can drive a cell into thermal runaway. A spoofed setpoint can trip a process. The failure crosses from the digital domain into the physical one, which pulls product-liability law and safety regulation into a conversation that most software teams have never had to hold.

The second is the update channel. The same remote-update mechanism that lets you patch a fleet is a single point of control over every unit that trusts it. Compromise the channel and you do not have one vulnerable device, you have the entire installed base. The feature that makes a connected product supportable is also the feature that makes it a fleet-wide risk. That is the tradeoff at the center of the product hat, and it does not go away with better patch hygiene. It has to be designed for.

What the rules now require

The European Union’s Cyber Resilience Act, Regulation (EU) 2024/2847, is the first horizontal law that treats a connected product’s security as a condition of sale. It changes three things for a manufacturer.

It creates a reporting duty on the product itself. Under Article 14, when a manufacturer learns of an actively exploited vulnerability or a severe incident affecting one of its products, it has to file an early warning within twenty-four hours, a fuller notification within seventy-two hours, and a final report within fourteen days of a corrective measure being available. Reports go to the relevant national CSIRT and to ENISA through the CRA’s Single Reporting Platform. The clocks resemble the incident-reporting regimes on the other hats, but the trigger is different. It fires on a vulnerability in your product, discovered anywhere in the world, exploited in anyone’s deployment.

It requires a software bill of materials. The manufacturer has to produce an SBOM in a common machine-readable format, covering at least the product’s top-level dependencies, held in the technical documentation and available to market-surveillance authorities on request. The CRA does not force you to publish it, but it does force you to know what is inside your own product, which many manufacturers cannot currently answer for firmware assembled from years of third-party components.

It sets a support obligation. Security updates have to be provided and vulnerabilities handled across the product’s expected lifetime, with a support period generally of five years. That converts every shipped unit into a standing commitment. You cannot sell the device and walk away, and you cannot quietly end support because the product line was discontinued.

The timeline is close. The CRA’s reporting obligations apply from 11 September 2026, and the main obligations apply from 11 December 2027. A manufacturer that has not built the vulnerability-reporting process and the SBOM discipline by then is selling into the EU market out of compliance.

The failure mode

The failure mode on the product hat scales with the size of the fleet. A single defensible vulnerability in a single product, exploited across the installed base, becomes a fleet-wide liability event, a reporting obligation on a twenty-four-hour clock, and a market-access problem if the CRA conformity case falls apart. For a manufacturer whose products sit inside customers’ critical operations, that same defect also lands on the other hats, which later posts cover. The point here is narrower. The product you shipped is a liability you still hold, and the law now measures how well you hold it.

What to do about it

Three moves matter most.

Build the SBOM before the regulator asks for it. Start with the products still in production and work backward through the fielded base. You cannot report on, or patch, dependencies you cannot see. The SBOM is the foundation the rest of the product-security case stands on.

Treat the update channel as the crown jewel. Sign your firmware, protect the signing keys as carefully as you protect anything in the company, and design the update path so a compromise of one customer’s deployment cannot reach the fleet. The blast radius of the update mechanism is the single largest technical risk on this hat.

Stand up the twenty-four-hour vulnerability-reporting process now, not in 2026. The CRA clock is short, and the reporting decision, like the SEC materiality decision on the enterprise hat, is only survivable if the process already exists. Know who receives a vulnerability report, who decides it is actively exploited, and who files to the national CSIRT and ENISA.

The product hat is where a manufacturer’s engineering choices become legal exposure. But a company that also services what it sells wears a third hat, and it is the one that turns a single incident into a many-customer event. That is the subject of Part 3: the operator.

Next in the series:The Operator Hat. Maintenance, monitoring, privileged remote access, and the blast radius of a service platform.

This post is part of the Four Hats series. Get all four chapters in The Four Hats of Cyber-Risk Exposure eBook, or book a consultation about scoping a program that covers every hat.