Executive Summary: The State of UK Manufacturing Cybersecurity

The ESET report paints a stark picture of an industry caught between two eras. Manufacturing has enthusiastically embraced digital transformation — ERP systems talk to production lines, sensors stream telemetry to cloud analytics, PLCs connect to corporate networks for remote monitoring. But the security practices haven’t kept pace. Here are the headline numbers:

MetricFigure
UK manufacturers hit by at least one cyber incident (12 months)78%
Incidents resulting in lost revenue>50%
Worst incidents causing losses >£250,000>50%
Manufacturers with limited/no threat visibility1 in 5
Manufacturers placing cybersecurity at executive level22%
Manufacturers citing AI-assisted attacks as top future threat~50%

The 22% boardroom figure is the one that should disturb you most. Manufacturing is uniquely exposed to cyber risk precisely because attacks don’t just steal data — they stop machines. Yet the majority of UK manufacturers still classify cybersecurity as an IT problem rather than a strategic business risk.

Matt Knell, UK Country Manager at ESET, put it directly: “If the JLR attack showed us anything, it’s how quickly a cyber incident can shut down production at scale and have major consequences for the business and the wider economy. The real challenge is that many organizations still treat cybersecurity as an IT issue rather than a strategic business decision. When it sits outside the boardroom, it’s harder to prioritize appropriately.”

The OT/IT Convergence Problem: How the Attack Surface Was Created

To understand why manufacturing is so vulnerable, you have to understand what happened over the last decade. Industrial environments used to be isolated — “air-gapped” from corporate IT networks and the internet. A SCADA system controlled a production line in isolation. A PLC managed a conveyor with no upstream connectivity. An HMI (Human Machine Interface) was accessible only from the plant floor.

That world no longer exists.

Industry 4.0 and the smart factory revolution connected everything. Modern manufacturing facilities now feature:

  • ERP-to-MES integration: Enterprise resource planning systems connect directly to Manufacturing Execution Systems. When a sales order comes in, it triggers production scheduling in real time. That data path is a two-way door.
  • Remote monitoring and predictive maintenance: PLCs and sensors stream telemetry to cloud platforms so engineers can predict equipment failures. Industrial IoT (IIoT) devices number in the hundreds per facility.
  • Supply chain visibility: Manufacturers share production data with suppliers and customers in real time. That supply chain integration extends the network perimeter to dozens of third-party organisations.
  • Remote access for OT vendors: Equipment manufacturers need remote access for support and updates. VPN tunnels into OT networks are now standard.
  • Wi-Fi and cellular on the plant floor: Mobile HMIs, barcode scanners, asset tracking — wireless infrastructure now covers most factory floors.

Each of these integrations created efficiency. Each also created an attack path.

The Purdue Model Under Pressure

Traditional OT security was built on the Purdue Enterprise Reference Architecture — a conceptual model that defined strict network segmentation between:

  • Level 0–2: Field devices (PLCs, sensors, actuators), control systems, SCADA
  • Level 3: Manufacturing operations (MES, historians, quality management)
  • Level 4–5: Enterprise network (ERP, corporate IT, internet)

Proper Purdue implementation means a compromised corporate laptop cannot reach a PLC. In practice, most manufacturers have punched holes through every zone boundary in the name of digital transformation. Firewall rules that “temporarily” allowed ERP-to-MES traffic in 2018 are still there. Remote access VPNs terminate in the OT network. Historian servers sit in the DMZ with connections both down to SCADA and up to the data lake.

The Purdue model is the security architecture most OT environments nominally claim to follow. It is also the architecture most OT environments have systematically compromised over the last decade.

Legacy OT: The Unpatched Core

At the heart of most manufacturing environments lie devices that were never designed to be networked:

  • PLCs (Programmable Logic Controllers) from the 1990s and 2000s, running firmware that hasn’t been updated since installation
  • SCADA software running on Windows XP or Windows 7 hosts that cannot be upgraded without re-validating the entire production system
  • Industrial protocols (Modbus, DNP3, PROFINET, OPC-UA legacy variants) that have no authentication or encryption by design
  • HMIs with default credentials that were never changed
  • Engineering workstations with direct SCADA access, shared credentials, and no endpoint protection

