Obsolete Operating Systems as Pivot Points: Analyzing Lateral Movement Risks in Legacy SCADA HMI Environments

Executive Summary

Legacy Windows operating systems—Windows XP, Windows 7, Windows Server 2003, and Windows Server 2008—embedded in supervisory control and data acquisition (SCADA) and human-machine interface (HMI) systems represent a persistent and systematic vulnerability category that remains underaddressed in critical infrastructure facilities despite documented multi-year exploitation campaigns. These systems, deployed in water treatment plants, electrical distribution networks, manufacturing facilities, and petrochemical operations, lack vendor security updates and serve as proven lateral movement pathways for both nation-state and financially motivated threat actors.

The technical barriers to exploitation are minimal; the organizational barriers to remediation are substantial. This analysis examines the technical mechanisms underlying this risk category, quantifies institutional significance, and provides stratified mitigation guidance aligned with operational constraints and budget realities. Organizations must prioritize legacy OS inventory assessment, network segmentation, and phased replacement scheduling within current capital planning cycles to meaningfully reduce lateral movement exposure.

What Happened

The widespread deployment of legacy Windows operating systems in critical infrastructure environments reflects a historical decision made when these systems were modern, supported, and considered secure. Windows XP reached end-of-support in April 2014; Windows 7 in January 2020; Windows Server 2003 in July 2015; and Windows Server 2008 in January 2020. Yet across North American and European critical infrastructure facilities—particularly in water and wastewater treatment, electrical grid operations, and manufacturing—these operating systems remain embedded in SCADA/HMI environments where they control critical processes.

The technical reality is unambiguous: unsupported operating systems receive no security updates. Vulnerabilities discovered after support ends remain permanently unpatched, creating a permanent attack surface against which threat actors can confidently develop and deploy exploitation toolkits.

Between 2024 and 2026, threat actors have repeatedly demonstrated the practical exploitability of this attack surface. CISA Advisory AA24-038A documented SCADA environment intrusions where threat actors leveraged legacy OS vulnerabilities as initial lateral movement vectors after establishing presence on corporate networks. The advisory specifically identified SMB-based exploitation, including variants of EternalBlue (CVE-2017-0144, the NSA-derived exploit disclosed by Shadow Brokers in 2017), as a primary mechanism for moving from less-critical systems to operational technology networks.

Dragos, the operational technology threat intelligence firm, documented in its 2026 OT/ICS Cyber Exposure report a marked increase in multi-stage exploitation campaigns targeting legacy OS systems as beachheads. These campaigns follow a consistent pattern: initial access is established on enterprise or DMZ systems through phishing, supply chain compromise, or insider action; threat actors then identify and exploit legacy Windows systems on adjacent networks; from the compromised legacy OS, attackers pivot to operational networks, harvest credentials from engineering workstations, and access process control systems. Time-to-objective has compressed significantly—organizations have documented compromise-to-critical-system-access timelines of 72 hours or less.

The sectoral concentration is notable. Water and wastewater treatment facilities show the highest documented concentration of legacy OS deployments, with some systems running Windows XP or Windows Server 2003 as of 2026. Electrical distribution utilities report similar challenges, particularly in distributed control networks serving rural or remote areas. Manufacturing facilities, especially mid-market operations in automotive and chemical sectors, frequently deploy legacy SCADA systems as process control backbones.

The exploitation chain is mechanically straightforward. An attacker with network access to a system running Windows XP or Windows 7 can execute remote code with minimal complexity. The SMB protocol (Server Message Block), used for file sharing and printer access in Windows environments, contains multiple exploitable vulnerabilities in legacy implementations. EternalBlue enables unauthenticated remote code execution on unpatched Windows systems. BlueKeep (CVE-2019-0708) and successor variants enable exploitation of Remote Desktop Protocol (RDP) services. Both vulnerabilities have mature exploitation toolkits available in public exploit repositories.

Once arbitrary code execution is achieved, the attacker has established a foothold on a system that lacks modern endpoint detection and response (EDR) capabilities and is unlikely to be monitored effectively. The attacker can then execute privilege escalation exploits to achieve local administrative access. Legacy Windows systems contain multiple kernel-level vulnerabilities enabling local privilege escalation; these are well-documented and easily exploitable.

From administrative access on the legacy OS, the attacker has multiple lateral movement pathways. Credential harvesting is the most direct: Windows systems store cached credentials, password hashes, and authentication tokens. Tools like Mimikatz can extract these from memory. In SCADA environments, credentials often have significant privilege levels—engineering workstations frequently store credentials with access to process control systems, historians, and HMI databases. The attacker can also exploit DCOM (Distributed Component Object Model) or RPC (Remote Procedure Call) protocols to execute code on adjacent systems without requiring credential transmission.

Network reconnaissance from the compromised legacy OS provides the attacker with topology information: system adjacency, running services, available protocols. SCADA networks often use standardized protocols (OPC, Modbus, Profibus, Ethernet/IP) that the attacker can probe and catalog. The attacker can then identify which systems control critical processes and execute process manipulation or data exfiltration.

