The Cyber Resilience Act and the plant floor: two obligations UK manufacturers keep confusing

A UK manufacturer that sells a connected machine into the EU now carries two distinct cyber obligations, and they almost never sit with the same person. One is about the product: the EU Cyber Resilience Act asks you to build security into what you ship, handle vulnerabilities across a defined support period, and report actively exploited vulnerabilities on a very short clock. The other is about the plant: keeping a production line running when the corporate network is compromised, which is a different discipline, with a different standard behind it and a different set of constraints.

Conflating the two is the most common and most expensive mistake we see in manufacturing. A company that has segmented its plant network properly can still be non-compliant on the product side, because no firewall rule has ever produced a software bill of materials or a vulnerability disclosure route. A company with a genuinely good product security programme can still lose a week of output to ransomware that arrived through a shared file server in the finance team. This piece separates the two, sets out what each actually requires, and shows where the work overlaps enough to be worth doing once.

Obligation one: the product you place on the EU market

The Cyber Resilience Act is EU product law. It entered into force in 2024 and applies to "products with digital elements" placed on the EU market: hardware and software that connects, directly or indirectly, to a device or network. That is a broad definition by design. It captures the obvious cases, such as a connected machine tool or a gateway, and the less obvious ones, such as the configuration software you ship on a USB stick with the machine, or firmware in a component you make for someone else's assembly.

Three roles carry duties. Manufacturers hold the substantive obligations: security by design, vulnerability handling, documentation, conformity assessment and reporting. Importers have to verify that a product they bring into the EU has been through the right process before placing it on the market. Distributors have to check that the marking and documentation are present and not to sell a product they know to be non-compliant.

The point UK engineering directors most often miss is that the obligation follows the product, not the company. Leaving the EU took the UK out of the Union's regulatory framework; it did not take UK goods out of the rules that apply to anything sold inside the single market. If your product reaches an EU customer, the CRA reaches your product. Routing sales through an EU subsidiary or a distributor does not dissolve the duty, it just rearranges who holds which part of it. Manufacturers established outside the EU are generally expected to have a representative inside the EU for these purposes, so part of the preparation is administrative rather than technical.

Two sets of dates matter, and only one of them is in the future.

Since 11 September 2026, reporting obligations have applied. A manufacturer that becomes aware of an actively exploited vulnerability in one of its products, or a severe incident affecting the security of those products, reports it through ENISA's Single Reporting Platform: an early warning within 24 hours, a fuller notification within 72 hours, and a final report later once the facts and the fix are settled. Those are calendar hours. If your products are in the field now, this duty is live now.

From 11 December 2027, the main obligations apply. That is the date the substantive requirements bite: the essential cybersecurity requirements, vulnerability handling across a support period, technical documentation, conformity assessment and CE marking. It sounds comfortably distant until you map it onto a product development cycle. A machine being specified in 2026 for launch in 2028 has to meet it, and architectural decisions taken this year decide whether that is a straightforward exercise or a redesign.

You can see both dates alongside the other deadlines in play on our regulation tracker.

What security by design and vulnerability handling actually mean

Stripped of the regulatory language, the CRA asks a manufacturer to be able to answer four questions about every product it ships.

What is in it? You identify and document the product's components and produce a software bill of materials in a machine-readable format, covering at minimum the top level of dependencies. This is the requirement that quietly reorganises an engineering function, because most embedded products are assembled from vendor SDKs, open-source libraries and components inherited from a supplier who has their own supply chain. The reason it matters is not neatness. When a serious vulnerability is published in a common library, the question "are any of our products affected?" has to be answerable inside the same 24 hours you have to file an early warning. Without an inventory, the honest answer is that you do not know, and a team starts reading source code under time pressure.

How was it built? The essential requirements expect products to be delivered without known exploitable vulnerabilities, with a secure default configuration, and with the attack surface reduced to what the product actually needs. In practice that means a documented secure development process: threat modelling at design stage, security testing before release, hardened defaults rather than hardened options, and a record that each of these happened. The documentation is part of the obligation, not an afterthought to it.

How do people tell you it is broken? You need a route for a researcher, a customer or an integrator to report a vulnerability, and a process behind that route that triages, fixes and communicates. A published policy, a monitored address and a named owner is the minimum viable version. The failure mode here is familiar: the report arrives at a general sales mailbox, sits for three weeks, and the researcher publishes.

How long will you fix it for, and how? Manufacturers have to provide security updates across a support period, free of charge, and make the end of that period clear to the buyer before they buy. The default expectation is five years, with the period reflecting how long the product is realistically expected to be in use: shorter where that is genuinely less, and longer for products with long service lives. That last point deserves a pause in an industrial context, because machinery is routinely in service for fifteen or twenty years. Committing to a support period is a commercial decision with an engineering bill attached, and it should be made deliberately rather than discovered at launch.