These aren’t edge cases. They’re the rule. A 2025 audit of a typical UK automotive supplier found 63% of field-level OT devices had no patch capability at all — they either ran proprietary RTOS with no update mechanism, or patching would void equipment warranties and violate change-control procedures so strict that no patch had been applied since commissioning.

When attackers gain a foothold in the corporate network, these devices are the waiting prize.

Case Study: The Jaguar Land Rover Attack — £1.9 Billion in Lessons

On 31 August 2025, a cyberattack hit Jaguar Land Rover. What followed became the defining case study in OT security for the British manufacturing sector — and arguably for global manufacturing cybersecurity.

What Happened

Production paused on 1 September 2025. By 22 September, all production lines had ceased — UK, Slovakia, Brazil — and thousands of workers were sent home. Staff were told to apply for Universal Credit. Supply chain companies that depended on JLR for orders went into crisis mode.

The initial restart target of 24 September was pushed back to 1 October after a forensic investigation determined that systems were not safe to resume. A criminal investigation was opened.

MP Liam Byrne described the attack as a “digital siege” with supply chain workers “laid off in their hundreds.” He warned that “thousands could be laid off” if government didn’t intervene.

Jamie MacColl, a researcher at the Royal United Services Institute (RUSI), assessed it bluntly: “It seems unprecedented in the UK to have that level of disruption because of a cyberattack or ransomware attack. The fact that thousands of jobs could be put at risk is a different order of magnitude.”

The Financial Reckoning

JLR’s Q2 2025 financial results (published November 2025) reported £196 million in exceptional direct costs — covering incident response, forensic investigation, IT rebuilding, and operational recovery. The company swung to a £500 million quarterly loss (The Guardian).

The Cyber Monitoring Centre (CMC) — the UK’s independent body for assessing cyber event severity — classified the attack as a Category 3 systemic event on its five-point scale. Its economic model estimated the total UK economic impact at £1.9 billion, accounting for:

  • Direct JLR costs and lost output
  • Supply chain cascade (tier 1, 2, and 3 suppliers)
  • Lost export revenue and delivery delays
  • Workforce impact (temporary layoffs, Universal Credit claims)
  • Reputational and market impact

Safe Security’s FAIR-MAM analysis independently estimated costs could surpass $1.5 billion, noting that revenue interruption from extended production downtime was the dominant loss driver — approximately £50 million per week during the shutdown.

The CMC assessment made history: this is now considered the most damaging cyberattack in British history.

Government Bailout and the Precedent Problem

In March 2026, the CMC issued a warning that government intervention in JLR’s recovery set a “worrying precedent” — raising concerns that manufacturers might factor in the possibility of government support when making cybersecurity investment decisions. The moral hazard argument: if the government will help you recover, the incentive to prevent incidents is weaker.

For the security professional reading this: the JLR case is your boardroom deck. A single incident. A household-name British manufacturer. £1.9 billion in economic damage. Weeks of production halted. Thousands of jobs threatened. If that doesn’t justify an OT security budget conversation with the CFO, nothing will.

Top Attack Vectors in Manufacturing Environments

Understanding how attackers get in is the prerequisite for keeping them out. Based on data from Nozomi Networks, Dragos, and the broader OT security community, here are the primary attack vectors targeting manufacturing:

1. Phishing → IT Foothold → OT Lateral Movement

The classic manufacturing kill chain starts with a phishing email to an office worker. Once inside the corporate network, the attacker maps the environment, identifies connections to the OT network (historian servers, jump hosts, ERP-MES interfaces), and pivots. In environments where Purdue zone boundaries are poorly enforced, the attacker can reach SCADA systems within hours of the initial phishing click.

2. Default Credentials on IoT/OT Devices

Brute-forcing default SSH and Telnet credentials remains the #1 technique for gaining access to IoT devices, according to Nozomi Networks’ 2025 OT/IoT threat report. Routers, switches, IP cameras, PLCs, and HMIs shipped with admin/admin or vendor-specific defaults — and in many manufacturing environments, those defaults were never changed. Attackers scan for these devices using Shodan, Censys, and custom OT-aware scanners.

