A critical CNC controller running an older operating system is not simply an IT asset. It is part of the production line, tied to delivery dates, operator workflows, tooling and revenue. That is why legacy machine patching cannot be treated like routine office PC maintenance. Apply an untested update at the wrong time and a machine may stop communicating, a specialist application may fail to load, or a vendor-supported configuration may be compromised.
Yet leaving known vulnerabilities untouched creates a different operational risk. Older shop-floor systems are frequent targets for ransomware, unauthorised access and malware spread from connected devices. The right response is not to patch everything immediately, nor to accept permanent exposure. It is to use a controlled process that protects both production continuity and cyber security.
Why legacy machine patching needs a different approach
Most standard patching policies assume devices can be restarted overnight, restored quickly and replaced if an update causes trouble. Legacy machinery rarely fits that model. A controller may run a version of Windows that is no longer supported, depend on proprietary drivers, or communicate with a PLC, HMI, barcode scanner or MRP system through software that has not changed in years.
There may also be no current vendor available to confirm compatibility. Documentation can be incomplete, passwords may sit with a former supplier, and the machine may only have a short maintenance window each month. In these circumstances, a blanket policy of automatic updates is not responsible risk management.
The trade-off is clear. Delaying updates can preserve a known working configuration, but it can also leave a route into the wider business network. Applying updates can close that route, but may introduce uncertainty on a production-critical asset. The practical objective is to understand each risk, reduce exposure around the machine and make changes only when the impact is controlled.
Start with the machine’s operational role
Before deciding whether a device should be patched, identify what it does and what depends on it. An engineering workstation used for occasional drawing changes needs a different level of control from a machine that runs every shift and feeds data directly into ERP or MRP.
A useful assessment records the operating system, installed applications, network connections, user accounts, antivirus status, available backups and machine vendor. It should also capture operational facts: the cost of an hour of downtime, the next planned maintenance slot, who can test the machine after an update, and whether a fallback process exists.
This turns a vague label such as “old PC on the shop floor” into a clear decision. Some machines can be patched under a careful monthly schedule. Others may be too fragile to change without vendor involvement. A small number may be so exposed that the priority is to remove their direct network access while a replacement plan is prepared.
Classify by risk, not age alone
Age matters, but it is not the only factor. A ten-year-old controller on an isolated network with restricted access may be lower risk than a newer workstation that is connected to the internet, accepts USB devices from multiple users and has local administrator rights.
Consider the machine’s exposure, criticality and recoverability together. Exposure covers how an attacker or malware could reach it. Criticality covers the production consequence if it stops. Recoverability covers whether the configuration, software and data can be restored within an acceptable period. This approach helps management invest in the controls that genuinely protect output, rather than focusing only on the date an operating system reached end of support.
Build a controlled patching process
A safe patching process has defined ownership, testing and approval. It should not rely on an operator receiving an update prompt and making a judgement during a busy shift.
First, review available patches and identify which ones address meaningful vulnerabilities. Security updates rated as critical may need urgent attention, particularly where remote access, shared folders or internet connectivity are present. Other updates can wait for the next planned maintenance window. Driver, firmware and application updates need extra caution because they are more likely to affect machine communications.
Next, test wherever possible. The ideal option is a non-production machine with the same configuration, but that is not always realistic. A practical alternative may be to test the associated application, communication path or operating system image in a controlled environment. For high-risk machinery, seek confirmation from the machine or software vendor before proceeding.
Before any approved change, take a verified backup or full image of the system. A backup is only useful if it can be restored, so recovery procedures should be checked in advance. Record the existing software versions, network settings and licence details. If the patch causes a fault, engineers need a reliable route back to the known working state.
Schedule the work around production, with a named person available to confirm that the machine starts, communicates and operates correctly afterwards. The test should reflect real use, not just whether Windows reaches the desktop. Confirm that programmes load, network shares are available, labels print where required and data reaches the connected business system.
Finally, document the result. This creates an audit trail for compliance, improves future troubleshooting and stops teams repeating the same investigation when staff or suppliers change.
When patching is not possible
Some legacy systems cannot be patched safely. The operating system may be unsupported, the manufacturer may prohibit changes, or the required application may depend on components that newer updates would remove. In that case, doing nothing is still not an acceptable strategy. Compensating controls can reduce the chance that the device becomes the entry point for a wider incident.
Network segregation is usually the most valuable control. Put legacy equipment on a separate, tightly controlled network segment and allow only the communication it genuinely needs. A machine should not have unrestricted access to office systems, cloud services or the public internet simply because it has an Ethernet connection.
A jump machine can provide controlled access for authorised support staff, rather than allowing direct remote connections to every controller. Multi-factor authentication, individual accounts and activity logging make access more accountable. USB controls, application allow-listing and the removal of unnecessary local administrator rights can further reduce the risk of malware reaching the machine.
These measures do not make an unsupported device equivalent to a modern, fully patched system. They do, however, create practical layers of protection while production teams plan a longer-term replacement or upgrade.
Avoid the common failure points
The biggest mistake is treating all devices identically. Office laptops can usually follow a standard patch cycle; shop-floor machinery requires exceptions that are deliberate, documented and reviewed. Exceptions without review tend to become forgotten vulnerabilities.
Another failure point is unclear responsibility between the machine supplier, internal IT team and external support provider. One party may say the machine must not be touched, while another assumes it is being maintained elsewhere. Assign ownership for patch decisions, backups, access control and incident response in writing. That makes it clear who is authorised to act when a critical vulnerability or production fault appears.
It is also worth avoiding false reassurance from antivirus alone. Endpoint protection is useful, but it cannot compensate for an exposed, unsupported operating system, weak passwords or unrestricted network access. Effective protection comes from combining patching with segregation, monitored backups, secure remote access and clear operational procedures.
Connect patching to lifecycle planning
Legacy machine patching should feed directly into a lifecycle plan. Every assessment reveals something useful: systems that can remain safely in service, machinery that needs stronger isolation, applications that have no supported upgrade path, and devices that should be budgeted for replacement before they fail.
This is particularly valuable for manufacturers managing capital expenditure carefully. Replacing every older system at once is rarely necessary or practical. A staged plan can prioritise the equipment with the greatest production impact and the highest security exposure, while controls protect lower-risk assets in the meantime.
For businesses working towards Cyber Essentials, ISO requirements or customer security expectations, this evidence also matters. A documented risk-based approach demonstrates that legacy equipment has not been ignored. It shows that decisions are understood, controls are in place and improvement is being managed rather than deferred indefinitely.
Make every change accountable
The best legacy patching arrangements give production teams confidence that IT changes will not be made casually, while giving directors confidence that known cyber risks are being actively managed. That requires knowledgeable technicians who understand the difference between a troublesome workstation and a machine that can stop the factory.
Where internal capacity is limited, specialist managed support can maintain the asset register, monitor exposure, co-ordinate vendors and schedule changes around operational reality. Syn-Star takes this approach by treating shop-floor technology as part of the production environment, not as an afterthought to office IT.
A legacy machine does not need to become an uncontrolled risk simply because it cannot be replaced tomorrow. With clear ownership, sensible testing, network controls and a realistic lifecycle plan, it can continue supporting production while the business retains control of security, downtime and future investment.