The persistence of legacy OS deployment despite documented risks reflects several organizational factors. First, replacement cost and complexity are substantial. A legacy SCADA system running Windows XP may be embedded in a manufacturing process that runs 24/7 with zero tolerance for downtime. The software controlling the process may be licensed only for Windows XP. Replacement may require new hardware, operating system, complete application redesign, and re-testing. In a facility with a capital expenditure budget measured in tens of millions, a multi-year delay in legacy OS replacement represents rational economic prioritization.

Second, organizational silos between enterprise IT and operational technology (OT) teams create governance gaps. Enterprise security teams may lack visibility into OT systems; OT teams may prioritize uptime over vulnerability patching. Security frameworks like NIST SP 800-82r3 recommend legacy system isolation and compensating controls, but these recommendations assume robust segmentation capabilities that many facilities lack.

Third, detection and monitoring blind spots compound the problem. Legacy operating systems may not support modern EDR agents. Network monitoring tools designed for contemporary traffic patterns may not recognize exploitation of legacy protocols. Log aggregation is often incomplete in hybrid IT/OT environments. Behavioral baselining is difficult on legacy systems where change is infrequent and baseline behavior may be poorly documented.

Why It Matters

Critical Infrastructure Operators

The implications of legacy OS lateral movement extend far beyond the compromised system itself. A facility running multiple interconnected SCADA systems creates multiple risk pathways. An attacker with access to one legacy OS may pivot through the facility's engineering network, compromise a historian database, and establish persistent access to process control systems. In water treatment, this could mean tampering with chemical dosing systems. In electrical distribution, this could mean manipulating power routing or protection settings. In manufacturing, this could mean altering product specifications or safety interlocks. The cascading effect is significant. Compromised process control creates not just direct facility risk but supply chain risk. A water treatment facility is unlikely to be directly exposed to end consumers, but supply chain integrity affects municipal water systems serving populations. An electrical distribution compromise affects reliability for commercial and residential customers. Manufacturing contamination affects product distribution networks and customer operations.

Regulatory and Compliance Stakeholders

Regulatory frameworks and industry standards assume a baseline level of security that legacy OS deployments violate. NIST SP 800-82r3 explicitly recommends against deploying unsupported operating systems and mandates compensating controls if legacy systems cannot be replaced. NERC CIP standards, which apply to electrical utilities, require baseline security measures that legacy OS deployments struggle to meet. FDA 21 CFR Part 11, governing pharmaceutical manufacturing systems, similarly expects supported, patchable operating systems. IEC 62443, the international standard for industrial automation and control system security, contains similar expectations. The gap between framework recommendations and operational reality creates compliance risk. Auditors identifying legacy OS deployments without documented compensating controls flag these as findings. Insurance underwriters may exclude coverage for incidents involving legacy systems. Third-party assessments often mark legacy OS deployments as non-compliant. Organizations must choose between investing substantial capital to replace systems or documenting remediation plans that may extend years into the future.

Executive Leadership and Finance

The economic argument against legacy OS replacement is straightforward. A facility running a critical process on a legacy SCADA system faces several replacement options. Option one: replace hardware, operating system, and application software simultaneously. Cost: often millions of dollars; timeline: measured in years. Option two: virtualize the legacy application on a modern operating system in a dedicated virtual machine. Cost: substantial but lower; timeline: months of testing. Option three: air-gap the legacy system from networks while investing in modern replacement systems in parallel. Cost: ongoing operational burden; timeline: indefinite until replacement. In many facilities, budget allocation decisions weigh these costs against probability and impact. If a facility has operated a legacy SCADA system without incident for ten years, the perceived risk may appear lower than the certain cost of replacement. This calculation shifts significantly when lateral movement risk is quantified: if an attacker with access to an adjacent corporate network can reach process control systems within hours through legacy OS exploitation, the compromise probability is elevated. The compliance timeline adds pressure. Regulatory requirements to remediate legacy OS deployments often span years—a facility may be given three to five years to develop and execute a replacement plan. During this window, the legacy system remains operational and vulnerable.

Security and Risk Management

Nation-state actors have demonstrated explicit interest in this attack surface. Multiple publicly documented campaigns have targeted critical infrastructure with legacy OS exploitation as a component of broader operational technology reconnaissance or disruption preparation. Financially motivated threat actors have also shown sophistication in this space—ransomware deployment against SCADA environments has included lateral movement through legacy OS systems as a primary attack chain component. Board-level and executive awareness of this gap is often limited. CISOs may articulate the risk but lack authority to mandate capital spending. CTOs may prioritize operational continuity over vulnerability reduction. Operations directors may view security requirements as constraints on productivity. This organizational tension perpetuates legacy OS deployment.

Operational Implications

Immediate (0–30 Days): The operational risk posed by legacy OS systems can be quantified through several frameworks. First, probability of lateral movement success: an attacker with network access to any adjacent system segment has a high-probability pathway to execute code on legacy systems. This probability is constrained only by network segmentation effectiveness—and most facilities lack comprehensive segmentation. If segmentation is incomplete, the probability approaches near-certainty over multi-year periods. Impact scenarios are specific and severe. Water treatment facility compromise could result in contamination events affecting public health. Electrical distribution compromise could result in cascading outages affecting thousands of customers and critical services. Manufacturing compromise could result in product defects, safety incidents, or intellectual property theft. In each scenario, the facility faces operational disruption, regulatory investigation, reputational damage, and potential legal liability. Time-to-compromise estimates are measured in days or weeks. Threat actors need only identify a legacy system on an adjacent network, exploit a known vulnerability, escalate privileges, and establish persistence. Organizations have documented actual compromise timelines of 72 hours from initial network access to persistence on critical process control systems.