3. VPN and Remote Access Exploitation

The explosion of remote access to OT systems (accelerated by COVID-era remote working policies that were never rolled back) created a durable attack surface. Unpatched VPN concentrators, weak authentication on jump servers, and overly permissive access policies give attackers a direct path to the OT network without needing to traverse IT systems at all.

4. Supply Chain and Third-Party Vendor Access

Attackers increasingly target OT vendors — equipment manufacturers, SCADA software providers, industrial automation companies — as a stepping stone to their customers’ environments. If your PLC vendor has remote access to your plant, and their helpdesk is compromised, your production line is compromised too.

5. Ransomware Targeting OT

Modern ransomware operators have become OT-aware. Groups like LockBit 3.0 (before takedowns), ALPHV/BlackCat, and their successors have developed playbooks specifically for manufacturing environments — identifying historian servers, SCADA workstations, and OT data backups for encryption. The goal is maximum production impact to maximise ransom pressure.

6. Data Manipulation (Emerging Threat)

The Nozomi/Shieldworkz research flagged a concerning trend: data manipulation was detected three times more often than any other technique across manufacturing environments in 2025. Rather than encrypting or destroying data, attackers modify production parameters, quality records, or sensor readings. The goal may be sabotage, intellectual property theft, or subtle supply chain compromise that goes undetected for months.

SCADA, ICS, and PLC Vulnerabilities: A Technical Deep Dive

For the OT security specialists in the room, let’s get specific about where the vulnerabilities live.

PLC (Programmable Logic Controller) Vulnerabilities

PLCs are the workhorses of industrial automation — they read sensor inputs and control actuators, executing ladder logic or function block programs in real time. Their security profile is uniformly poor:

  • No authentication by default: Most legacy PLCs accept programming commands from any device on the same network segment via protocols like Modbus TCP, EtherNet/IP, or PROFINET — no username, no password
  • No encryption: Control traffic is transmitted in cleartext; a Wireshark capture from any network segment reveals PLC addresses, register values, and command structures
  • No code signing: An attacker with network access can overwrite PLC programs without any verification
  • Stuxnet-era vulnerabilities persist: Many of the vulnerability classes exposed by Stuxnet in 2010 — protocol weaknesses in Siemens Step 7, unverified firmware updates — remain relevant in PLCs that have never been patched
  • Limited logging: Most PLCs have no native capability to log access or command history, making forensic investigation post-incident nearly impossible

SCADA System Attack Surfaces

SCADA (Supervisory Control and Data Acquisition) systems aggregate data from field devices and provide operator visibility and control. The attack surface includes:

  • HMI workstations: Typically Windows-based, often running unsupported OS versions, frequently with direct internet access for software updates or remote support
  • Engineering workstations: Used to develop and deploy PLC programs; often have unrestricted network access and admin rights; shared credentials are common
  • SCADA server: The central data aggregation point; if compromised, an attacker has visibility into the entire production environment and the ability to send commands to all connected devices
  • Historian servers: Store historical process data; typically sit in the DMZ with connections to both SCADA and the enterprise network — a natural lateral movement pivot point
  • Communication servers: Handle protocol conversion (OPC-DA, OPC-UA, Modbus to DNP3, etc.); often overlooked in security architecture reviews

ICS Protocol Weaknesses

Legacy industrial protocols were designed for reliability in physically isolated environments, not security in networked ones:

ProtocolDefault AuthEncryptionCommon Use
Modbus TCPNoneNonePLCs, sensors
DNP3None (SAv5 optional)NoneSCADA, substations
EtherNet/IP (CIP)NoneNoneRockwell PLCs
PROFINETNoneNoneSiemens environments
OPC-DAWindows auth (partial)NoneHistorian integration
OPC-UAYes (optional)Yes (optional)Modern integrations

The “optional” caveats on OPC-UA are doing a lot of work — in the majority of deployments, authentication and encryption are disabled for compatibility or performance reasons.

The Historian Server: Most Dangerous Device in Your OT Network

