What are practical first steps to secure an old SCADA system?

Old SCADA systems are common in regulated plants and are rarely designed for today's threat landscape. You usually cannot replace them quickly due to validation burden, vendor dependence, and downtime constraints. The most practical first steps focus on containment, visibility, and basic hardening rather than major architectural change.

1. Get a clear, current picture of what you have

Security decisions are unreliable without an accurate inventory. For legacy SCADA, even basic visibility is often missing.

• Build an OT asset inventory: SCADA servers, engineering workstations, operator HMIs, PLCs/RTUs, gateways, historian, protocol converters. Capture OS versions, firmware levels, vendor, location, and criticality.
• Map network paths: Identify how these systems connect to each other, to the plant network, and to corporate IT. Focus on firewalls, unmanaged switches, wireless bridges, and any "temporary" links that became permanent.
• Document external dependencies: Remote vendor access, outsourced monitoring, cloud connectors, remote support tools, and any modem, VPN, or cellular access.

Where tooling is immature, combine static network diagrams, switch MAC tables, and carefully planned passive network monitoring. Avoid intrusive scanning that may disrupt fragile legacy devices.

2. Put the SCADA system behind strong network boundaries

Network segmentation is usually the highest-leverage first move that does not require changes to the legacy SCADA software itself.

• Create or tighten an OT zone: Place SCADA components in a dedicated network segment with clearly defined boundaries to corporate IT and external networks.
• Use a DMZ for data exchange: Route traffic between SCADA and enterprise systems (MES, historian replication, reporting) through a DMZ where you can control and monitor protocols.
• Apply "default deny" at boundaries: On firewalls, block all traffic by default, then explicitly allow only required ports, directions, and endpoints.
• Remove direct internet access: SCADA servers and HMIs generally should not have direct outbound internet access. Where business processes require it, route through proxies with strict controls.

These changes typically require coordination with IT networking and may need downtime windows. In regulated environments, treat segmentation changes as controlled changes with impact analysis and rollback plans.

3. Lock down remote access first

Remote access is a frequent entry point, particularly in plants that rely on vendors or central engineering teams.

• Identify all remote paths: VPNs, remote desktop services, vendor support tools, jump servers, modems, cellular gateways, and "backdoor" connections set up for maintenance.
• Consolidate through monitored jump hosts: Prefer a single, hardened remote access path (or a very small number) into the OT environment, using jump servers in a DMZ.
• Enforce strong authentication: Implement multi-factor authentication where feasible for remote connections, at least at the VPN or jump host level.
• Restrict privileges and schedule access: Use least privilege for remote users and restrict access windows (for example, only during approved maintenance periods).
• Log and review: Ensure remote sessions are logged. For high-risk systems, consider session recording or at least robust command and connection logs.

If existing vendor tools cannot meet security expectations without impacting support, treat that as a risk to be formally accepted or mitigated with extra monitoring and compensating controls.

4. Improve basic hardening without breaking the system

Many old SCADA systems cannot be patched or reconfigured aggressively without risk. Focus first on controls that are low-risk and reversible.

• User accounts: Remove unused accounts, eliminate shared generic admin accounts where possible, and ensure default vendor passwords are changed. When shared accounts are unavoidable, implement procedural and logging controls.
• Password policies: Within system limitations, enforce nontrivial passwords and periodic changes, balancing security with the operational risk of lockouts.
• Services and ports: Disable unnecessary services on SCADA servers and HMIs, but only after testing in a representative environment or low-risk window.
• Removable media: Restrict or control USB and external media usage. If technical controls are weak, introduce procedural controls and logging at minimum.
• Antivirus and application allowlisting: On Windows-based SCADA servers and HMIs, implement antivirus tuned for OT, with exclusions carefully tested. Where feasible, consider allowlisting, but recognize that legacy applications can be fragile.

Every hardening action in production should pass through change control, with documented testing and a rollback plan, especially where validated systems are involved.

5. Establish monitoring that fits plant realities

Monitoring is often minimal in OT. Even basic visibility into abnormal connections and changes can dramatically reduce dwell time for threats.

• Centralize logs where possible: Forward Windows event logs, firewall logs, and VPN/jump host logs to a central collector. Integration into an existing SIEM or log platform is ideal but not mandatory for a first step.
• Use passive OT network monitoring: Consider a network sensor or span port feeding an OT-aware monitoring tool to identify new devices, unusual communications, or clear policy violations.
• Define a simple triage process: Decide in advance who reviews alerts, at what frequency, and what constitutes escalation in a 24/7 manufacturing context.

Do not try to mirror IT-grade monitoring complexity on day one. Start with a small set of high-value alerts linked to known risks, then mature over time.

6. Address patching and upgrades pragmatically

Legacy SCADA often cannot be patched to current IT standards without jeopardizing validated state or vendor support. Treat patching as a risk management problem, not a box-ticking exercise.

• Baseline current versions: Understand which components are unsupported or out of vendor maintenance, and which are still patchable.
• Coordinate with vendors: For core SCADA applications and PLC firmware, use vendor-approved patch levels and follow their upgrade guidance.
• Prioritize perimeter patching: Firewalls, jump hosts, remote access gateways, and domain controllers interfacing with OT should be more aggressively patched, with strong regression testing.
• Use compensating controls: Where patching is infeasible, lean harder on network isolation, strict access control, and monitoring. Document these as formal compensating controls for audit and risk reviews.

Full platform replacement is sometimes the only long-term answer for very old SCADA that cannot be reasonably secured. In regulated and high-availability plants, this is usually a multi-year program with staged migrations, detailed validation, and carefully scheduled cutovers, not a quick fix.

7. Define roles, procedures, and change control

Even strong technical measures will fail without basic governance.

• Clarify ownership: Decide who owns OT cybersecurity decisions for SCADA (for example, joint OT/IT governance), and ensure that roles and responsibilities are documented.
• Integrate with existing change control: Treat SCADA security changes like any other critical system change: risk assessed, reviewed, tested, approved, and documented.
• Create simple, usable procedures: Remote access approval, account creation and removal, USB usage, backup and restore, and incident response steps should be documented and trained.
• Backups and recovery: Ensure you have tested, offline-capable backups of critical SCADA servers and configuration (including PLC/RTU programs) so you can recover from both failure and security incidents.

8. Choose a realistic starting roadmap

Trying to fix everything at once typically fails in brownfield environments. Instead, create a short list of immediate, high-impact actions that fit your constraints.

For many plants, a practical initial sequence looks like:

1. Document assets, network paths, and remote access into the SCADA environment.
2. Harden remote access: centralize through a jump host, add MFA, remove unused paths.
3. Tighten firewall rules between SCADA, IT, and the internet to "default deny" plus explicit necessary traffic.
4. Clean up accounts and passwords on SCADA servers, HMIs, and associated Windows systems.
5. Turn on basic centralized logging for key systems and define a simple alert review process.

Deeper hardening, patching, and architectural improvements can then be phased in over months and years, synchronized with planned outages, validation cycles, and vendor roadmaps.