OT and IT security for UK manufacturers: what's changed and what you need to do in 2026

Why manufacturing became the top target

IBM X-Force and Dragos – two of the most widely cited sources on industrial cybersecurity – both ranked manufacturing as the sector most frequently targeted by ransomware attacks. For the third consecutive year. That's not a statistical blip; it reflects something structural about how manufacturers operate and what attackers have learned about them.

The logic is straightforward from an attacker's perspective. A law firm that gets hit by ransomware faces a bad week and reputational damage. A manufacturer that loses access to its production control systems faces immediate, measurable financial loss: lines stop, orders are missed, customers look elsewhere. The pressure to pay is correspondingly higher, and the willingness to pay – or to pay quickly – reflects that pressure.

Manufacturers also tend to have under-invested in security relative to sectors like financial services. They've faced the same budget constraints as any mid-size business, they've prioritised uptime over security hardening, and they're often running technology that was installed a decade ago and hasn't been touched since. That creates a target profile that's both valuable and accessible.

The IT/OT convergence problem – how it happened

OT – operational technology – is the hardware and software that monitors and controls industrial equipment. PLCs (Programmable Logic Controllers) manage machinery sequences. SCADA (Supervisory Control and Data Acquisition) systems oversee plant-wide operations. HMIs (Human-Machine Interfaces) give operators visibility and control on the shop floor. Add industrial robots, conveyor systems, quality control sensors and you have a complex web of interconnected physical-process systems.

For most of the history of industrial computing, OT networks were air-gapped. They were physically isolated from business networks and from the internet. That isolation was the security model – not a sophisticated one, but an effective one. You couldn't remotely compromise a PLC you couldn't reach.

Then came the pressure to connect. ERP systems needed real-time production data. Remote monitoring promised to cut maintenance costs. Industry 4.0 initiatives required sensors and machines to feed data into analytics platforms. Each of those integrations required a connection – a bridge across what had been an air gap. And each bridge, if not properly architected, became a potential attack path from the corporate IT network directly into OT systems.

Most manufacturers didn't build those bridges with security in mind. They built them to solve an immediate operational problem, and the security architecture got bolted on later – or not at all. The result is that many production environments now have OT systems reachable from corporate IT networks, and corporate IT networks reachable from the internet, creating an attack surface that simply didn't exist ten years ago.

What OT attacks look like in practice

Attackers targeting manufacturers don't always go for OT systems directly. The more common pattern is to compromise an IT system first – through a phishing email, a compromised credential, or an unpatched vulnerability – then move laterally across the network until they reach systems that control or monitor production.

At that point they have options. They can deploy ransomware that encrypts both IT and OT systems simultaneously, maximising disruption. They can target engineering workstations where PLC programs are authored and stored, threatening to corrupt or delete the configurations that tell machines how to operate. They can simply threaten to disrupt production unless paid, knowing that the cost of downtime often exceeds the ransom demand.

OT systems are particularly attractive targets for two reasons. First, many run legacy operating systems – Windows XP and Windows 7 are still found on factory floors, not because manufacturers are negligent but because the industrial software that controls production equipment often can't be updated without re-certification by the equipment vendor. Second, even where patches exist, applying them requires taking systems offline – which means planned downtime, production disruption and, in some facilities, significant safety procedures. The patching cycle that IT teams apply to office laptops every month simply doesn't translate to a SCADA server running a continuous production line.

The UK regulatory and supply chain pressure

The regulatory landscape for UK manufacturers is shifting. The Cyber Security and Resilience Bill, currently moving through Parliament, will extend NIS2-equivalent obligations to a wider range of organisations. Manufacturers in defence, healthcare and government supply chains are directly in scope – but the supply chain provisions mean that even tier-2 and tier-3 suppliers face increasing scrutiny from their customers' compliance requirements.

UK MOD suppliers are already experiencing this. Defcon notices have referenced cybersecurity requirements, and Cyber Essentials certification has become a baseline expectation for many defence supply chain contracts. That certification requirement is filtering down: if a tier-1 prime contractor requires Cyber Essentials of its suppliers, those suppliers increasingly require it of their own supply chain in turn.

