The CRA Clock is Ticking For UK Manufacturers

With the first major reporting deadline under the EU Cyber Resilience Act (EU CRA) approaching on 11 September 2026, manufacturers can no longer treat cyber-security as a point-in-time exercise or a problem to be addressed after a product has shipped.

 

It’s a fact that the UK is outside the EU. But the commercial reality is, where UK-designed or UK-manufactured products are sold into the EU, the CRA will become a market access requirement. The UK’s Product Security and Telecommunications Infrastructure (PSTI) regime has applied to consumer connectable products since April 2024, putting baseline security, vulnerability reporting and declared security update on manufacturers’ agendas.

 

The CRA goes further, establishing sustained accountability throughout the product lifecycle. For manufacturers of embedded and connected systems, this is not simply a new reporting requirement. It challenges how products are designed, governed, updated, and supported.

 

The organisations best positioned to respond will be those that treat cyber-resilience as an engineering and governance discipline, rather than a documentation exercise performed at the end of development.

 

The First Operational Test

From 11 September 2026, the EU CRA’s reporting obligations will apply to manufacturers of in-scope products with digital elements (such as robotics systems, industrial automation equipment, rail and energy systems, connected devices, and the embedded software and components that support them). The broader requirements of the regulation become applicable on 11 December 2027, including essential cyber-security requirements, conformity assessment, and CE marking.

 

That sequence matters. The reporting deadline arrives before many will have completed their wider conformity programmes. It therefore acts as an early operational test of whether product, security, engineering, and legal teams can identify an actively exploited vulnerability or severe security incident, assess its significance, and escalate it within the required timeframe.

 

Manufacturers must be able to issue an early warning within 24 hours and a more complete notification within 72 hours. That demands more than a reporting template; it requires reliable product inventories, software visibility, vulnerability monitoring, clear internal ownership, and a defined path from technical assessment to regulatory decision-making.

 

The implications extend into the supply chain. Modern products may incorporate operating systems, open-source packages, third-party libraries, and software supplied by multiple vendors. Manufacturers cannot assume that a vulnerability in one of those components is solely the supplier’s responsibility. They need sufficient visibility to understand which products are affected, evaluate the risk, and coordinate an appropriate response.

 

For products placed on the EU market, the CRA therefore turns cyber-security into a market-access issue. It connects secure development, vulnerability handling, technical documentation, and lifecycle support to a manufacturer’s ability to continue placing products on the EU market.

 

Why Embedded Industries Will Feel the Pressure

The burden will be greatest in sectors where products combine long operational lifetimes, safety or availability constraints, complex software supply chains, and very limited tolerance for disruptive updates.

 

This is particularly relevant to industries central to the UK economy, including advanced manufacturing, industrial automation, defence and automotive. The operational impact of a security issue can extend well beyond the device itself.

 

In robotics, systems may operate for years in factories, warehouses, and other controlled environments, and a security update cannot be treated like a routine patch. An unsuccessful change could halt production, affect predictable behaviour, or require extensive revalidation. It is telling that 51% of developers surveyed for the Inside the Robot report identified cyber-security regulatory requirements as the most difficult standards to address.

 

Industrial automation presents a similar problem at a different scale. Operators may have large install bases containing equipment from different generations, with multiple software configurations and varying levels of connectivity. Reliability is often non-negotiable, yet every additional connection and dependency creates another potential path for compromise.

 

Rail systems introduce long certification cycles and feature assets expected to remain in service for decades. Energy systems may include remote equipment and critical infrastructure that must be monitored and maintained without compromising continuity of service.

 

Automotive is governed by its own sector-specific regulatory frameworks, but the engineering pressure is comparable. The implementation of frameworks such as UNECE WP.29 and ISO/SAE 21434 requires manufacturers to manage cyber-security as a continuous lifecycle activity, rather than a one-off development-stage task. Research highlights challenges around documentation, legacy-system integration, supplier coordination and maintaining threat analysis and risk assessment across complex supply chains.

 

Across these industries, the common characteristics are clear. Products are long-lived, the consequences of failure are serious, and there is very little room to get an update wrong. These are mission-critical systems in which cyber-security, functional safety, reliability, and operational continuity increasingly intersect.

 

Where the Operational Burden Accumulates

The challenge is not any one security control; it is turning security activities into a systematic, measurable, and documented operating model spanning product management, engineering, security, compliance, support, and the software supply chain.

 

Manufacturers need an accurate, current view of the software in every supported product. A software bill of materials (SBOM) can provide an important foundation, but producing an SBOM is not the same as maintaining software visibility. Component data must inform ongoing vulnerability monitoring, product-impact analysis, and remediation.

 

They must then determine whether a newly disclosed vulnerability affects their implementation. Manufacturers need to understand whether the vulnerable functionality is present, reachable, or otherwise exploitable in the context of the finished system. That assessment may involve internal teams, platform suppliers, open-source communities, and other third parties, all operating under a compressed reporting timetable.

 

Remediation creates another layer of difficulty. A security fix that is technically correct in isolation may still affect system behaviour, safety assumptions, or availability. The manufacturer must integrate, test, validate, and deploy the change without creating a new failure elsewhere in the product.

 

These difficulties are amplified by tightly coupled architectures. Where components have broad privileges or poorly defined boundaries, changing one part of the system can trigger extensive regression testing across the whole product. Legacy architectures, built before isolation, and controlled updates becoming central design requirements, make targeted remediation particularly difficult.

 

What begins as a software maintenance gap can become a security, delivery, lifecycle-cost, and market-access problem.

 

From Compliance Event to Resilience Discipline

The appropriate response is to move from compliance as an event to cyber-resilience as a discipline. The EU CRA requires secure products and repeatable processes capable of sustaining them over time.

 

Architecture does not prove compliance on its own, but it can determine how difficult compliance becomes to maintain. Isolation, least-privilege enforcement, modularity, and a reduced trusted computing base can limit what a compromised component can reach. Clear component boundaries can also support more focused remediation and validation when changes are required.

 

That distinction is important. Architecture is an enabler, not a substitute for product-level risk assessment, evidence, reporting, or conformity. Manufacturers remain responsible for the security and compliance of the finished product. However, selecting a platform designed for isolation, controlled privileges, and long-term evolution can reduce the technical complexity underlying that responsibility.

 

Software transparency must be combined with ongoing vulnerability management. Manufacturers need processes for monitoring relevant CVEs, assessing impact, coordinating with product security incident response teams (PSIRTs), and escalating reportable events. They also need secure update mechanisms, defined support periods, and plans for products that remain in operation beyond the standard lifecycle of individual software components.

 

Platform suppliers have an important supporting role. Manufacturers should expect clear product information, SBOM data where available, vulnerability advisories, coordinated product-security response, security updates, and well-defined lifecycle support options. These capabilities cannot make an end product compliant on the manufacturer’s behalf, but they can reduce uncertainty and help manufacturers build defensible, repeatable processes.

 

The Deadline Should be a Forcing Function

For UK manufacturers with EU market exposure, the September milestone should prompt manufacturers to test whether their monitoring, assessment, escalation, and reporting processes work at the speed the regulation requires. It should also expose weaknesses in software visibility, architecture, update mechanisms, support commitments, and evidence ownership before the wider EU CRA requirements apply in December 2027.

 

The strongest organisations will be those that make cyber-resilience part of how products are architected, governed, updated, and supported from the start. Not those that assemble the most paperwork when asked for it.

 

---

 

Harrison Parker is Regional Sales Manager EMEA at QNX 

 

Main image courtesy of iStockPhoto.com and MicroStockHub