NCC Group’s latest threat intelligence puts an uncomfortable number against a familiar factory problem. In August 2026 it recorded 1,073 ransomware attacks globally, the highest monthly total of the year. Industrials accounted for 329 of them, or 31%.
That does not mean 329 PLCs were encrypted or that every incident reached operational technology. In many manufacturing incidents the initial compromise still starts on the IT side through stolen credentials, exposed remote access, phishing or an internet-facing appliance. The production impact appears later, when the attacker reaches shared identity, virtualisation, engineering servers, historians, MES, file servers, backups or remote-support paths that the plant depends on.
For me, that distinction matters. “OT cybersecurity” is not mainly about buying a special firewall for the PLC network. It is about making sure a compromise elsewhere cannot easily become a production shutdown.
The August data is a warning about dependency, not just malware
NCC Group’s September 2026 review of August says ransomware activity rose 12% from July and that industrial organisations remained the most targeted sector. The same report describes Aurora ransomware activity using VPN exploitation and credential harvesting, including a transportation case where a hypervisor was encrypted.
That is a useful pattern to think about in a factory. A modern production system often depends on far more than the PLC itself:
- Active Directory or another identity service for engineering and operator access
- virtual machines hosting SCADA, historian, MES, reporting or licence services
- remote-access software used by OEMs and system integrators
- shared file storage containing PLC programs, HMI projects and recipes
- backup servers that are reachable from the same administrative environment
- ERP, WMS or cloud services that production needs to release or complete work
A line may still be electrically healthy while production is effectively stopped because nobody can log in, the recipe server is unavailable, work orders cannot be released, or the engineering workstation has been isolated during incident response.
Remote access deserves more attention than it usually gets
Factories have accumulated remote-access methods over many years: VPNs, RDP gateways, OEM appliances, vendor cloud tunnels, TeamViewer-style tools, cellular routers and sometimes a PC that “must stay online because the supplier needs it”. Each one may have been reasonable when installed. Together they become difficult to govern.
I would start by inventorying every path that can reach a production asset from outside the plant. Not just the corporate VPN. Include machine-builder access, maintenance laptops, 4G/5G routers, cloud gateways, remote desktop tools and any inbound port forwarding left behind from commissioning.
Then reduce the list. Remote access should be named-user, time-bounded where practical, logged and protected with multi-factor authentication. Shared vendor accounts are convenient until an incident happens and nobody can tell who used them.
The CISA StopRansomware guide specifically recommends updating VPN and remote-access infrastructure, using MFA for VPN connections, auditing remote monitoring and management tools, and restricting remote access to approved paths. Those controls are basic, but they address the routes attackers repeatedly use.
Keep IT and OT separated enough that failure stays local
Segmentation is often discussed as if it means drawing a firewall icon between office and factory networks. The engineering test is simpler: if a normal IT administrator account or compromised office laptop is taken over, what can it actually reach?
For a small or medium plant, I would aim for clear zones rather than an elaborate architecture that nobody maintains. Business IT, production servers, engineering workstations, supervisory control and machine-level control should not all be peers on one flat network.
Connections between zones should exist because a function requires them, not because “the machines need network”. MES may need production counts and order status. A historian may need process tags. An engineering workstation may need programming access. Those flows can be defined explicitly.
CISA’s Cross-Sector Cybersecurity Performance Goals use the same principle: maintain separation between IT and OT and limit connections to what is necessary. In practice, that also makes troubleshooting easier. A controlled architecture is easier to understand than years of accumulated exceptions.
CANS covers this from the automation side in our industrial automation and SCADA work and industrial digitalisation projects. The objective is not to isolate production from useful data. It is to connect it deliberately.
Back up the things that let you rebuild a plant, not only the databases
Many backup policies are written by IT teams and naturally focus on servers and business data. OT recovery needs a slightly different inventory.
| Asset | What should be recoverable |
|---|---|
| PLC / safety PLC | Source project, compiled program where applicable, firmware/version record, I/O configuration and passwords/keys under controlled custody |
| HMI / SCADA / BMS | Project files, graphics, scripts, alarm configuration, historian settings and licence information |
| Drives / robots / instruments | Parameter sets, calibration records, recipes and communication settings |
| MES / OEE / middleware | Application configuration, interfaces, database schema, certificates, scheduled jobs and deployment packages |
| Virtualisation / servers | Golden images, VM backups, hypervisor configuration and a documented rebuild order |
At least one recovery copy should be offline or otherwise protected from the credentials used to administer the live environment. CISA recommends offline encrypted backups and regular restore testing because ransomware commonly attempts to delete or encrypt reachable backups.
The restore test is the part people skip. A folder full of PLC projects is not yet a recovery plan if the correct programming software, licence, communication driver and device firmware are missing.
Plan for production to operate in a degraded state
One useful exercise is to ask what the plant can still do if the corporate network is unavailable for 24 hours.
Can operators run the line locally? Can the PLC keep controlling safely if MES is down? Can work orders be entered manually? Can a batch continue without cloud analytics? Is there a local copy of the critical recipe? Can maintenance retrieve drawings and PLC backups without logging into the compromised domain?
I would leave reliable local control alone wherever possible. Higher-level software should improve scheduling, traceability, quality and analysis, but a temporary loss of those layers should not turn every machine into dead metal.
This is also why I prefer bounded interfaces between plant software and control. Our earlier article on AI agents and industrial control made the same point from an AI angle: higher-level systems can assist broadly, but authority over physical control should remain constrained.
Incident response needs an OT version
An IT incident team may quite reasonably want to isolate networks, disable accounts, reimage machines and power down affected servers. On the shop floor, those actions can have safety and process consequences.
The OT response plan should therefore answer some practical questions before an incident:
- Who has authority to stop production or isolate a control segment?
- Which systems must remain powered for safe shutdown?
- What evidence should be preserved before a machine or server is reimaged?
- Which vendor contacts are needed to recover PLCs, robots, drives or specialist software?
- Which production systems must be restored first?
- How will temporary manual operation be controlled and documented?
Fortinet’s 2026 OT cybersecurity survey is useful context here. It reported that 71% of surveyed organisations detected between one and nine intrusions in the previous year, and it highlighted visibility, segmentation, secure remote access and OT-aware incident response as continuing gaps. Better detection can make incident numbers look worse before the organisation actually becomes less secure. Seeing the problem is a prerequisite to controlling it.
What I would do this month in a typical factory
I would not begin with a large cybersecurity transformation programme. I would pick a plant, put the controls engineer, IT administrator and production manager in the same room, and map three things: external access, IT-to-OT paths, and recovery dependencies.
From that map, the first fixes are usually obvious. Remove forgotten remote-access tools. Put MFA on the access that remains. Separate engineering access from ordinary office accounts. Protect and test PLC/HMI backups. Check whether the hypervisor and backup server share the same administrator credentials. Confirm that production can reach a safe state if MES, Active Directory or the WAN disappears.
Those actions are not glamorous. They are far more useful than adding another dashboard while the basic trust boundaries remain loose.
Sources
- NCC Group — Monthly Threat Pulse, review of August 2026
- NCC Group — Cyber Threat Intelligence Reports
- CISA — StopRansomware Guide
- CISA — Cross-Sector Cybersecurity Performance Goals
- Fortinet — 2026 State of Operational Technology and Cybersecurity Report summary
Featured image: Raymond Sime / Unsplash.
Engineering support
CANS works on PLC/SCADA, industrial communications, remote monitoring, edge systems, MES/OEE integration and industrial digitalisation. If you need to review the control-system architecture behind a cybersecurity or resilience programme, we can help map the plant dependencies and define changes without disrupting reliable production control.
Recent Comments