Cyber Resilience Act Turns Device Security Into a Supply-Chain Duty

The EU Cyber Resilience Act is usually discussed as a deadline problem. Manufacturers of connected products have a date to work towards, a technical file to assemble, a conformity assessment to arrange and a CE marking to affix. Treating it that way is understandable, and it is also where many programmes will go wrong. The regulation's harder implication is architectural: it asks companies to show, for the life of a product, that security was designed in, that the components inside it are known and tracked, and that flaws will be handled long after the device has left the factory.

That moves security from a post-launch fix to a product-lifecycle discipline, with consequences for engineering teams, procurement, suppliers and the update strategies that decide whether a product can still be supported years after launch.

Scope that reaches past the finished device

The regulation covers products with digital elements, a deliberately broad category that takes in hardware and software alike, including embedded software and components rather than only the finished article sold to a customer. Some products already governed by other sector-specific European rules, such as medical devices or certain automotive systems, sit outside or partly outside the regime, but the direction of travel is clear: the unit of regulation is no longer just the box that ships.

The obligation lands on the entity placing the product on the market, yet the evidence has to come from further back in the chain. A manufacturer cannot credibly attest to the security of a component it has never examined, or promise to patch a dependency its supplier stopped maintaining two years ago. Importers and distributors carry their own duties, and even open-source stewards, given a lighter set of obligations, are not entirely outside the frame.

In practice this means obligations cascade. Contracts need to specify who fixes a vulnerability and how quickly. Procurement needs to ask questions it may never have asked. Engineering needs a record of what is actually inside a product, not what the original design document said it would contain.

Vulnerability handling becomes an operating capability

The most common misreading of the regulation is to treat it as a certification exercise: pass the assessment, receive the marking, move on. The requirements around vulnerabilities do not work that way. Manufacturers are expected to maintain processes for receiving reports, triaging them, developing and testing fixes, releasing updates and telling users what has changed. They need a coordinated vulnerability disclosure policy and a clear point of contact. They must also report actively exploited vulnerabilities and severe incidents to authorities within short statutory windows, and inform users without undue delay where appropriate.

That is an operational capability, not a document. It requires people, service levels and decision rights: who monitors incoming reports at a weekend, who decides whether a flaw warrants an out-of-band release, who drafts the advisory and who signs off on disclosure. A security team that has never run a disclosure inbox tends to discover that the process, not the fix, is the bottleneck.

The capability also has no natural end point. A product that sold well three years ago still generates reports, still receives updates and still needs someone accountable for it. Companies that map this work to a project team will find themselves rebuilding it every cycle.

Update commitments force architecture choices early

The regulation requires manufacturers to determine a support period for their products and to make it clear to users, which turns a vague marketing promise into a design constraint. Once a company commits to keeping a device patched for a defined number of years, a set of engineering questions becomes urgent: how updates are signed and how signing keys are protected over that period, how secure boot is rooted in hardware, whether a failed update can be rolled back, and whether the software stack can absorb years of dependency changes without a rewrite.

These decisions are cheap in the first months of a programme and expensive later. Key management that depends on one engineer is a liability across a decade-long support window. A monolithic firmware image with no recovery path makes every update a risk. A component chosen for cost alone may be unavailable, or unmaintained, halfway through the product's life.

Support also needs an ending. Good practice includes planning how customers are told that support is finishing, what safer defaults a device falls back to, and what decommissioning guidance is published. End-of-support handled badly becomes a security problem with a long tail.

Software bills of materials earn their place

Component inventories, often discussed as software bills of materials, are frequently dismissed as paperwork. Their value becomes obvious during an incident. When a widely used library turns out to be compromised, the operational question is which products in the field contain it, in which versions, and which of those are exposed. An accurate, machine-readable inventory turns that from a weeks-long archaeology project into a query.

The same record supports supplier management. Procurement can require an inventory and a disclosure commitment as conditions of doing business, and can track which suppliers are still maintaining the components they ship. The caveat is that an inventory produced once at release and never refreshed is a compliance artefact rather than a tool. Useful ones are generated from build pipelines, versioned, and kept current as dependencies change.

A European baseline with global reach

Few manufacturers build separate product lines for separate regulatory regions. Design decisions taken to satisfy European requirements tend to travel with the product, and the suppliers who serve European customers end up adapting their own processes to match. The United Kingdom's product security regime and voluntary labelling efforts in the United States point in a similar direction, so the practical effect is convergence around a common floor rather than a patchwork.

For component makers and software vendors outside Europe, that means the regulation becomes a design input even where no CE marking is required. Security documentation, update commitments and vulnerability reporting are becoming part of what it means to be a credible supplier.

The organisations that cope best with this shift are unlikely to be those with the largest compliance departments. They are more likely to be those that treat security as a property of the product and its supply chain, measured in how quickly a flaw is found, understood and fixed in the field. For the Global Tech Awards, which looks at innovation across the technology sector, that work deserves attention on its own terms. Secure-by-design engineering and lifecycle governance are not constraints bolted onto a product; they are part of what makes a connected device trustworthy, and increasingly part of what makes it competitive.