A production computer that still runs a critical machine is not simply an old PC. It may hold the settings, drivers or software needed to make parts that customers are expecting this week. A legacy machine security project gives you a structured way to reduce the risk around that equipment without taking a reckless approach to changes that could stop production.
The aim is not necessarily to replace every ageing machine controller or Windows XP workstation immediately. It is to understand what it does, contain the security risk, make recovery possible and create a realistic long-term plan. For most manufacturers, that is a much better decision than hoping an unsupported computer remains invisible forever.
Start with production risk, not the age of the computer
An old computer is a concern, but age alone does not tell you how urgent the problem is. A ten-year-old PC running a standalone inspection station may be lower risk than a newer machine connected directly to the business network, used for email and accessed remotely by several suppliers.
Start by identifying which equipment can affect output, quality, delivery dates and safety processes. Include CNC controllers, programming stations, label printers, test rigs, barcode systems, industrial PCs, warehouse terminals and computers supporting CAD, CAM, ERP or MRP workflows.
For each item, establish four practical facts. What does it control or support? What systems does it communicate with? Who needs access to it? What happens if it fails, becomes encrypted by ransomware or has to be rebuilt?
This work often exposes dependencies nobody has documented. A machine may appear to be self-contained until you discover it pulls job files from a shared folder, relies on a particular USB licence key or sends production data to an old database server. Those details decide the right security controls.
Separate failure impact from cyber exposure
A machine can be highly critical but relatively isolated. Another may be easy to replace but have a wide route into your network. Assess both sides.
Failure impact covers downtime, scrapped material, missed despatches, the availability of spare parts and whether anyone still knows how to reconfigure the system. Cyber exposure covers unsupported operating systems, internet access, shared passwords, removable media, remote support tools and network connections.
This distinction helps you spend effort where it protects the business most. It also prevents a familiar mistake: replacing a working computer without first confirming that the machine software, interfaces and licensing will work on anything newer.
Build the legacy machine security project around containment
Unsupported software cannot usually be made equivalent to a fully supported, regularly patched operating system. There is no polite technical workaround for that. However, a well-designed environment can reduce the chance that the device is exposed and limit the damage if another system is compromised.
Network segregation is normally the first major control. Machinery-connected devices should sit in a separate network segment from office computers, guest Wi-Fi and general-purpose warehouse devices. Access between segments should be limited to the specific services the machine needs, such as a defined file share, database connection or approved management workstation.
That does not mean cutting off a machine because it sounds secure. Production systems sometimes need controlled communication with ERP, MRP, engineering or quality applications. The work is to document that traffic, test the restrictions and allow only what is required. Broad “allow any” rules are quick to create and hard to defend later.
A firewall between the factory network and the office network provides useful control, but it must be configured to suit the process. For example, a CAM programming computer may need to send files to a CNC machine, while the CNC machine should not need unrestricted access back into the office network.
Remove unnecessary ways in
Once the machine is contained, reduce avoidable exposure. Disable internet browsing, email access and unused network services on legacy systems. Remove software that has no production purpose. Restrict USB use where this will not interfere with the process, and put a clear procedure around authorised removable media.
Shared logins are common on shop-floor equipment because they are convenient during a shift. They also make it difficult to see who changed a setting or accessed a critical system. Where individual accounts are supported, use them. Where the equipment cannot support them, compensate with physical access controls, named authorised users and an access record.
Remote supplier access deserves special attention. A supplier may genuinely need access to diagnose a machine fault, but permanent remote-control software with a shared password is not a sensible default. Use access that is approved, time-limited and monitored where possible. Require the supplier to connect through a controlled route rather than directly from the internet to the machine.
This can add a few minutes during a support call. That is a trade-off. It is usually preferable to discovering that an old remote access tool has provided a route into production systems for months.
Make recovery credible, not theoretical
Backups are often discussed as though every legacy machine can be restored like a modern laptop. In practice, machine recovery may rely on an operating system image, application installers, configuration files, licence details, PLC programs, vendor disks and specialist knowledge.
A useful legacy machine security project identifies exactly what must be retained to recover each critical device. This should include the machine configuration, not just user documents. Store backup copies separately from the machine and protect them from routine network access where possible.
Test a restoration plan in a controlled way. You may not be able to restore a production controller during working hours, but you can verify that backup files are readable, licence information is available and the required installer media still exists. If a specialist supplier must be involved, confirm their response arrangements and whether they still support the equipment.
A hypothetical example illustrates the point. An engineering firm may back up its CAD files every night, yet still lose several days if the programming workstation fails because the original machine software was installed from a disc nobody can locate. The drawings are safe, but production is not ready to restart.
Treat replacement as a managed engineering change
Containment buys time. It should not become a reason to avoid a replacement decision indefinitely.
Create a lifecycle plan that ranks legacy equipment by operational risk, supportability and replacement complexity. Some devices can be upgraded quickly. Others require a machine supplier, software vendor and production team to coordinate testing. Budgeting and planning these changes over time is far less disruptive than responding after a failure.
Before replacing a machine-connected computer, confirm compatibility with interfaces, serial connections, drivers, licences, machine software versions and any linked ERP or MRP process. Build and test the new environment away from live production if possible. Keep a tested rollback option until the new setup has operated reliably.
Virtualisation can help in some cases by preserving an older operating environment on supported hardware. It is not suitable for every machine, especially where specialist hardware, real-time behaviour or vendor support are involved. It should be assessed as one option, not treated as a universal answer.
Consider customer and certification requirements carefully
Customers and supply-chain partners increasingly ask manufacturers how they protect systems and intellectual property. An unsupported operating system connected to the wider network can raise difficult questions, particularly if it supports sensitive drawings, job data or customer information.
Good containment, access control and recovery planning demonstrate sensible risk management. They do not automatically make a legacy device acceptable for every customer requirement or certification assessment. Cyber Essentials and Cyber Essentials Plus preparation, for example, needs careful consideration of the systems in scope and the applicable requirements at the time of assessment.
Keep a written record of the risk, compensating controls, ownership and replacement plan. This is useful for management decisions, insurance discussions, customer questionnaires and internal accountability. More importantly, it stops critical knowledge living only with the person who has “always looked after that machine”.
A practical checklist before you start
Before approving work, make sure the project will deliver more than a spreadsheet of old computers. It should produce:
- a complete list of machinery-connected and production-critical devices
- a simple map of network connections and system dependencies
- agreed network segregation and rules for required communications
- controlled arrangements for supplier and remote access
- verified recovery materials, backups and restoration responsibilities
- a prioritised replacement plan with operational owners and timescales
The right approach depends on your machinery, supplier support and tolerance for downtime. But doing nothing is also a decision, and it usually leaves production dependent on equipment that cannot be properly secured or quickly recovered.
If you are unsure which legacy devices present the greatest risk, start with a review of the machines that would stop output or delay despatch if their computer failed. Syn-Star can help manufacturers turn that review into a practical security and lifecycle plan that protects production without creating unnecessary disruption.