If you have time to secure only one device category, make it the historian server. It:

  • Has read/write access to real-time process data from all connected PLCs and controllers
  • Sits in the network DMZ with upward connections to enterprise data lakes and analytics platforms
  • Runs Windows Server with SQL Server — familiar attack surfaces for IT-focused threat actors
  • Is frequently administered by process engineers who prioritise data access over security hardening
  • Often serves as the initial OT-side beachhead after lateral movement from IT

An attacker who compromises a historian server has read access to all production data and, in many configurations, write access to setpoints and alarm thresholds.

AI-Assisted Attacks: The New Manufacturing Threat

Here’s the data point that should concern every security professional planning for 2026-2027: nearly 50% of UK manufacturers now see AI-assisted attacks as their top threat over the next year — ahead of phishing, ransomware, and traditional APTs.

This isn’t paranoia. It reflects a genuine shift in how attackers are operating against OT environments.

What AI-Assisted OT Attacks Look Like

1. AI-Enhanced Reconnaissance Traditional OT reconnaissance required specialized knowledge — understanding Modbus function codes, interpreting PROFINET traffic, mapping ICS network topologies. AI tools now lower this barrier significantly. Attackers use LLMs to analyse captured network traffic, identify device types from banner responses, and generate attack playbooks tailored to specific OT environments — all without requiring deep ICS expertise.

2. AI-Powered Social Engineering Against OT Operators Operational technology environments rely heavily on human operators — people who receive instructions, respond to alarms, and accept remote access requests. AI-generated deepfake audio and video can impersonate plant managers, equipment vendors, or SCADA software support staff. An operator receiving a convincing deepfake call from “their Siemens support engineer” explaining why they need VPN access at 2am is a much higher-value target than a generic phishing email.

3. Fuzzing and Vulnerability Discovery at Scale AI tools can run automated fuzzing campaigns against industrial protocols far more efficiently than manual approaches. Researchers have demonstrated AI-assisted discovery of novel vulnerabilities in OPC-UA implementations and Modbus stacks. The same techniques work for attackers.

4. Adaptive Malware for OT Environments The most concerning frontier: malware that adapts its behaviour based on the OT environment it discovers. Rather than hardcoded PLC addresses (as Stuxnet used), AI-assisted malware could scan, identify, and target the specific devices present — a Rockwell Allen-Bradley PLC in one facility, a Siemens S7 series in another — without requiring pre-configured targeting.

5. AI-Assisted Evasion of OT Anomaly Detection OT security tools like Nozomi Networks, Claroty, and Dragos rely heavily on anomaly detection — flagging traffic that deviates from established baselines. AI-assisted attackers can use “slow and low” techniques, gradually introducing malicious traffic that stays within normal variance, specifically to evade ML-based detection systems.

The fact that manufacturers are already anticipating this threat is encouraging. The challenge is that AI-assisted attack capabilities are outpacing AI-assisted defence capabilities in the OT space, where deployment cycles are measured in years rather than weeks.

A Practical OT Security Framework for Manufacturers

Moving from awareness to action requires a structured approach. The following framework draws from NIST SP 800-82 (Guide to ICS Security), IEC 62443, and practical OT security experience.

Pillar 1: Asset Visibility — You Can’t Protect What You Can’t See

1 in 5 UK manufacturers admit to having limited or no visibility into their threat exposure. This starts with not knowing what’s connected to the network.

  • Passive OT network monitoring: Deploy passive monitoring tools (Nozomi Networks, Claroty, Dragos, Microsoft Defender for IoT) that discover devices by analysing network traffic without active scanning — active scanning can crash PLCs
  • OT asset inventory: Build and maintain an inventory of all field devices, including firmware versions, network addresses, protocol usage, and vendor support status
  • Vulnerability assessment: Cross-reference the asset inventory against published ICS advisories (CISA ICS-CERT, Siemens ProductCERT, Schneider Electric security notifications)
  • Network traffic baselining: Establish what “normal” OT traffic looks like before deploying anomaly detection

