The most dangerous moment in the lifecycle of a control system is not when it is old. It is when someone decides to replace it.
The modernisation imperative and why it is also a crisis
Legacy SCADA systems are, in a narrow sense, a solved security problem. A Windows XP-based HMI with no network connectivity and an air gap maintained since commissioning in 2003 has a well-understood threat surface. It is large, unpatched, unsupported, architecturally rigid, but it is static. The adversary cannot reach it without physical access. The operator knows exactly what it does. The engineers who built it wrote the logic and still maintain it. The system is deeply vulnerable in the abstract, and deeply reliable in practice.
The moment that system is connected to a historian, to a remote access platform, to an enterprise analytics pipeline, to a vendor support channel, the threat surface transforms. It goes from static and physical to dynamic and networked, inheriting all of the attack surface of the systems it connects to, often without inheriting any of their security controls.
This is the fundamental paradox of SCADA modernisation: the pressure to modernise is real and legitimate, aging systems become unsupportable, spare parts become unavailable, cyber exposure accumulates, and the operational analytics that energy operators need to manage increasingly complex grids require data that legacy systems cannot efficiently provide but the act of modernisation, if poorly architected, introduces more risk than it resolves.
I have been involved in SCADA modernisation programmes at major energy operators, and the pattern I observe most consistently is that the architectural decisions made in the first six months of a modernisation programme determine the security posture of the resulting system for the next fifteen to twenty years. Those decisions are rarely made with adequate security architecture input. They are made by project engineers optimising for delivery timelines and by vendors optimising for their own integration story. The security architecture function, if it exists at all, is often brought in late, after the topology is fixed, after the vendor contracts are signed, after the connectivity decisions are made.
This post is an attempt to describe what good looks like: the architectural patterns that allow SCADA modernisation to deliver its operational benefits without destroying the security properties that make control systems reliable and safe.
Part 1: Understanding what you are actually modernising
The term “SCADA modernisation” encompasses a range of activities that have quite different security architecture implications, and conflating them is a common source of design error. Before any architecture work begins, it is worth being precise about which of the following you are actually doing:
HMI refresh. Replacing operator workstations and display software, typically from an obsolete platform (Windows XP, Windows 7) to a current one, while leaving the underlying control logic and field devices unchanged. This is the lowest-risk modernisation activity from a process perspective, the control layer is untouched, but it introduces new attack surface at the supervisory layer and requires careful management of the transition period when old and new HMI platforms coexist.
Historian modernisation. Replacing or augmenting the process historian, the system that collects and stores time-series process data, typically to improve data accessibility, query performance, or integration with enterprise analytics. This is frequently the entry point for IT/OT connectivity decisions that should be made as part of a broader architecture programme but are instead made as a data integration project with minimal security governance.
SCADA platform migration. Replacing the SCADA software platform, the application layer that provides supervisory control, alarm management, and process visualisation, while retaining existing field devices and communications infrastructure. This involves significant changes to the Level 2 architecture and often requires changes to communication protocols between the SCADA server and field devices.
Communications infrastructure modernisation. Replacing the field communications network: moving from serial RS-485 or proprietary radio to Ethernet-based or cellular communications, which fundamentally changes the attack surface at Levels 1 and 2. Legacy serial communications are difficult to attack remotely because they require physical access to the communications medium. Ethernet-based field networks, even when logically segregated, have a very different security profile.
Full system replacement. Replacing everything: field devices, communications, SCADA platform, HMI, historian. This is the highest-risk activity because every component is changing simultaneously, and the interactions between new components introduce behaviours that were not present in the legacy system.
Each of these activities requires a different security architecture approach, and the first deliverable of any modernisation programme should be an explicit classification of what is being changed, with a security impact assessment for each change category. The failure to produce this classification is the failure mode that causes security considerations to be bolted on at the end of a project rather than designed in at the beginning.
Part 2: The non-negotiable architectural constraints
Before discussing patterns, I want to establish the constraints that any acceptable SCADA modernisation architecture must satisfy. These are not preferences or best practices. They are design constraints that reflect the operational and safety requirements of energy infrastructure.
Constraint 1: Operational continuity during transition.
A SCADA modernisation programme at an operational energy facility cannot take the facility offline for the duration of the project. The modernisation must be designed around a transition period during which old and new systems coexist, both must function correctly, and the cutover from old to new must be executable without process interruption. This constraint has direct security architecture implications: the transition architecture:the temporary connectivity between old and new systems, the migration tooling, the parallel running configuration, must be explicitly designed, explicitly secured, and explicitly decommissioned at the end of the transition. Transition architectures that are designed hastily tend to persist indefinitely, because decommissioning them requires a further project that nobody has budgeted for.
Constraint 2: Safety system independence must be preserved.
If the facility has a safety instrumented system (SIS), and any facility operating above a trivial risk level should have one; that system must remain architecturally independent of the SCADA system being modernised. The SIS’s ability to drive the process to a safe state must not depend on the availability or integrity of the SCADA platform. This is a requirement of IEC 61511 (functional safety) as well as good security practice. In practice, it means that SIS networks must be physically separated from SCADA networks, that SIS interfaces to the SCADA system (for monitoring purposes only, the SCADA should never be able to command the SIS) must be one-directional, and that SIS software must be subject to a separate, more rigorous change management process than SCADA software.
Constraint 3: Rollback must be possible.
Any modernised system must have a defined, tested rollback procedure that can restore operational control to the legacy system in the event that the new system fails to perform as expected. This constraint is frequently treated as a project management consideration,a risk in the project register, rather than an architecture requirement. It should be an architecture requirement. The ability to revert to the legacy system means the legacy system must remain capable of operation for the duration of the transition period, which has implications for how the transition is sequenced and what decommissioning activities can occur before the new system is validated in operation.
Constraint 4: Engineering change control applies to security changes.
Any change to a SCADA system including security changes, is an engineering change that must go through the same change management process as operational changes. The security team does not have a bypass on engineering change control for OT systems. This constraint means that the security architecture must be designed to accommodate the operational change management process, not to circumvent it. Patching, configuration changes, and agent deployments must all be planned, tested, and executed within the operational maintenance window framework.
Part 3: Defence-in-depth zoning for modernised SCADA environments
The modernised SCADA architecture should implement defence-in-depth through explicit zone design, with each zone characterised by its function, its trust level, its security requirements, and the controls on its conduits to adjacent zones. The following zone structure reflects the architecture I consider minimum acceptable for a major energy operator’s SCADA environment post-modernisation.
Safety Zone (Level 1S). The SIS network, physically separated from all other networks. No inbound connections from any other zone. Read-only data export to the supervisory zone via a hardware data diode or equivalent one-way mechanism. Access to this zone requires physical presence and a specific authorisation process. No remote access.
Field Control Zone (Level 1). PLCs, RTUs, and intelligent electronic devices (IEDs). Physical network infrastructure separated from supervisory networks. Communications to the supervisory zone via a well-defined set of industrial protocols, OPC-UA preferred for new deployments, with legacy protocol support (Modbus, DNP3) maintained for existing devices that cannot be migrated without replacement. No direct routed connectivity to any network above Level 2.
Supervisory Zone (Level 2). SCADA servers, HMI workstations, engineering workstations. This is the zone where the modernisation is most intensive, and where the security architecture decisions are most consequential. Critically, this zone must not be domain-joined to enterprise Active Directory. It should have its own identity infrastructure. Endpoint security controls; whitelisting applications rather than blacklisting malware, which is the appropriate model for a constrained-function environment, should be deployed with profiles that are validated not to interfere with control system operations.
OT DMZ (Level 2.5). This is the zone that most legacy SCADA environments lack and that most modernisation programmes fail to introduce properly. The OT DMZ sits between the supervisory zone and any zone that has connectivity to enterprise IT or external networks. It hosts the systems that broker data across the boundary: the historian replication server, the remote access jump host, the patch management server for OT systems, the protocol translation and data aggregation services. No direct routed path should exist from any IT network to the supervisory zone. All data crossing this boundary transits the DMZ and is subject to inspection.
Enterprise Integration Zone (Level 3). The historian servers that serve data to enterprise analytics platforms, the interfaces to ERP and maintenance management systems, the operational dashboards accessible from corporate networks. This zone is part of the OT estate; it is managed under OT change management processes, with OT-appropriate security controls, but it has defined conduits to enterprise IT systems. Every conduit is explicitly documented, firewall-controlled, and subject to regular review.
Remote Access Zone. A dedicated zone for all remote access to the OT environment. Remote access sessions: whether for internal engineers, vendor support, or regulatory access, terminate in this zone, not directly in the supervisory zone. The zone provides a jump host from which sessions to specific supervisory zone systems can be initiated, with all session activity recorded. The remote access zone has no persistent connectivity to the supervisory zone; sessions are established on demand and terminated on completion.
Part 4: Historian architecture, the boundary that is most commonly broken
The process historian sits at the most contested boundary in SCADA modernisation: it needs to collect data from the supervisory zone and make it available to enterprise analytics, but it occupies a position that, if poorly designed, creates a direct routed path between corporate IT and operational control systems.
The historian architecture I consider acceptable for a major energy operator has the following characteristics:
Separate historian instances on each side of the boundary. A “collection historian” sits in the OT DMZ, receiving data from the supervisory zone via a one-way replication mechanism ,ideally a data diode, or at minimum a firewall rule permitting only outbound historian replication traffic on the specific port required. An “enterprise historian” sits in the enterprise integration zone or the IT network, receiving replicated data from the collection historian. The enterprise historian is the system that business intelligence platforms, dashboards, and data science workloads query. It has no direct connection to the supervisory zone. If the enterprise historian is compromised, the supervisory zone is not reachable.
One-way replication only. The replication from collection historian to enterprise historian is strictly one-directional. There is no mechanism for the enterprise historian to write data back to the collection historian, and no management interface on the collection historian that is accessible from the enterprise network. This means that vendor remote management of the collection historian must be conducted through the remote access zone, not through the enterprise network.
Data validation at the boundary. The replication mechanism should include validation of the data being transferred, range checking, rate-of-change checking, and anomaly detection that can identify data that deviates significantly from expected process behaviour. Manipulated process data is a known adversary technique: if an attacker can corrupt the data that operators see in enterprise dashboards, they can obscure an ongoing process attack until physical consequences are already underway.
Explicit data classification. Not all process data should flow to the enterprise historian. A formal data classification exercise should determine which process variables are required for business purposes and which should remain within the OT environment. Safety system data, in particular, should generally not flow to enterprise systems, it is operationally irrelevant to business users and its exposure creates unnecessary risk.
Part 5: Remote access architecture for modernised SCADA
Remote access to SCADA systems is, in my experience, the single most common source of uncontrolled exposure in energy operator OT environments. The pressure to provide remote access is constant and legitimate: engineering vendors need to support systems they have supplied, operations engineers need to work from locations other than the control room, and the economics of twenty-four-hour on-site staffing for all maintenance activities are not always viable. The security architecture challenge is to accommodate these legitimate needs without creating the persistent, unmonitored connectivity that adversaries exploit.
The architecture I advocate for remote access to modernised SCADA environments has four essential characteristics:
Explicit, time-limited sessions. No persistent remote access connections. Every remote access session must be initiated explicitly, have a defined duration, and terminate automatically at the end of that duration. Vendor remote access in particular which in many legacy environments is implemented as a persistent VPN tunnel that the vendor controls must be converted to a session-based model where access is granted for a specific maintenance window and revoked on completion. The operational overhead of managing this is real and should be acknowledged; it is also substantially smaller than the overhead of responding to an incident that entered through a persistent vendor connection.
Jump host mediation with session recording. All remote sessions to the OT environment terminate on a jump host in the remote access zone. From the jump host, engineers can initiate sessions to specific systems in the supervisory zone, with those sessions conducted over protocols appropriate to the target system, RDP for Windows-based HMIs, SSH for Linux-based systems, proprietary protocols for engineering workstations. Every session, including vendor sessions, are recorded in full. Session recordings are stored in a tamper-evident log system that is accessible to the security operations function.
Multi-factor authentication, always. MFA is non-negotiable for remote access to OT environments. The credential compromise scenarios that lead to remote access exploitation, phishing, password reuse, pass-the-hash, are all mitigated by a properly implemented MFA requirement. Hardware tokens or authenticator applications are preferable to SMS-based MFA, which is vulnerable to SIM swapping attacks. For vendor accounts, consider certificate-based authentication tied to specific devices, so that a compromised vendor credential alone is insufficient to gain access.
Separate remote access infrastructure for OT. The remote access infrastructure for OT: the VPN gateway, the jump host, the authentication service, should be separate from enterprise remote access infrastructure. Enterprise VPN infrastructure is designed and managed for IT use cases, patched on IT timescales, and monitored by IT security operations. Its security posture is determined by enterprise IT requirements. Using the same infrastructure for OT remote access means that a compromise of the enterprise remote access infrastructure provides a path to OT systems. Separate infrastructure, separately managed, separately monitored, eliminates this risk.
Part 6: Managing the vendor ecosystem
SCADA modernisation programmes involve a complex vendor ecosystem: the SCADA platform vendor, the historian vendor, the field device vendors, the system integrator, the communications infrastructure supplier. Each of these vendors has legitimate requirements for access to the systems they supply and support. Each of them also represents a supply chain risk: a potential pathway through which a compromised vendor or a malicious insider at a vendor could reach the OT environment.
Vendor access management in modernised SCADA environments requires:
Vendor-specific accounts, not shared credentials. Every vendor that requires remote access should have a dedicated account in the remote access zone’s identity infrastructure. Shared vendor accounts: “support@vendorname” used by an unknown number of people at the vendor, cannot be audited, cannot be individually revoked when a vendor employee leaves, and cannot be attributed in session recordings. Insist on individual named accounts for all vendor personnel requiring access.
Software supply chain controls. vendor-supplied software: SCADA platform updates, historian patches, firmware for field devices, should be validated before deployment. This means receiving software through a defined channel, verifying cryptographic signatures or hashes against vendor-published values, and staging software in a test environment before deploying to production. The SolarWinds and Kaseya compromises demonstrated that software supply chain attacks against IT management tools are a proven adversary technique. OT software supply chains are, if anything, less mature in their security practices than the IT supply chains that were exploited in those incidents.
Contractual security requirements. Vendor contracts for SCADA system supply and support should include explicit security requirements: security testing of software before release, notification obligations for security vulnerabilities discovered in supplied components, requirements for individual named accounts rather than shared credentials, and obligations to comply with the operator’s OT security policies when accessing the operator’s environment. These requirements are increasingly standard in major energy operators’ procurement frameworks, but they are not yet universal, and their absence from contracts is a negotiating failure that has security consequences.
Part 7: The cutover: the highest-risk moment
Everything discussed above concerns the target architecture. The cutover: the period during which operations transition from the legacy system to the modernised system, is where the most acute security risks materialise, and where the most careful architectural planning is required.
During cutover, the legacy system and the new system typically operate in parallel. This parallel operation period introduces connectivity between old and new systems that does not exist in either the legacy architecture or the target architecture. It is, by definition, a temporary deviation from both. Temporary deviations are where security incidents happen not because adversaries time their attacks to coincide with cutover periods, but because the people responsible for security are most stretched, the change management processes are most complex, and the documentation of what is connected to what is least complete.
The security architecture for the cutover period should be explicitly designed, separately from both the legacy and target architectures, and should include:
A network topology diagram specific to the cutover period, showing every connection between legacy and new systems, the protocols used, the firewall rules required, and the business justification for each connection.
A defined decommissioning plan for every cutover-specific connection, with explicit acceptance criteria that must be met before the connection is removed. The plan should be agreed before the cutover begins, not negotiated after.
Enhanced monitoring during the cutover period, including network traffic baselines for the new architecture that allow anomalous behaviour to be detected against the expected pattern. The first weeks of operation of a new SCADA system are when its normal behaviour is established; they are also when any adversary who has observed the modernisation programme will be most likely to attempt to exploit the transitional state.
A rollback decision authority, explicitly named, with the authority to initiate rollback to the legacy system if the new system fails to perform as required. The rollback criteria should be defined in advance, specific performance thresholds, alarm rates, communication failure conditions, so that the decision can be made quickly and without ambiguity if needed.
Part 8: The operational technology security programme that modernisation requires
SCADA modernisation does not end when the new system is in production. It begins a new phase of the operational technology security programme that must be sustained for the lifetime of the modernised system,which, as noted at the outset, may be fifteen to thirty years.
The key elements of that programme:
Vulnerability management calibrated to OT constraints. The modernised system will accumulate vulnerabilities over its operational life. Some will be patchable through the OT change management process. Some will require compensating controls because patching is not feasible without a major maintenance window. Some will require acceptance as residual risk because neither patching nor compensating controls are viable within the operational constraints. The programme needs a formal process for each category, with documented rationale for risk acceptance decisions.
OT-specific security monitoring. he security operations function monitoring the OT environment needs OT-specific detection capabilities: monitoring for anomalous engineering commands (unexpected programme uploads or downloads to PLCs), unexpected changes to control logic, new devices appearing on the network, unusual traffic patterns in industrial protocols. Generic IT-focused SIEM rules do not provide adequate detection for OT-specific attack techniques. Purpose-built OT network detection and response (NDR) platforms — Dragos, Claroty, Nozomi — provide detection logic calibrated to industrial protocols and OT-specific attacker techniques.
Regular architecture review. The threat landscape evolves. New adversary techniques are documented. New vulnerabilities are discovered in OT components. The architecture that was appropriate at the time of modernisation may require adjustment as the threat and vulnerability landscape changes. A regular architecture review: at minimum annually, and triggered by significant threat intelligence developments or significant changes to the OT environment, is the mechanism for keeping the architecture current.
Conclusion: Modernisation as an architecture programme, not a project
The framing that causes most SCADA modernisation programmes to make poor security architecture decisions is the framing of modernisation as a project: a defined scope, a fixed budget, a delivery date, and a handover to operations at the end. Projects optimise for delivery. They do not optimise for the thirty-year security posture of the system they deliver.
The alternative framing is modernisation as an architecture programme: a sustained, governance-driven process of improving the OT environment while maintaining its operational and safety properties, with security architecture as a continuous discipline rather than a project phase. In this framing, the delivery of a modernised SCADA system is not the end of the programme, it is the beginning of the operational phase of a long-term security architecture commitment.
Energy operators who frame it this way make better decisions at every stage: they invest in the OT DMZ that the project manager wants to descope for budget reasons, they maintain the rollback capability that the project schedule makes inconvenient, they design the vendor access architecture that the vendor wants to simplify, and they sustain the security monitoring programme that nobody budgeted for at the start of the project.
The SCADA system that will be protecting your infrastructure in 2045 is being designed today, in the architectural decisions of current modernisation programmes. The quality of those decisions is determined by the quality of the security architecture input at the beginning of the programme, not at the end.
Get in the room early. Or accept the consequences of not being there.
Key references and further reading
- IEC 62443-3-3 — System Security Requirements and Security Levels. The technical requirements standard for IACS security, including zone and conduit design requirements directly applicable to SCADA modernisation.
- IEC 61511 — Functional Safety: Safety Instrumented Systems for the Process Industry Sector. The standard governing SIS design and independence requirements referenced throughout this post.
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security. Chapter 5 covers OT network architecture in detail relevant to the zone design described here.
- NERC CIP-005 — Electronic Security Perimeters. For bulk electric system operators in North America, the regulatory baseline for electronic security perimeter design.
- Waterfall Security Solutions — SCADA Security Architecture — Vendor documentation but technically substantive on unidirectional gateway architecture and historian boundary design.
- Dragos — OT Network Visibility and Detection — Technical documentation on OT-specific network detection and response capabilities referenced in Part 8.
- ISA-TR84.00.09 — Cybersecurity Related to the Functional Safety Lifecycle. The technical report addressing the intersection of IEC 61511 (process safety) and ISA/IEC 62443 (OT security) — directly relevant to the SIS independence requirements in Part 2.
- IOGP Report 627 — Cybersecurity for the Oil and Gas Industry. Industry guidance with specific applicability to upstream and midstream energy operators.
This post is part of an ongoing series on security architecture for critical infrastructure and energy systems. The next post examines the narrow but legitimate case for AI and machine learning in OT environments — specifically, where these technologies genuinely improve security and operational outcomes, and where they introduce more risk than they resolve.
About the author: Infrastructure Architect with 14 years of experience spanning enterprise architecture, operational technology environments, and regulated digital infrastructure. Currently leading infrastructure architecture for a major energy operator. Holds CISSP certification. Previously Technical Director at a digital health startup. Views expressed are personal.