The NCSC has published specific guidance for industrial control systems and OT security. Its core principle is clear: OT and IT networks must be segmented, with controlled and monitored connections at the boundary. That's not a new idea – it's how OT networks were originally designed – but it's a principle that many manufacturers have inadvertently abandoned as they've connected systems for operational convenience.

Cyber Essentials certification has a specific limitation here worth understanding. The scheme was designed for office IT, not OT. It's possible – and currently permissible under the scheme – to scope OT systems out of a Cyber Essentials assessment where those systems have no internet connectivity. Many manufacturers do exactly this. The certificate is genuine, the scope is legitimate, but it leaves the OT environment entirely unassessed. That gap is increasingly visible to customers, insurers and auditors who ask what the certificate actually covers.

What reasonable security looks like for a mid-size UK manufacturer

Not every manufacturer needs a full IEC 62443 implementation or a dedicated OT security operations centre. But there's a baseline that a 50–200 person manufacturer can and should achieve, and it starts with understanding what you have.

Asset inventory is the foundation. You can't protect systems you don't know exist. A structured inventory of OT devices – PLCs, HMIs, SCADA servers, engineering workstations – with their software versions, network addresses and connectivity paths is the starting point for every other security decision. Many manufacturers discover during this exercise that they have systems on their network that nobody currently working there fully understands or owns.

Network segmentation is the most impactful single control. OT and IT networks should be separated, with a controlled DMZ between them where any necessary data exchange happens under defined rules. Traffic crossing that boundary should be logged and monitored. A corporate laptop infected with ransomware should not be able to reach a PLC – full stop. Achieving that requires proper firewall rules, VLAN design and, in some cases, purpose-built industrial firewalls that understand OT protocols.

Access control for OT systems is often weaker than for IT systems. Shared credentials, no multi-factor authentication for remote access, and broad permissions are common. Restricting who can access OT systems – and enforcing MFA for any remote access to OT – meaningfully reduces the risk of a compromised credential becoming a production outage.

Patch management needs a realistic approach. Some OT systems can be patched; many cannot without vendor involvement and planned downtime. The answer isn't to ignore the problem – it's to know which systems fall into which category, to patch what can be patched on a systematic schedule during planned maintenance windows, and to apply compensating controls (tighter segmentation, enhanced monitoring) where patching isn't feasible.

Backup of engineering configurations is frequently overlooked. PLC programs and SCADA configurations represent years of engineering work. If those are encrypted or deleted by an attacker, rebuilding them from memory is not a realistic option. Backing them up – separately from production systems, on media that an attacker who compromises the production network can't reach – is a straightforward control that dramatically changes the recovery calculus after an incident.

The patch management problem on the factory floor

It's worth expanding on patch management because it's where the OT security problem is most practically difficult, and where the gap between theoretical best practice and operational reality is widest.

An industrial control system running a production line may have been installed in 2009, certified by the equipment vendor on a specific version of Windows, and never updated since. The vendor may no longer support that version. Applying a Microsoft security patch may void the certification, require a full functional re-test, and take the line offline for days. For a facility running 24/7, the cost of that downtime may genuinely exceed the cost of running an unpatched system with compensating controls.

That's not negligence – it's a real operational constraint. The security response is to treat it as a risk to manage rather than a problem to fix. Compensating controls include strict network segmentation that prevents anything reaching the unpatched system that doesn't need to, application whitelisting on workstations where it's feasible, and enhanced monitoring to detect anomalous behaviour early.

Where patches can be applied – and many OT systems are more patchable than manufacturers assume – the barrier is usually process rather than technical. There's no defined maintenance window, no ownership of the task, no test procedure. Establishing those processes is the work, not the patching itself. Organisations that create a structured OT patch management programme, even one that operates on a six-month or annual cycle, are in materially better shape than those running on ad-hoc responses to vendor advisories.

Incident response planning deserves equal attention. When – not if – an OT system is compromised, the decisions that matter most are made in the first hours: do you isolate the affected segment and accept production loss, or keep running while investigating? Who decides whether to pay a ransom? How long can production stop before the business faces contractual penalties? What's the rebuild sequence if systems have to be restored from scratch? These questions are genuinely hard to answer under pressure. They're much easier to answer in a tabletop exercise beforehand.