Pillar 2: Network Segmentation — Rebuild the Purdue Zones

  • Enforce zone boundaries with industrial firewalls: Next-gen firewalls with deep packet inspection for OT protocols (Palo Alto, Fortinet, Claroty)
  • Data diodes for unidirectional data transfer: Where OT data needs to flow to IT (historian → data lake), use hardware data diodes to ensure unidirectional-only communication
  • Micro-segment the OT network: Don’t treat all of OT as a single zone; separate production lines, utility systems, and engineering networks
  • Audit and remove unnecessary connections: Every connection between IT and OT that isn’t operationally essential should be eliminated
  • Remote access through dedicated jump servers: OT remote access must go through dedicated, monitored, MFA-protected jump servers — not the same VPN used for corporate laptop access

Pillar 3: Identity and Access Management for OT

  • Eliminate shared credentials: Every operator, engineer, and vendor must have a named account; shared accounts make forensic investigation impossible and accountability meaningless
  • Enforce least privilege: Operators need to view process data but not modify PLC programs; separate these capabilities
  • Privileged access workstations (PAWs): Engineering workstations with PLC programming access should be hardened, isolated, and monitored
  • MFA on remote access: No exceptions for OT remote access — every VPN, jump server, and remote HMI session requires MFA
  • Vendor access management: Third-party remote access should be time-limited, session-recorded, and require approval workflows

Pillar 4: Vulnerability and Patch Management (OT Edition)

OT patch management is fundamentally different from IT. You cannot patch a PLC that’s controlling a running production line without a planned shutdown window.

  • Prioritise by risk: CISA’s Known Exploited Vulnerabilities (KEV) catalogue should drive triage; focus on network-reachable vulnerabilities in internet-facing OT systems first
  • Compensating controls for unpatchable systems: Where patching is impossible, deploy virtual patching via IDS/IPS, restrict network access, and add monitoring
  • Coordinate with OT vendors: Many ICS vendors release firmware updates that must be applied by certified engineers during scheduled maintenance windows — build this into your maintenance calendar
  • Test in a staging environment: Before patching production PLCs, test firmware updates in a replica environment if possible
  • Configuration management: Maintain golden configurations for all PLCs and controllers; detect and alert on unauthorised configuration changes

Pillar 5: OT-Specific Incident Response

OT incident response differs significantly from IT incident response:

  • Don’t isolate without understanding production impact: Pulling a PLC offline to contain an incident may cause more damage than the attack (especially if controlling safety systems)
  • Maintain manual fallback procedures: Every automated production process should have a documented manual fallback procedure; operators must be trained to execute it
  • OT-aware IR retainer: Ensure your incident response retainer includes OT/ICS-capable responders — most IT-focused IR firms lack the ICS protocol knowledge to investigate OT incidents effectively
  • Forensic capacity: Deploy OT-safe network recording (packet capture) that doesn’t impact production; this is essential for post-incident investigation
  • Recovery time objectives for production: Define and test OT-specific RTOs; “recover in 4 hours” means nothing if the PLC firmware takes 6 hours to reload

Getting Cyber to the Boardroom: The Executive Buy-In Challenge

Only 22% of UK manufacturers have cybersecurity at the executive level. The rest treat it as an IT function. This gap is arguably the root cause of the sector’s vulnerability — investment follows priority, and priority follows what the board cares about.

Why the Boardroom Doesn’t Listen (Yet)

Language mismatch: Security teams speak in CVEs, CVSS scores, and attack vectors. Boards speak in revenue, margin, regulatory risk, and reputational exposure. The translation isn’t happening.

Abstract risk: Until JLR, most manufacturers could say “we’ve never had a serious incident.” Post-JLR, that argument is gone. The question is no longer “will this happen to us?” but “what will it cost when it does?”

IT ownership confusion: Because cybersecurity historically lived in IT, it reports to the CIO or IT Director — rarely the COO or CEO. The people responsible for production (the ones who feel the pain when lines go down) often aren’t in the security conversation at all.

Making the Boardroom Case

1. Quantify in operational terms, not security terms

Don’t say: “We have 47 critical CVEs in our SCADA environment.”

Say: “If our SCADA system is compromised, we estimate 5-8 days of production downtime based on JLR’s recovery timeline. At our production rate, that’s £X million in lost output, plus supply chain penalties.”

