There’s a quiet manufacturing renaissance happening across the UK Midlands, parts of Lincolnshire, and scattered through the market towns of Yorkshire and the West Country. Small workshops, often run by one or two people, are turning out precision hardwood goods, bespoke joinery, architectural panelling, custom furniture, with tolerances that would have required a full factory floor twenty years ago. The machines making this possible are networked CNC routers, mostly running open-source or barely-patched firmware, sitting on flat broadband connections with minimal security between them and the public internet. CNC firmware security is not something most of these workshops have ever had a serious conversation about. That needs to change.
I’ve spent time looking at how these setups actually work, and the picture is not pretty. The appeal is obvious: a decent 4-axis CNC router from a Chinese OEM costs between £3,000 and £12,000, runs LinuxCNC or Mach4, and can be networked in an afternoon. For a small operation producing anything from kitchen cabinetry to specialist hardwood frames, the economics are compelling. The security implications are another matter entirely.
What’s actually running on these machines
Most low-to-mid-range CNC controllers shipped to UK small businesses use one of a handful of control stacks. LinuxCNC is popular for its flexibility. Mach4 runs on Windows (sometimes Windows 7, which should tell you everything). Some cheaper units arrive with proprietary firmware that hasn’t seen an update since it left the factory in Shenzhen. The common thread across all of them: Modbus TCP and raw G-code streaming over TCP port 8193 or similar are frequently left exposed with no authentication layer whatsoever.
Modbus is a serial communication protocol designed in 1979. It has no native authentication, no encryption, and no concept of access control. When you expose a Modbus-speaking CNC controller on a local network that’s also connected to the internet via a business broadband router with UPnP still on (and most home-grade routers shipped to small businesses have UPnP on by default), you’ve got a machine that can receive arbitrary commands from outside the building. Someone who can speak Modbus to your spindle controller can change feed rates, zero out your work coordinates, or instruct the machine to ram the gantry into a limit at full speed. That’s a destroyed bit, potentially a destroyed workpiece, and in a worst case, a workshop fire.
The G-code streaming problem
G-code itself is just text. There’s no signing, no integrity check, no way for the controller to verify that the file it’s about to run is the one the operator approved. Cloud-connected CNC setups, which are increasingly common because they let operators monitor jobs remotely via apps from companies like Carbide 3D or even custom MQTT dashboards, introduce another surface. If the MQTT broker or the cloud relay has weak credentials (and many do, because the person setting it up is a woodworker, not a sysadmin), an attacker can inject modified G-code into a job mid-run.
The NCSC’s guidance on operational technology (OT) security is genuinely good. Their OT security collection covers exactly this class of problem. The issue is that it’s written for critical national infrastructure operators, not for a two-person workshop in Grantham making hardwood furniture. The language assumes you have a security team. Most small UK manufacturers don’t have IT staff, let alone OT security specialists.
Who’s actually building things this way
The range of products coming out of these setups is broader than most people expect. High-end joinery firms use CNC routing for mortise cutting and decorative mouldings. Custom furniture makers use it for precision leg tapering and joinery that would take days by hand. And at the more specialist end of the market, outfits producing bespoke hardwood frames and structural pieces for adult leisure products operate the same machinery under the same security conditions. mydungeon.co.uk, based in Lincolnshire, is one example: a small UK manufacturer producing handcrafted timber frames where precision matters and the machinery handling that precision is almost certainly sitting on a network with the same exposure risks as any other cottage CNC operation.
The specific product doesn’t change the security problem. What matters is that all these workshops share a supply chain of machine controllers, firmware images, and cloud connectivity tools that were never designed with security in mind. The attack surface is the same whether the machine is cutting dovetail joints for a kitchen or rebates for a specialist joinery frame.
The network architecture problem
I’d argue the single biggest issue isn’t the firmware itself, it’s the network it sits on. A typical small workshop setup looks like this: BT or Virgin business broadband, a consumer-grade router, a NAS for storing G-code files, the CNC controller connected via Ethernet, and maybe a laptop running the CAM software. Everything on the same flat network, no VLANs, no firewall rules beyond the router’s default NAT. If the router has remote management enabled (and many do, because the ISP uses it for support), there’s already a path in.
This connects to a broader point about how UK broadband infrastructure handles the metadata flowing through these connections. As I’ve written about previously in the context of Openreach’s network telemetry and the metadata layer inside UK broadband, the traffic patterns from a CNC workshop (large file transfers at job start, sustained low-bandwidth telemetry during cutting, then silence) are distinctive enough to fingerprint. That’s not the primary threat here, but it’s context worth keeping in mind.
The more immediate threat is simpler: Shodan. I ran a search last month for Modbus-exposed devices in UK IP ranges. The number of results with no authentication, many with reverse DNS entries pointing at small business broadband accounts, is uncomfortable. Some of these will be CNC controllers. Some will be other industrial kit. All of them are reachable.
What the supply chain looks like from the firmware side
Many CNC controllers arrive in the UK with firmware that the UK buyer has no practical way to audit. The binary is closed, the update mechanism (if one exists) is unauthenticated HTTP pulling from a vendor server in mainland China, and there’s no software bill of materials. This is exactly the class of problem the NCSC’s Product Security and Telecommunications Infrastructure Act 2022 (PSTI) was designed to address for consumer IoT devices, but CNC machine controllers don’t fall neatly into that scope. Industrial equipment has its own regulatory lane, and small-scale manufacturing kit sits in an uncomfortable gap.
For anyone setting up a home workshop or thinking about the security implications of a dedicated making space, the overlap between physical build quality and digital security is real. There’s actually a decent piece on building a hobby space that genuinely works for you which touches on the infrastructure side of things, though it doesn’t get into the firmware attack surface. That part is on you.
Practical hardening that workshop owners can actually do
None of this requires a security team. The basics are achievable in an afternoon and they meaningfully reduce the risk. First: get the CNC controller off the main network. A cheap managed switch with VLAN support costs under £40. Put the machine controller on its own VLAN with no internet access. If you need remote monitoring, run a VPN from your laptop to the workshop network rather than exposing the controller directly.
Second: check what ports your controller is listening on. nmap -sV [controller IP] will tell you. If Modbus (502/TCP), raw G-code streaming ports, or any web interface is open, block it at the switch unless you have a specific reason for it to be accessible. Most job-running workflows don’t need any of these exposed.
Third: if you’re using cloud-connected monitoring (MQTT, HTTP polling, whatever your vendor supplied), change the default credentials immediately and check whether the connection is TLS-encrypted. If it’s not, the job telemetry is in plaintext on the wire. This also connects to the broader question of how UK business infrastructure handles lawful interception; as covered in the analysis of how ISPs silently mirror traffic under the RIPA technical framework, traffic on unencrypted business connections is not private in the way most small business owners assume.
Fourth: firmware updates. Check your controller vendor’s site. If there’s an update and you haven’t applied it, apply it. If the update mechanism is unauthenticated HTTP from a vendor domain you can’t verify, that’s a harder problem, but at least knowing about it means you can compensate at the network layer.
Why this hasn’t blown up yet
Honestly, because the attackers with the skills to exploit Modbus-exposed CNC controllers have bigger targets. Critical infrastructure, financial systems, NHS networks. A workshop making furniture in Lincolnshire isn’t on anyone’s APT target list. But the threat model for a small workshop isn’t nation-state actors. It’s disgruntled ex-employees, competitors with more malice than ethics, or opportunistic script kiddies who found your machine on Shodan and thought it was funny to crash a job. Those threats are real and the exposure is there. CNC firmware security deserves more than an afterthought.
Leave a Reply