Short-Term (30–90 Days): Facilities must assess their vulnerability through a structured process. First, inventory: what legacy operating systems are actually deployed, where are they located, what functions do they control? Many facilities lack comprehensive asset management covering OT systems. Legacy SCADA systems may be undocumented in enterprise asset databases. Second, network adjacency: which legacy systems have network paths to operational networks? A legacy OS system that is physically isolated poses significantly different risk than a system connected to a process network or engineering network. Adjacency mapping requires understanding current network topology and often involves physical site surveys and network traffic analysis. Third, compensating control assessment: what protections currently exist? Network segmentation firewalls, endpoint security tools, monitoring and logging capabilities, access controls, incident response procedures? Each provides some risk reduction, but none fully mitigates the legacy OS vulnerability. The assessment must honestly evaluate the effectiveness of existing controls against documented threat actor capabilities. Fourth, skill and resource capacity: can the organization maintain legacy systems securely during a replacement transition? Legacy system management requires specialized knowledge. Engineering staff familiar with legacy SCADA systems may be nearing retirement, creating a skills gap that directly impacts the organization's ability to implement compensating controls or respond to incidents.

Medium-Term (90 Days–12 Months): Capital budgeting for legacy system replacement requires executive alignment across multiple stakeholder groups. Operations leadership cares about uptime and process reliability. Engineering leadership cares about functionality. Finance leadership cares about cost and schedule. Security leadership cares about risk reduction. These priorities often conflict. A facility may rationally choose to replace systems serving less-critical functions first (lower operational risk of downtime) rather than systems with highest security risk. This economically rational approach extends legacy OS deployment timelines and perpetuates vulnerability windows. Interim containment strategies—network segmentation, enhanced monitoring—can reduce risk while replacement is planned but require sustained operational investment. A facility implementing microsegmentation to isolate legacy SCADA systems may need to invest in network infrastructure, monitoring tools, and staff training. These ongoing costs must be budgeted indefinitely until replacement is complete. Vendor lock-in and product availability constraints further complicate planning. Legacy SCADA applications may be licensed only for specific operating systems. Vendors may be unwilling to re-license for modern operating systems. A facility planning replacement must navigate these constraints, often requiring vendor negotiation or selection of entirely new solutions.

Long-Term (12+ Months): Risk ownership for legacy OS deployment must be explicitly assigned. The CISO typically owns information security risk; however, legacy SCADA systems are often considered operational technology and may be outside the CISO's purview. The CTO may own technology strategy but may not be formally accountable for security outcomes. Operations directors own facility performance but may not prioritize security investment. This governance ambiguity perpetuates legacy OS deployment. Absent clear accountability for lateral movement risk, the path of least resistance is continued operation of existing systems. Executive boards must explicitly assign risk ownership, establish remediation timelines, and resource replacement projects. Communication to external stakeholders—regulators, auditors, insurers, customers—requires honest risk characterization. Many facilities currently describe legacy OS deployment as a 'known risk under mitigation' without specifying concrete remediation timelines or compensating control effectiveness. Transparent communication would likely accelerate replacement investment.

Recommended Actions

Actions are organized by organizational security maturity. Baseline controls apply across all tiers and should be treated as immediate priorities regardless of organizational size.

Closing Statement

The persistence of legacy Windows operating systems in critical infrastructure SCADA and HMI environments represents a systematic vulnerability that cannot be patched—only contained, compensated, or eliminated through replacement. This risk category sits at the intersection of technical reality (unpatched systems are permanently vulnerable) and organizational constraint (replacement is expensive and operationally complex). Neither awareness nor regulation has yet closed this gap at scale.

The organizations that will most effectively manage this risk are those that quantify it specifically, assign clear accountability for remediation, and resource replacement projects as strategic investments rather than optional upgrades. The technical mitigation strategies are known and implementable: network isolation, compensating controls, continuous monitoring. The governance challenge—making capital allocation decisions under constraint and executing multi-year projects in facilities designed for uptime rather than change—is substantially harder.

This moment in the threat landscape creates a decision window. Threat actors have openly demonstrated the exploitability of this attack surface. Regulatory pressure is increasing. Board-level awareness of legacy system risk is rising. Organizations that begin remediation now will benefit from extended timelines and lower pressure environments than those that wait for incident trigger or regulatory mandate. The cost of legacy OS replacement is measurable; the cost of facility compromise through lateral movement is existential.

Bridging the awareness gap between security frameworks and operational reality requires sustained executive engagement, honest risk communication, and resourced remediation. The tactical actions are clear; the strategic commitment required is what ultimately determines whether legacy systems remain permanent vulnerability vectors or become transitional artifacts of a more distant era.