There is also a tiering question. Most products are expected to self-assess against the requirements. A defined set of more security-sensitive categories, set out in annexes to the regulation, requires more: either applying harmonised standards or involving an accredited third-party body, with a small critical tier facing the strictest route. Some categories familiar to industrial companies appear in those lists, including industrial automation and control systems, though the entries carry qualifications about intended use. Which tier a given product falls into, and therefore whether you can self-declare, is a question to settle product by product against the current text and guidance rather than by analogy with a competitor.

Why this lands on engineering, and why that is where it gets missed

Here is the structural reason manufacturers get caught out. Everything above is product compliance. It belongs with the people who already handle CE marking, the machinery and EMC directives, declarations of conformity and technical files. It sits with engineering, product management and the quality function.

Cybersecurity, in most manufacturers, sits with IT.

So the CRA arrives in an organisation and lands in a gap. IT reads it, recognises the vocabulary, and assumes someone owns it. Engineering reads it, recognises the conformity machinery, and assumes the cyber part belongs to IT. The regulatory affairs team tracks product directives and has no reason to be watching a cybersecurity act. Nobody is obstructive and nothing gets done, which is the quietest way for a deadline to be missed.

The fix is unglamorous: name an owner, in writing, who sits in the product organisation and has access to security expertise rather than being expected to supply it personally. Then join the two record systems. Your technical file needs to reference the SBOM, the threat model, the test evidence and the support-period commitment. Your security function needs visibility of which product versions are in the field and which components they contain, because that is what turns a published vulnerability into a defensible 24-hour answer.

This is the kind of scoping work our advisory team does first on a manufacturing engagement, because the answer to "which obligations genuinely reach us?" changes the size of everything that follows.

Obligation two: the plant that makes the product

Now turn around and look at the factory. None of the above protects a production line, and the CRA does not ask it to.

The reference point here is IEC 62443, the standards series for industrial automation and control systems. Two of its ideas do most of the useful work.

Zones and conduits. Rather than treating the plant as one network, you divide assets into zones that share a security requirement, then define conduits as the only permitted paths between them. A cell controller, its drives and its human-machine interface might form one zone. The historian and the manufacturing execution system form another. Corporate IT is a separate zone again, and the path between IT and the plant is a conduit you design, document and monitor rather than a flat route that exists because a cable was convenient in 2011. The discipline is in the exclusivity: a conduit is only meaningful if it is the sole route, which is why the exercise usually begins with finding the undocumented connections nobody remembers making.

Security levels. The standard describes levels that express the attacker a zone is expected to withstand, from casual or coincidental misuse at the lower end, through intentional attacks using simple means and limited resources, up to sophisticated attacks with substantial resources behind them. The value is that it forces a conversation in specifics. You set a target level per zone based on consequence, assess what the zone can currently achieve, and the gap becomes your work list. A safety-instrumented zone and a shop-floor reporting zone should not have the same target, and saying so out loud stops the budget being spread evenly over things that matter unevenly.

IEC 62443 also has a product dimension, covering secure development lifecycle requirements for the people who build control systems and component-level technical requirements. If you are a manufacturer whose products are themselves control equipment, this is where the two obligations in this article meet most directly, and the secure-development evidence you build for one serves the other.

Why OT cannot be patched on an IT cadence

The single most common misunderstanding IT leaders bring to the plant is that OT patching is an attitude problem. It is not. It is a consequence problem.

A controller may be supported by its vendor only at a specific firmware revision. A machine may be part of a validated or safety-assessed configuration where any change triggers reassessment. Restarting a process asset may mean losing a batch, re-homing an axis, or a four-hour ramp back to stable output. A good proportion of the estate runs operating systems that passed end of support years ago and cannot be upgraded without replacing the machine, which is a capital decision on a different timescale entirely. And the window in which any of this can be touched is a planned shutdown that the operations director scheduled months ago.

So the realistic strategy is not faster patching. It is compensating controls that reduce exposure while the asset stays as it is.

• •An asset inventory that is actually complete, including what each asset talks to. You cannot defend or prioritise what you have not enumerated, and in most plants the first pass finds assets nobody had on a list.
• •Segmentation that holds under pressure, enforced at the conduit rather than by convention, so a compromise in corporate IT does not reach the cell. Network security work in a plant is mostly this.
• •Passive, protocol-aware monitoring inside the OT environment. Active scanning can knock over fragile devices, so the sensible approach watches traffic rather than probing it, and alerts on the industrial protocols rather than only on Windows telemetry. This is the part of managed security that has to be designed for OT rather than inherited from IT.
• •Application allow-listing on engineering workstations and HMIs, which are the general-purpose computers in an otherwise purpose-built estate and therefore the usual way in.
• •Hard controls on removable media and engineering laptops, including the ones that belong to contractors.
• •Patching the things you can, properly, in the windows you have: the historian, the jump hosts, the engineering workstations, the switches. The unpatched controller gets a lot less dangerous when everything around it is current.
• •Backups of the things OT recovery actually needs: controller logic and configuration, HMI projects, recipes, drive parameters, known-good engineering workstation images. A corporate backup of file shares and mailboxes will not rebuild a line.

