That model is gone. The moment you connected the plant floor to historians, ERP, and remote support, every unauthenticated protocol and unpatched HMI became reachable. The system did not get less secure. The world around it changed, and the system has no way to respond.
This guide covers why legacy control systems are exposed, what modernization actually means at the OT level, and how modernizing closes the gaps that no amount of perimeter defense will fix.
Legacy control systems can create unexpected security problems for operational technology through the following scenarios:
Legacy control systems routinely outlive their vendors. DEC VAX and Alpha hardware running OpenVMS, and Sun SPARC servers running Solaris, are long discontinued and still carrying production workloads across manufacturing, utilities, and defense. In several cases, the original manufacturer no longer exists in any form that could issue a patch.
They still run for the same reason they always did: the application works, the process depends on it, and nobody wants to be the person who takes it down. Reliability is exactly what makes these systems hard to retire.
When a vulnerability lands on a platform like that, no fix is coming and no vendor to call. Your remaining options are compensating controls or migration.
Industrial protocols like Modbus, DNP3, and BACnet were designed for isolated networks where every device on the wire was assumed to be legitimate. They carry no authentication. A command arriving in the correct format is executed, with no way for the receiving device to establish who sent it or whether they were authorized.
There is no encryption either. Traffic is readable in transit, which means process values, setpoints, and commands can be observed and altered by anything with access to the network segment.
None of this is a defect in the system running the protocol. It is a design assumption from an era when physical access was the control. Once the network reaches beyond the plant, that assumption no longer holds.
The isolated nature of legacy control systems introduces worrisome security gaps.
Built on flat networks, these systems don’t have the necessary barriers to stand in the face of harmful attacks. Internal traffic isn’t stopped by firewalls. There’s no network segmentation, and infected computers can compromise the entire network.
Similarly, undocumented connections let malware enter the system through hidden blind spots. It could be through unguarded remote access, forgotten ports, unauthorized dial-up modems, or insecure links.
Historians, ERP integration, remote support, and IIoT projects all did the same thing: they gave the plant network a route to the outside. Each one was justified on its own merits. Together they removed the isolation the security model depended on.
The Colonial Pipeline shutdown in 2021 is the clearest example of what that costs. The ransomware never touched the control system. It hit the business IT side, and because the company could not confidently separate billing from operations, it shut the pipeline down as a precaution. The OT was not compromised. It was collateral.
That is the real exposure. An IT compromise now forces an OT decision, and on a flat, undocumented plant network that decision defaults to stopping production.
In OT, modernization comes down to two questions: how much of the system you replace, and whether the application has to change. The answers determine your cost, your risk, and your downtime.
Rip-and-replace is the option everyone considers first and almost nobody should choose. It means months of downtime, a large upfront capital request, and walking away from control logic that has been tuned against your process for two decades.
Incremental modernization is the workable path: phased, budgeted over time, and scoped so a failure in one phase does not take the plant with it. Our guide to control system modernization covers the phased approach in detail.
Emulation is what makes that path practical.
Emulation and virtualization do the same essential thing: they recreate the legacy environment in software, so your existing application runs unmodified on current hardware. The terms get used interchangeably in practice, and the distinction matters far less than the outcome. The operating system, the application binaries, and the control logic stay exactly as they are. Nothing gets rewritten, revalidated, or relearned.
That is what makes the approach viable for VAX, Alpha, and SPARC workloads, where the original hardware is gone, and the application cannot simply be recompiled onto something new.
The security value is direct. A VAX application emulated on a current server sits on hardware that still receives firmware updates, supports modern backup tooling, and can be snapshotted and restored in minutes rather than sourced from a parts broker.
One client ran an OpenVMS cluster of 14 Alpha nodes on legacy Fibre Channel storage, with the hardware reaching end of life and no supported replacement path. Read how we virtualized it.
Modernization is not a security product. It removes the structural conditions that make a legacy environment impossible to defend. Here is what changes in each of the five areas that matter most.
On a legacy platform, patching is not a scheduling problem. It is an availability problem. Often there is no patch, because the vendor stopped writing them. Where one exists, the system cannot be taken down long enough to apply and validate it.
That produces a permanent backlog. Known vulnerabilities stay open indefinitely, and OT vulnerability management becomes an exercise in documenting risk rather than reducing it.
Move the workload onto supported hardware and the calculus changes. Patches exist. Test environments spin up from a snapshot. A change that used to require a plant shutdown gets validated on a clone first and applied in a maintenance window.
The Purdue Model divides an industrial network into levels, from field devices at Level 0 up through enterprise systems at Level 4, with a demilitarized zone between the plant and the business network. Traffic crosses each boundary through a controlled, inspected path instead of moving freely.
Legacy environments usually cannot support this. Applications hardcode IP addresses, protocols assume a flat broadcast domain, and nobody has a current map of what talks to what. Segmenting a network you cannot document is how you cause an unplanned outage.
Modernization is what makes segmentation possible. Migrating to platforms that support routing, current network hardware, and documented interfaces gives you somewhere to draw the boundaries. Segmentation will not stop an intrusion, but it decides whether a compromised workstation reaches one cell or the entire plant.
Remote access is how most OT intrusions actually happen. In the 2015 attack on the Ukrainian power grid, attackers did not defeat the control system. They used legitimate remote access credentials to reach operator workstations and open breakers by hand.
Legacy remote access is typically a flat VPN, a shared vendor account, or a dial-up modem someone installed in 2004 and forgot. Once a session is established, it has broad reach and almost no logging.
Zero trust access inverts that. Every session is authenticated and authorized against a specific asset for a specific task, permissions expire when the work is done, and the session is recorded. For vendor and integrator access, the hardest category to control, that is the difference between handing out network access and granting a supervised connection to one machine.
It is also how managed remote support should work: monitored sessions against defined systems, with health checks and alerting, rather than standing access to the plant network.
Ransomware turned backup into a security control. The question is no longer whether a tape exists somewhere. It is how fast you can rebuild a controller, an HMI, and a historian after an incident, and whether you have ever actually tried.
Legacy systems fail this test in a specific way. The backup exists, but the only hardware that can restore it is the hardware that just failed. Recovery depends on sourcing a discontinued part.
Once a workload is emulated or virtualized, the entire system is a file. You can snapshot it, replicate it offsite, stand up a copy on any current server, and test a full restore without touching production. That is what turns a recovery time objective into a number you can commit to instead of an estimate.
You cannot patch, segment, or monitor a device you do not know is on the network. Most plants find equipment during an inventory that nobody knew was connected: a contractor’s laptop bridge, an open switch port, a serial-to-Ethernet converter added during a project ten years ago.
Legacy systems make this harder because passive discovery tools often cannot identify them. An unrecognized controller shows up as an unknown MAC address and stays that way.
Modernization forces the inventory. You cannot migrate a system without mapping every dependency first, which is why the asset register that comes out of a migration project is frequently the first accurate one the site has ever had. Segmentation, monitoring, and incident response all depend on it.
The assumption behind most delayed modernization projects is that the application has to be rewritten. In OT, it usually does not.
Emulation runs the existing binaries unchanged, so there is no code to rewrite and nothing to revalidate. Where a migration genuinely is required, the work runs in parallel: the new system is built alongside the old one and shadow tested against live process data until its outputs match, then cut over during a scheduled window.
Neither approach requires the plant to stop. Downtime in a well-run modernization project is measured by the length of a single planned cutover, not in months.
Compliance is usually what moves a modernization project from the wish list to the capital plan, because the requirements are specific and the deadlines are external.
ISA/IEC 62443 is the governing standard for industrial automation security. Its zone and conduit model is segmentation by another name, and demonstrating conformance requires documented asset inventories and controlled boundaries that most legacy environments cannot produce.
NIST SP 800-82 is the federal guidance for securing OT. It assumes capabilities such as logging, authentication, and patch management that legacy platforms cannot support at all.
For utilities, NERC CIP carries financial penalties and requires per-asset evidence of access control, change management, and recovery planning. For defense and government suppliers, CMMC and NIST SP 800-171 apply comparable expectations to any system touching controlled information.
The pattern across all four is the same. None of them ask whether your system is old. They ask you to demonstrate control, and an unpatchable platform with no authentication and no asset register cannot produce that evidence at any budget.
Most modernization projects fail in planning, not execution. Three steps decide the outcome.
Start by assessing your current situation: inventory all modules and their degree of importance to your business. Look for pain points in your legacy system, evaluate the quality of your code, and determine whether your system can handle future additions.
This step lets you know which systems or operations need to be repaired or updated first. Prioritize systems that present higher risks and are more critical to your business, requiring immediate action.
Those with lower business impact and lower risks could come later.
Each phase of your modernization project needs to be decided around business-aligned goals. This way, you’ll be both productive and tech-savvy, ensuring your operations don’t get interrupted while you gradually migrate your legacy system.
Modernizing your legacy system can ward off cyberattacks, protecting your sensitive data and making sure infrastructure-level projects run seamlessly.
At Salem Automation, we help manufacturers, government operations, and utilities keep their decades-old yet reliable systems going while transferring them to modern platforms. These new platforms enhance their security and prepare them for future integrations.
We specialize in legacy emulation, platform migration, OpenVMS services, and database management.
Connect with Salem Automation today for any inquiries about our services or questions about legacy system modernization.
Modernizing a legacy system doesn’t always mean replacing all your hardware. Sometimes, you may be able to keep your hardware while moving your applications to more advanced, high-performance digital platforms.
Other times, only aged, out-of-date parts of your hardware will be replaced. The cases in which you might need a full replacement are:
Yes, to a point, and it is often the right first move. Compensating controls protect the system without touching it: network segmentation to limit what can reach it, protocol-aware monitoring to detect abnormal commands, application allowlisting on HMIs, and brokered remote access in place of a flat VPN.
Done properly, that approach can extend the safe service life of a legacy system by several years at a fraction of replacement cost. What it does not do is fix the underlying platform. The hardware still ages out, the vendor still does not exist, and recovery still depends on parts you cannot buy. Compensating controls buy you time to modernize on your own schedule rather than under pressure.
It depends on what the project actually involves. An emulation project can be done in a week or more, because the application and the operating system move across unchanged.
A full modernization is a different scale. Reprogramming applications and moving to a new operating system can take anywhere from six months to several years, depending on how much custom code is involved and how many systems depend on it.
For projects at the multi-year end, the work is planning as much as engineering. Salem can help you break a modernization into stages so each phase delivers something usable instead of waiting years for a single cutover.
IT security is related to digital data, cloud-based operations, and enterprise networks. OT security is about protecting the physical aspects of a business, like machinery and industrial control systems.
Join us on Wednesday, October 7, 11:00 AM – 12:00 PM for a practical webinar exploring three paths forward for Oracle Rdb and OpenVMS environments.
Salem Automation, PARSEC Group, and CONNX will cover emulation, bridging Rdb data into modern business processes, and migrating the database and supporting functionality to a new platform.
Discover how to modernize while reducing migration risk and keeping critical legacy systems supported.