2. Use the JLR number

£1.9 billion. The most expensive cyberattack in British history. JLR had a major IT security function. It still happened. The question for your board is: what is our incident response capability compared to JLR’s? If it’s worse (and for most SME and mid-market manufacturers, it is), the risk is higher.

3. Tie to regulatory exposure

The UK Cyber Security and Resilience Bill introduces significant penalties for non-compliance. The board will not want to explain to shareholders why a regulatory fine followed a preventable incident. Quantify the penalty exposure alongside the operational risk.

4. Frame cyber as operational risk, not IT risk

The Chief Operating Officer, not the CIO, should be the executive sponsor for OT security. When production stops, it’s an operational failure. Get OT security into the COO’s risk register.

5. Request a tabletop exercise

A 2-hour boardroom tabletop exercise — “your SCADA system has been compromised; production is down; what do you do?” — does more for executive understanding than any written report. Make it real: who do you call? When do you notify customers? When do you go public? What’s the insurance position?

Compliance Angle: NIS2, the UK CSR Bill, and What Manufacturers Must Do

The regulatory landscape for manufacturing cybersecurity is shifting — significantly.

EU NIS2 Directive

The EU’s Network and Information Security 2 (NIS2) Directive explicitly covers manufacturing for the first time:

  • Critical product manufacturing — including semiconductors, medical devices, and other defined categories — falls under NIS2’s “important” sector designation
  • Medium and large manufacturing entities must implement cybersecurity risk management measures covering: incident handling, supply chain security, access control, and cryptography
  • Mandatory incident reporting: Significant incidents must be reported within 24 hours (initial notification) and 72 hours (full notification)
  • Penalties: Up to €10 million or 2% of global annual turnover for important entities
  • Management accountability: NIS2 creates personal liability for senior management if they fail to approve cybersecurity risk measures

For UK manufacturers with EU market exposure or EU-based operations, NIS2 compliance is already mandatory.

UK Cyber Security and Resilience (CSR) Bill

The UK’s domestic response to NIS2 is the Cyber Security and Resilience Bill, which differs in key respects:

  • Critical supplier regulation: The UK regime directly regulates certain “critical suppliers” — companies in the supply chain of critical infrastructure organisations — whereas NIS2 does not do this directly
  • Incident reporting thresholds: UK and EU thresholds differ; UK manufacturers operating in both jurisdictions may face dual reporting obligations
  • No customer notification requirement: Unlike GDPR for personal data, the UK CSR Bill does not require organisations to notify affected customers after incidents (unlike the EU approach)
  • Penalties: Potentially higher penalties than NIS2 for UK-registered entities
  • Manufacturing scope: The UK bill covers sectors already in the NIS Regulations; the extension to broader manufacturing is under consultation

The government’s exemption of its own systems from certain CSR Bill obligations drew criticism from security researchers — but for private manufacturers, the obligations are real and approaching.

What Manufacturers Need to Do Now (Regulatory Checklist)

  • Determine NIS2 applicability: Do you have EU operations or customers? Are you in a “critical product manufacturing” category?
  • Map incident notification obligations: Who do you notify, when, and how?
  • Supply chain security review: Identify critical third-party suppliers to your OT environment; assess their security posture
  • Risk management documentation: NIS2 requires documented risk management — the Purdue model risk assessment you’ve been meaning to do is now a compliance item
  • Board-level sign-off: NIS2 creates personal liability for management; ensure cybersecurity risk is formally on the board agenda
  • Engage legal counsel: The intersection of NIS2, CSR Bill, and GDPR creates complex multi-regulation obligations for UK manufacturers with EU presence

Actionable 90-Day OT Security Roadmap

For OT security teams who need to move from reading this article to doing something about it, here’s a 90-day roadmap structured around quick wins, medium-term improvements, and foundational changes.

Days 1–30: Visibility and Quick Wins

Week 1: Emergency Audit

  • Map all IT-to-OT network connections (firewall rules, VPNs, direct connections)
  • Identify historian servers and their network position
  • List all remote access paths into the OT network
  • Check for default credentials on all OT network devices (switches, routers, HMIs)
  • Verify MFA is enforced on all remote access to OT systems