Ransomware, measured in shifts

In an office, a ransomware incident is counted in records and in days of disruption. In a plant it is counted in shifts, and the arithmetic is unforgiving: a line that does not run does not make the thing you sell, and the output is not recoverable later because the capacity was the constraint. Add contractual delivery commitments, perishable work in progress and the cost of a cold restart, and the loss curve is steeper than almost any IT model assumes.

Two consequences follow. First, recovery priority is a production decision, not an IT one. The order in which systems come back should be set by which lines earn and which customers are contractually exposed, agreed with operations in advance and written down, because nobody negotiates that well at 3am. Second, the test has to be a real one. A restore test that proves the file server comes back says nothing about whether you can rebuild a cell controller from backup with the right program version. Our ransomware readiness checklist sets out the four stages in general terms; in manufacturing, read stage three as "can we restart the line", not "can we restore the data".

NIS2, where you have EU operations

One more obligation, and it is worth being precise about it because it is routinely overstated.

NIS2 is an EU directive, not a regulation. That means it does not apply to a UK company directly. It takes effect through each member state's own transposing law and applies to entities operating in that country. Annex II of the directive covers a set of manufacturing categories, including medical devices and in vitro diagnostics, computer, electronic and optical products, electrical equipment, machinery, and motor vehicles and other transport equipment. Within those categories, scope generally depends on size thresholds and on how the member state has implemented the directive, and transposition has not been uniform or on time across the Union.

For a UK manufacturer, that gives two realistic routes in. If you have an EU subsidiary or site in a covered category that meets the national thresholds, that entity has obligations under that country's law, and the group needs to know which country and which obligations. If you supply customers who are themselves in scope, their supply-chain security duties arrive at your door through contract: security requirements, incident-notification commitments and audit rights in a renewal you were expecting to be routine. The second route is far more common, and it is the one that catches companies who correctly concluded they were not in scope themselves. We cover the shape of the directive on our NIS2 page, and the same supply-chain dynamic is now visible in UK procurement through Cyber Essentials requirements in contracts.

Where the two obligations genuinely overlap

Having insisted on the distinction, it is worth being clear about the economies, because there are real ones.

The SBOM you build for product compliance and the asset inventory you build for plant defence are the same instinct applied in two directions, and the tooling and ownership conversations rhyme. The vulnerability intake process you stand up for the CRA can serve the plant too, since a researcher and a maintenance engineer both need somewhere to send bad news. Secure development evidence built to the IEC 62443 product lifecycle requirements feeds the CRA technical file. An ISO 27001 management system gives you the governance scaffolding, the risk register, the document control and the review cadence, that both obligations assume exists. And the monitoring that watches the IT to OT conduit is the same capability that tells you whether a reportable incident has actually occurred, which is the first thing you need when a 24-hour clock starts.

What does not transfer is accountability. Product compliance has to be owned in the product organisation and plant resilience in operations, with security supporting both. The programmes that work are the ones where those two owners are named, the shared artefacts are built once, and somebody senior holds the join.

A sensible order of work

If you are starting from a standing start with 11 December 2027 on the horizon, the sequence that tends to work:

1. •Scope the product side honestly. Which products with digital elements reach the EU market, through which route, and in which categories. This is a half-day exercise with the right people in the room and it changes everything downstream.
2. •Stand up the reporting capability now, because that duty is already live. Who detects, who decides it is reportable, who files, and what happens at a weekend.
3. •Build the SBOM for products currently in production, starting with the highest-volume or longest-lived.
4. •Publish a vulnerability disclosure route and put a real process behind it.
5. •Decide support periods deliberately, product by product, with the engineering cost understood.
6. •In parallel, map the plant into zones and conduits and find the connections that are not on any drawing.
7. •Set target security levels by consequence, then close the gaps in priority order rather than evenly.
8. •Prove the restart, not the restore, against one real production scenario.

Threat Protect works with manufacturers across both halves of this. We scope which obligations genuinely reach you rather than selling you the longest possible list, we run continuous compliance so the evidence stays current between audits instead of being rebuilt each year, and where certification is in play it is delivered through certified assessment partners with us as your single point of accountability. If you would like to work out which of the two obligations is your real exposure, book a call with a senior advisor.

Official sources

• • European Commission: Cyber Resilience Act
• • European Commission: NIS2 Directive
• • NCSC: operational technology guidance