Operational Technology (OT) environments are the backbone of critical industries such as manufacturing, energy, utilities, transportation, pharmaceuticals, and water treatment. Many of these environments rely on legacy systems that have been operating reliably for decades. While these systems were designed for availability, they were built before modern cybersecurity, remote access, and cloud integration became essential requirements.
As organizations pursue digital transformation initiatives such as Industrial IoT (IIoT), predictive maintenance, AI-driven analytics, and centralized monitoring, they face the challenge of securely connecting legacy OT systems without disrupting operations or requiring a full system overhaul.
In this blog post, we explore best practices and our products we offer for integrating legacy OT systems into modern enterprise architectures while maintaining safety, reliability, and security
Understanding Legacy OT Challenges
Legacy OT systems commonly present several technical and operational constraints:
- Dependence on proprietary or obsolete industrial communication protocols such as OPC Classic/DCOM and Modbus
- No built-in security (no encryption, authentication, or integrity protection)
- Unsupported operating systems and firmware (e.g., Windows XP, Windows Server 2003/2008)
- Limited resources such as minimal processing power and memory that prevent installing antivirus or endpoint security agents
- High availability requirements that discourage system modifications
- Limited vendor support or unavailable replacement parts
- Flat network architectures with little or no segmentation
- Unsupported software that no longer receives security updates
Unlike IT systems, OT environments prioritize continuous operation and safety over frequent updates. Therefore, connectivity strategies must minimize operational, availability and cybersecurity risks. Moreover, OT systems revamping is a last resort as it is expensive, operationally risky, and usually unnecessary. Securing legacy systems in place delivers the same visibility and connectivity benefits while treating the OT asset as something to protect, not replace.
Best Practices for Legacy OT Security
1. Start with a Comprehensive Asset Inventory
Before introducing connectivity, organizations should establish comprehensive visibility into their OT environment. An effective inventory includes:
- Controllers (PLCs, RTUs)
- HMIs
- SCADA servers
- Engineering workstations
- Sensors and actuators
- Network switches
- Communication gateways
- Protocols in use
- Firmware versions
- Physical locations
- Criticality of each asset
Passive network discovery tools are generally preferred over active scanning, which can unintentionally disrupt sensitive industrial equipment.
Implementation Tips: Up-to-date architecture drawings should be maintained alongside the asset inventory to provide a complete view of the OT environment, including network topology, communication paths, and system dependencies. This documentation enables informed decision-making, effective change management, and the secure integration of legacy and modern systems.
2. Assess Business Objectives before Connecting Anything
Not every legacy device needs to be exposed to the IT/enterprise network layer or requires cloud connectivity. Clearly define the business outcomes:
- Remote monitoring
- Predictive maintenance
- Production analytics
- Energy optimization
- Asset utilization
- Regulatory reporting
- Centralized alarming
Understanding the desired use cases helps determine which data is necessary and reduce the attack surface by preventing unnecessary exposure of OT assets.
3. Preserve Operational Stability
Operational continuity should always take precedence over new functionality. Best practices include:
- Avoid installing software directly on legacy controllers.
- Do not modify PLC logic solely for connectivity purposes.
- Isolate the OT assets from outside connections.
- Test integrations in staging environments whenever possible.
- Schedule deployment during maintenance windows.
- Maintain rollback procedures.
Connectivity should be additive rather than disruptive.
4. Use Secure OT Network Segmentation
One of the fundamental principles of OT cybersecurity principles is separating OT networks from corporate IT networks by segmenting industrial networks according to the Purdue Enterprise Reference Architecture. The Purdue Model organizes industrial systems into functional levels, helping organizations control data flows, reduce attack surfaces, and contain cyber incidents.
A typical architecture includes:
- Level 4–5: Enterprise IT systems (business applications, ERP, email, cloud services)
- Level 3: Manufacturing Operations Management (SCADA, historians, engineering workstations, patch management, backup systems)
- Industrial DMZ (IDMZ): A secure buffer between the enterprise and OT networks that hosts services requiring communication across both environments, such as OPC gateways, remote access servers, update repositories, and data replication services.
- Level 2: Supervisory control systems, including HMI and SCADA servers
- Level 1: Basic control systems, including PLCs, RTUs, and industrial controllers
- Level 0: Physical processes, sensors, actuators, and field devices
- Safety Instrumented Systems (SIS): Where applicable, these should be isolated from the basic process control system with dedicated security controls and tightly restricted communications.
Communication between levels should be limited to operational requirements and protected by industrial firewalls, access control policies, and deep packet inspection where appropriate. The Industrial DMZ should serve as the only controlled conduit for data exchange between enterprise IT and OT environments, preventing direct connections between Levels 4/5 and the control network.
Proper segmentation based on the Purdue Model helps contain cyber threats by isolating legacy OT systems, limits lateral movement, protects critical control systems, and enables secure integration of legacy OT assets with enterprise and cloud applications while preserving the availability, reliability, and safety of industrial operations.
Implementation Tips: To support this type of architectures, we offer Smart IoT Highway platform, SIOTH®, which is a robust IT-IIoT-OT integration platform that securely aggregates operational data, normalizes industrial protocols, enforces security policies, and exposes standardized interfaces to enterprise systems.
By centralizing connectivity configuration through SIOTH® instead of multiple point-to-point gateways, organizations can reduce architectural complexity, improve maintainability, and enforce consistent security policies across their OT environment.
5. Prefer Read-Only Data Collection
Whenever possible, legacy OT systems should expose operational data without allowing remote control.
Examples include process variables, machine status, alarm and events, historical trends, equipment utilization and production counters.
Read-only communication significantly reduces operational risk.
Write capabilities should only be enabled when absolutely necessary and after thorough risk assessment.
Implementation Tips:
SIOTH® platform offers several capabilities to block the write back to the OT systems via data flow control and access rights, but it also allows users to secure the write back when needed via product features such as:
- Flow/protocol break support to avoid direct writes to OT systems
- Data validation
- OPC UA reverse connect support
- Implementation of write approval workflows via its Job Engine module
- Restricting the write scope by exposing only the required data
- Encrypting data in-transit
- Ensuring traceability of all write requests
6. Use Industrial Protocol Gateways
Legacy protocols often cannot communicate securely with modern applications.
Industrial gateways bridge this gap by translating between protocols.
Examples include:
- Modbus TCP → MQTT
- Modbus TCP → OPC UA
- DNP3 → REST API
- PROFINET → OPC UA
- OPC Classic → OPC UA
Implementation Tips:
To achieve this objective, our Smart IoT Highway, SIOTH®, platform provides:
- Protocol translation
- Edge processing
- Secure communications
- Local buffering
- Data encryption
- User authentication
- Support of network segmentation and DMZ based architecture.
This way, SIOTH becomes the integration point instead of the legacy controller.
7. Deploy an Edge Computing Layer
Edge computing allows data processing close to industrial equipment. Benefits include:
- Reduced latency
- Local analytics
- Data filtering
- Compression
- Event detection
- Temporary storage during network outages
- Reduced cloud bandwidth
Rather than exposing PLCs or OPC Classic servers directly to the DMZ or to enterprise systems, edge devices securely aggregate operational data, serving as the trusted secure interface between OT and enterprise systems.
Implementation Tips:
Below is an example of architecture deploying SIOTH Edge device. Deployed close to industrial equipment, SIOTH Edge provides secure connectivity to legacy and modern OT systems while executing SIOTH capabilities locally. This enables protocol conversion, data processing, filtering, aggregation, advanced AI/ML models execution, without requiring direct access to controllers or other critical OT assets.
8. Implement Zero Trust Principles
Modern OT security increasingly adopts Zero Trust concepts. Key practices include:
- Verify every connection
- Strong identity management
- Device authentication
- Multi-factor authentication for remote users
- Least-privilege access
- Continuous monitoring
- Session logging
- Network micro-segmentation
No device should be trusted solely because it resides inside the industrial network.
Implementation Tips:
We recommend our users to put in place a defense in depth strategy as illustrated below:
9. Secure Remote Access
Remote maintenance has become essential, but it remains a major attack vector.
Secure remote access should include:
- VPN with MFA
- Bastion hosts or jump servers
- Time-limited access
- Role-based authorization
- Session recording
- Approval workflows
- Vendor-specific accounts
- Automatic session expiration
Direct Internet exposure of PLCs or HMIs should never be permitted.
10. Protect Legacy Systems That Cannot Be Patched
Many OT devices can no longer receive security updates. Compensating controls include network isolation, firewall filtering, application allowlisting, intrusion detection, strict access control, continuous monitoring, physical security, and disabling unused services and ports. Security should be applied around the asset when it cannot be applied directly to it.
Implementation Tips:
- Secure IT-OT integration capabilities of the SIOTH® platform allow users to isolate these legacy systems.
- For smaller integration needs, two options stand out. Secure communications between legacy OPC servers and clients through a secure OPC tunnel over a single TCP port using OPCNet Broker. OPC tunneling fully replaces DCOM, keeping OPC Classic communications functional and secure even after Microsoft’s 2022 DCOM hardening update. Alternatively, deploy a secure, modern OPC UA interface on top of existing OPC Classic servers and clients using the OPC UA Wrapper.
11. Monitor OT Communications Continuously
Continuous monitoring enables organizations to detect abnormal behavior without interfering with operations. Effective monitoring includes:
- New device detection
- Unauthorized protocol usage
- Configuration changes
- Unexpected firmware modifications
- Network anomalies
- Unauthorized engineering workstation activity
- Remote login events
Behavioral baselining is particularly valuable in OT environments because industrial processes tend to exhibit highly predictable communication patterns.
Implementation Tips:
You can take advantage of Simple Network Management Protocol, SNMP, to monitor your OT infrastructure and detect abnormalities.
Using SNMP connector and Job Engine capabilities in SIOTH®, you can trigger alarm notifications when abnormal resources consumption in critical servers is detected. Resources consumption is monitored in real-time using data collected via SNMP and rules execution as illustrated in the examples below:
Notifications can be sent to operators and system administrators:
- via emails if an SMTP server is available
- Or in form of system alarms to the SCADA servers.
Learn More About SIOTH Job Engine
12. Encrypt Data Beyond the OT Boundary
Many industrial protocols lack encryption. Once data leaves the control network, communications should be secured via encryption by using for example secure MQTT and OPC UA security options.
Sensitive production information should never traverse enterprise or cloud networks unencrypted.
Implementation Tips:
Several of our products support data in-transit encryption:
- SIOTH Connectors
- OPCNet Broker
- OPC UA Wrapper via standard OPC UA security options
13. Plan for High Availability
Industrial environments require continuous operation. Depending on the requirements of the digital transformation initiative, connectivity solutions should support:
- Redundant gateways
- Failover communications
- Store-and-forward capabilities
- Network redundancy
- Backup power
Implementation Tips:
SIOTH® supports active-passive and active-active redundancy. Moreover, all connectors in SIOTH provide the following features:
- Automatic Reconnection: the connectors periodically monitor the connection of the systems that they communicate with. Upon connection loss, they launch the automatic reconnection procedure to reestablish the communications without user intervention.
- Store and Forward: the connectors provide store & forward capabilities to automatically save the data temporarily in a buffer to be transferred automatically upon reconnection.
14. Maintain Detailed Documentation
Accurate documentation simplifies troubleshooting and supports regulatory compliance. This can include network diagrams, data flows, device inventories, firewall rules, user access lists and backup procedures.
Implementation Tips:
The configuration environment of Data Flows in SIOTH® provides the perfect reference for your data flows documentation, as illustrated in the example below:
SIOTH IT-OT Integration Capabilities
15. Follow Recognized OT Security Standards
Organizations should align connectivity projects with established industrial cybersecurity frameworks, such as IEC 62443 for industrial automation and control system security.
Standards provide structured guidance for securing industrial environments while supporting modernization efforts.
à Implementation Tips:
SIOTH® and OPCNet Broker® are compliant with cyber security requirements from IEC 62443 related to connectivity and IT-OT integration.
Common Mistakes to Avoid
Several common practices can significantly increase operational and cybersecurity risk as well as maintenance cost:
- Connecting PLCs or other industrial control devices directly to the Internet
- Bridging IT and OT networks without segmentation
- Ignoring legacy protocol security limitations
- Deploying multiple gateways and connectors, increasing architectural complexity and the attack surface
- Implementing numerous point-to-point integrations instead of a centralized integration architecture
- Collecting excessive data without a defined business need
- Performing active vulnerability scans on production equipment without validation
- Applying IT patching practices without considering OT operational and availability constraints
- Using default, weak, or shared credentials
- Allowing unrestricted or unmanaged remote vendor access
Connecting legacy OT systems is a critical step in industrial digital transformation, but it must be approached with care. The primary objective is to enhance visibility and operational efficiency without compromising the safety, availability, or reliability of industrial processes.
Organizations should prioritize asset visibility, network segmentation, read-only data access where appropriate, secure protocol gateways, edge computing, Zero Trust principles, and continuous monitoring. By implementing compensating controls for systems that cannot be modernized and adhering to recognized industrial cybersecurity standards, organizations can unlock the value of legacy OT assets while managing operational and cybersecurity risk effectively.
Frequently Asked Questions
Why can't legacy OT systems just be patched like IT systems?
Many legacy OT devices run on unsupported operating systems or firmware, have no vendor support left, and cannot tolerate downtime or unplanned changes without risking safety or production continuity. Instead of patching directly, legacy OT security relies on compensating controls such as network isolation, firewall filtering, whitelisting, and continuous monitoring, applied around the asset.
What is the Purdue Model and why does it matter for OT security?
The Purdue Enterprise Reference Architecture organizes industrial systems into functional levels, from enterprise IT down to physical processes, with an Industrial DMZ as the only controlled path between them. Segmenting a network according to the Purdue Model contains cyber incidents, limits lateral movement, and keeps enterprise systems from connecting directly to control-level equipment.
Should legacy OT systems allow write-back access?
Only when necessary. Read-only data collection of process variables, alarms and historical trends, covers most monitoring, analytics, and reporting use cases with significantly less risk than write access. Where write-back is required, it should go through validation, approval workflows, and full traceability rather than a direct, unrestricted connection.
How do you securely connect legacy PLCs to the cloud?
Rather than exposing PLCs directly, route their data through an edge device or integration platform deployed on the DMZ and that performs protocol translation, encryption. This allows to keep the PLC itself isolated inside the OT network while only aggregated, authorized data reaches enterprise or cloud systems.
Why do organizations secure rather than revamp legacy OT?
Full replacement of legacy OT equipment is often far costlier than the original system once re-engineering, re-certification, and downtime are factored in. Many of these systems also run continuous, safety-critical processes, so taking them offline risks lost production or safety shutdowns. Decades-old equipment is a known, proven quantity, while a replacement introduces new and unknown failure modes into a process where failure can be costly or dangerous. In most cases, the actual business goal, such as monitoring or predictive maintenance, does not require replacing the system at all. It only requires securely exposing the data it already produces.