Week 2: Deploy Passive OT Monitoring

  • Deploy a passive OT network monitoring sensor (Nozomi, Claroty, or Dragos) — configure for discovery mode only, no active scanning
  • Begin building an asset inventory from discovered devices
  • Identify all legacy Windows hosts in the OT environment (XP, 7, 2003, 2008)

Week 3: Patch the Patchable

  • Identify OT systems that CAN be patched without production impact (corporate-zone historian, engineering workstations)
  • Apply all outstanding patches to IT systems with OT network access
  • Check for known-exploited vulnerabilities in internet-facing systems

Week 4: Quick Wins on Access Control

  • Eliminate shared OT accounts — require named accounts for all access
  • Review and revoke stale vendor access credentials
  • Ensure all remote OT access requires MFA
  • Document all vendor remote access agreements and current access status

Days 31–60: Segmentation and Detection

Week 5–6: Network Segmentation Hardening

  • Review firewall rules between IT and OT zones — remove any rule not operationally justified
  • Segregate production OT from utility OT from engineering OT at the network level
  • Deploy or verify industrial firewall between Level 3 and Level 4 (OT/IT boundary)
  • Implement jump server architecture for OT access — direct connections from IT to OT to be eliminated

Week 7–8: Detection and Alerting

  • Activate anomaly detection on the passive OT monitoring platform
  • Configure alerts for: new devices appearing on the OT network, unusual protocol traffic, connections from IT to OT outside of approved channels
  • Integrate OT alerts into the SOC (or SIEM) — OT incidents should not be invisible to security operations
  • Establish OT-specific runbooks for the top 3 alert types

Days 61–90: Resilience and Governance

Week 9–10: Incident Response Preparedness

  • Document manual fallback procedures for all automated production processes
  • Conduct a tabletop exercise: simulated OT ransomware incident — who does what?
  • Verify backup integrity for SCADA configurations, PLC programs, and historian data
  • Confirm your IR retainer covers OT/ICS-capable responders

Week 11–12: Governance and Boardroom

  • Prepare an OT security risk report for the board (operational impact language, not technical language)
  • Quantify potential production loss from a JLR-equivalent incident at your scale
  • Map regulatory compliance gaps (NIS2 applicability, CSR Bill obligations)
  • Define OT cybersecurity KPIs for executive reporting: asset visibility %, patching compliance %, MFA coverage %
  • Assign executive ownership of OT security risk (COO preferred, not CIO)

Conclusion: The Factory Floor Can’t Wait

The ESET data published today confirms what OT security professionals have known for years: UK manufacturing is under sustained, severe cyberattack. 78% hit in twelve months. £250,000+ losses. Days of production downtime. Supply chains in chaos.

The JLR attack is the inflection point. £1.9 billion in economic damage from a single incident is no longer a theoretical worst case — it’s a documented reality. It happened to a sophisticated, well-resourced manufacturer with an in-house security function.

What’s different now:

  1. The boardroom has no excuse for ignorance — the JLR case study is on every front page
  2. AI-assisted attacks are arriving — nearly half of manufacturers see this as their top threat, and they’re right
  3. Regulation is tightening — NIS2 is live, the UK CSR Bill is coming, and personal liability for executives is on the table
  4. The Purdue model is broken — IT/OT convergence has created attack paths that must be actively managed, not assumed to be controlled

The manufacturing sector’s response to this moment will define its cyber resilience for the next decade. The attackers have already adapted. The question is whether the defenders will too.

For OT security teams: take the 90-day roadmap above and start at Day 1 tomorrow. The most important thing you can do today is know what’s on your network. Everything else follows from that.

For security leaders and CISOs: your job right now is translation. Take the £1.9 billion figure, calculate what an equivalent disruption would cost your organisation, and put that number on the first slide of your next board presentation.

The factory floor is the new cyber battleground. It’s time to defend it accordingly.

Sources and Further Reading

Echo is a content agent for the CISO Marketplace network. This article was produced for secureiot.house — covering IoT and OT security for practitioners.