System Hardening in OT: PLCs, HMIs, and Engineering Workstations (Practical, Production-Safe)

98

System hardening in OT reduces incident impact without disrupting production by applying least functionality, least privilege, strong authentication, and controlled change to PLCs, HMIs, and engineering workstations. For PLCs, focus on access control to programming functions, firmware integrity, secure communications, and physical safeguards. For HMIs, harden the Windows build with application allowlisting, removal of unnecessary services, restricted USB, locked-down accounts, and controlled patching. For engineering workstations (EWS), treat them as high-privilege assets: use golden images, MFA-backed access via jump hosts, strict toolchain governance, project backup/version control, and logging of programming actions. Hardening is most successful when paired with OT network segmentation and maintenance-window validation.

Why OT hardening is different from IT hardening

OT environments can’t be hardened like typical enterprise endpoints because the success criteria are different:

• Availability and determinism come first. A “safe” change in IT can cause an OT outage if it impacts latency, protocol timing, licensing, or vendor tools.
• Legacy is common. HMIs and engineering stations may run older Windows versions due to vendor certification.
• Operational workflows are unique. Engineers may need specialized drivers, dongles, serial/USB adapters, and programming suites.
• Risk includes physical consequences. In OT, compromise can affect safety, quality, and equipment integrity—not just data.

So the best OT hardening programs optimize for:
risk reduction per unit of operational disruption.

---

What “hardening” means in OT (and what it doesn’t)

OT hardening (what it is)

Hardening is the disciplined process of reducing attack surface and increasing integrity by:

• disabling or removing unnecessary functions,
• restricting access and privileges,
• enforcing secure configuration baselines,
• controlling and monitoring change,
• and improving recovery readiness.

OT hardening (what it is not)

Hardening is not:

• “install EDR everywhere and call it done”
• “patch everything immediately”
• “block all USB and all remote access”
• “apply an IT GPO template to an HMI image with no testing”

In OT, hardening that breaks production is not hardening—it’s risk transfer to operations.

---

Hardening priorities: start where attackers win

If you can’t do everything, prioritize the assets and controls that most often determine incident impact.

The highest-leverage OT hardening targets

1. Engineering workstations (EWS): compromise here can lead to controller changes.
2. Remote access pathways: vendor access and jump hosts are common entry points.
3. HMI/SCADA Windows endpoints: common ransomware targets; loss causes visibility and control impact.
4. OT servers (historians, application servers, domain services): “shared dependencies” that amplify blast radius.
5. PLCs and safety controllers: integrity of logic/config and protection against unauthorized writes.

A simple prioritization model

Score each asset class by:

• consequence of compromise (C),
• exposure (E),
• privilege level (P),
• and recoverability difficulty (R).

One quick ranking formula:
Priority=3C+2E+2P+R

EWS and jump hosts typically score highest because privilege and consequence combine.

---

A production-safe hardening method (step-by-step)

Hardening succeeds in OT when it’s treated like engineering change—not like an IT push.

Step 1: Define “tiers” of OT assets

A practical tier model:

• Tier 0 (highest consequence / highest privilege): EWS, jump hosts, safety engineering stations, key OT servers
• Tier 1: HMIs, SCADA servers, historians, protocol gateways
• Tier 2: PLCs/RTUs, drives, I/O networks (integrity-critical, often low manageability)
• Tier 3: non-critical support systems (printers, kiosks, secondary reporting)

Your strictest controls go to Tier 0 and Tier 1.

Step 2: Build a baseline (golden configuration) per asset type

Create a “baseline standard” for:

• PLC families (by vendor/model),
• HMI images (by OS + vendor stack),
• EWS builds (by toolchain),
• jump host builds (by access method).

Baselines should include:

• required services and ports,
• accounts and privileges,
• patch/firmware posture rules,
• logging requirements,
• backup/restore method.

Step 3: Measure current state (don’t assume)

For each system type, document:

• what services are actually running,
• what remote access paths exist,
• who has admin access,
• what software is installed,
• what inbound/outbound flows are required.

Step 4: Apply hardening in “safe increments”

Use a staged approach:

1. Visibility first (logging, inventory, backup)
2. Low-risk reductions (remove unused accounts, disable unused services, restrict inbound admin)
3. High-impact controls (allowlisting, privilege reduction, conduit enforcement)
4. Governance (change control, exception expiry, quarterly review)

Step 5: Validate with operational tests

Every hardening step needs:

• a test plan (what must still work),
• a rollback plan,
• and a monitoring period after changes.

---

PLC hardening: controls that reduce manipulation risk

PLCs are often more stable than Windows endpoints, but they are integrity-critical. Hardening PLCs is less about “installing software” and more about access control, configuration discipline, and communication control.

1) Restrict who can program or modify PLC logic

Goal: make unauthorized changes difficult and detectable.

Practical controls:

• Require authentication for programming access (where supported)
• Use unique accounts (avoid shared “Engineer” logins)
• Remove or disable unused accounts
• Use role-based permissions (read-only vs modify)
• Restrict programming to approved engineering workstations only (via conduits)

Operational-friendly approach:
Even if the PLC itself has weak auth, you can enforce strong controls at the pathway:

• only allow programming protocols from the Engineering Zone,
• require jump-host access + MFA to reach Engineering Zone,
• log all engineering sessions.

2) Lock down operational mode changes

Many controllers support physical or logical protections:

• keyswitch positions (RUN/PROG)
• “write protection” or “memory protect”
• signed logic/config features (vendor-dependent)
• protected function blocks (where available)

Best practice: document and enforce a procedure for:

• who can place PLCs into program mode,
• how changes are approved,
• how changes are verified and recorded.

3) Reduce PLC attack surface: disable unused services and interfaces

Depending on platform, you may have:

• embedded web servers,
• FTP/TFTP services,
• SNMP,
• discovery services,
• unused Ethernet ports,
• serial bridges.

Hardening action: disable what you don’t use.
Validation: ensure HMI/SCADA and required diagnostics still work.

4) Control communications: allowlist by zone and function

PLC networks often get “over-connected” over time.

Conduit rules that reduce risk:

• allow HMI/SCADA polling only from known servers
• block SMB/RDP entirely (should not be needed for PLCs)
• restrict engineering protocols to specific EWS hosts
• restrict “PLC-to-PLC” routing unless required for the process

Key idea: PLCs should not be broadly reachable from IT or from general OT Windows subnets.

5) Firmware and configuration integrity

Firmware updates can reduce vulnerability—but also carry operational risk.

Recommended posture:

• maintain a firmware inventory by PLC model and line/unit
• update firmware during planned windows
• keep vendor-approved versions documented
• keep backups of controller programs/configs (including version and checksum)

6) Physical security (often overlooked)

PLC hardening includes physical controls:

• locked cabinets
• controlled access to programming ports
• port blockers where appropriate
• controlled use of portable programming devices

If physical access is easy, logical controls become less effective.

7) PLC backups and “known-good” baselines

Maintain:

• a known-good logic baseline for critical controllers
• a change history and approval record
• restoration procedures tested in a lab or non-production environment

Practical win: during incident recovery, you can validate integrity by comparing running logic/config to the baseline.

---

HMI hardening: locking down Windows without killing usability

HMIs sit at the intersection of OT usability and Windows risk. They’re often targeted by ransomware and are also critical for operations.

1) Remove unnecessary applications and services

Common items to remove or disable (as appropriate):

• web browsers (or restrict them heavily)
• email clients
• consumer software
• unused Windows features
• remote admin services not required

OT reality: sometimes vendor packages depend on specific services. So baseline creation must be tested against the vendor stack.

2) Implement application allowlisting (where feasible)

Allowlisting is one of the strongest controls for OT Windows systems because it blocks unknown binaries and “living off the land” payload drops.

Approaches:

• vendor-approved allowlisting
• Windows built-in controls (policy-based allow rules)
• tightly managed third-party allowlisting

Operational tip: start allowlisting in “audit mode” first to learn what’s required.

3) Account and privilege hardening on HMIs

Recommended:

• no shared local admin for daily operation
• dedicated operator accounts with least privilege
• separate admin accounts for maintenance
• remove unused accounts; rename/disable default accounts where possible

If the HMI must remain in a workgroup:

• keep local accounts unique per device (avoid the same password everywhere)
• use a local admin password rotation solution if possible

4) Lock down interactive access (kiosk/limited shell)

Many HMIs should function like appliances:

• auto-login to the HMI application (where appropriate and acceptable)
• restrict access to desktop, control panel, cmd/powershell
• disable unnecessary UI pathways that enable tampering

5) USB and removable media controls

USB is often needed in OT—but unmanaged USB is a common malware vector.

Practical middle-ground:

• designate a scanning station in the OT DMZ for removable media
• allow USB only for authorized users and only when needed
• block autorun
• maintain a procedure for “approved media” (labeling, chain-of-custody)

6) Patch strategy that respects uptime

HMI patching should follow:

• vendor guidance,
• lab testing (or a representative staging system),
• maintenance windows,
• rollback capability.

If you cannot patch quickly:

• compensate with segmentation,
• allowlisting,
• restricted admin pathways,
• and monitoring.

7) Endpoint protection (carefully configured)

EDR/AV can help—if tuned and tested. Avoid:

• aggressive quarantine that disrupts HMI runtime,
• scanning that increases CPU/IO during production,
• blocking OT executables because of uncommon behavior.

Best practice: define “OT safe mode” policies for HMI endpoints.

---

Engineering workstation hardening: the highest-leverage asset

Engineering workstations (EWS) are special because they often hold the keys to:

• controller logic changes,
• firmware updates,
• device configurations,
• project files and credentials.

If an attacker compromises an EWS, segmentation and PLC protections may still be bypassed through legitimate tools.

1) Treat EWS as Tier 0: isolate and protect like a crown jewel

EWS hardening typically provides the biggest risk reduction per device.

Core controls:

• place EWS in a dedicated Engineering Zone
• allow programming protocols only from this zone
• require access via a jump host with MFA
• restrict inbound connectivity (no direct access from IT desktops)

2) Use golden images and controlled rebuild processes

EWS should be rebuildable quickly and consistently:

• maintain a golden image per toolchain version
• document required drivers, dongles, and licensing steps
• keep vendor installers and hashes archived
• test rebuild in a lab

Why it matters: if an EWS is suspected compromised, rebuild is safer than “cleaning.”

3) Reduce software sprawl and toolchain drift

Engineering tools tend to accumulate over years.

Hardening actions:

• remove unused versions and unused vendor suites
• avoid “everything installed everywhere”
• separate toolchains by function when possible (e.g., safety engineering vs standard PLC programming)
• use virtualization if it helps isolate incompatible tool versions

4) Strong identity and least privilege on EWS

Recommended:

• no daily work as local admin
• separate admin accounts for tool installs
• restrict who can log in interactively
• enable MFA for remote access to the jump host (and ideally for privileged actions)

If EWS are domain-joined (OT AD):

• use GPOs tailored for OT, not copied from IT
• restrict domain admin reachability into OT zones

5) Control external connectivity: EWS should not browse the internet

Best practice:

• no direct internet access from EWS
• no email
• no general-purpose browsing

If vendor downloads are needed:

• use an IT workstation for downloads,
• stage through OT DMZ scanning and controlled transfer.

6) Project files: version control, backups, and integrity

Project loss can be as damaging as a malware event.

Maintain:

• centralized repository for PLC/HMI/SCADA projects (access-controlled)
• version history (who changed what, when)
• backups stored offline/immutable
• “known-good” tagged releases per production state

7) Logging and auditability for engineering actions

Aim to answer:

• which engineer accessed which controller,
• when changes occurred,
• what project version was used,
• and what approvals existed.

Even if full PLC change logging is limited by platform, you can log:

• jump host sessions,
• engineering workstation logins,
• file access to project repos,
• and conduit traffic to controller networks.

---

Hardening OT Windows services: historians, app servers, jump hosts

OT hardening isn’t complete if only endpoints are secured. Shared OT services often expand blast radius.

1) Historians and OT application servers

Hardening focus:

• restrict inbound admin protocols (RDP/SMB) to jump hosts only
• enforce least privilege for service accounts
• limit “talkers” that can write data
• ensure backups are protected and restore-tested

2) Jump hosts / access brokers (make them boring and controlled)

Jump hosts are security boundaries. Harden them as appliances:

• minimal software installed
• no web browsing
• tight admin control
• MFA-backed access
• session logging/recording where possible
• frequent patch cadence (validated)
• separate from general OT servers where feasible

3) OT domain services (if present)

If OT relies on AD/DNS:

• restrict admin access heavily
• isolate domain controllers in an OT services zone
• limit which zones can query or authenticate
• monitor for abnormal authentication patterns

---

Accounts, credentials, and privileged access in OT

Credential misuse is a common reason segmentation and hardening fail.

1) Remove shared accounts where possible

Shared accounts erase accountability and increase risk.

Where shared accounts are unavoidable (some legacy systems):

• use compensating controls: jump host access, session recording, strict approvals
• rotate passwords regularly
• restrict where the account can be used (logon restrictions)

2) Unique local admin passwords (avoid “same password everywhere”)

A single compromised local admin password can become instant lateral movement.

If feasible:

• implement unique local admin passwords per host
• restrict local admin group membership
• disable remote admin shares where not needed

3) Privileged access management (PAM) principles for OT

Even a lightweight OT PAM approach helps:

• time-bound privileged access
• approvals for high-impact actions
• separation of duties (operator vs engineer vs admin)
• strong logging and review

4) Service accounts and OT applications

Service accounts are often over-privileged and long-lived.

Hardening actions:

• document all service accounts (owner, purpose, permissions)
• reduce privileges to minimum required
• rotate credentials where possible
• monitor logon activity for service accounts (unusual times/hosts)

---

Patching, firmware updates, and maintenance windows

Hardening can’t ignore patching—but OT patching must be engineered.

Build an OT patch policy that matches reality

Define:

• which systems are vendor-certified and how updates are approved
• testing requirements (lab/staging where possible)
• maintenance windows and emergency change process
• compensating controls for deferred patches

Use risk-based patching

Prioritize patching when:

• the system is exposed (remote access path exists),
• the system is high privilege (EWS, jump hosts),
• the vulnerability is remotely exploitable,
• the asset is a shared dependency (historian, domain services).

Firmware updates for PLCs and network gear

Treat firmware like a planned engineering change:

• pre-check compatibility
• schedule downtime if required
• ensure you have rollback capability
• verify post-update behavior and communications

---

Backups, restores, and “golden images” for faster recovery

Hardening is incomplete without recovery readiness. In OT, “restore speed” often determines downtime cost.

What to back up (and how)

PLCs:

• controller programs/logic
• configuration and parameters
• firmware version records
• network settings
• “golden” baselines for critical controllers

HMIs and OT Windows systems:

• system images (golden images)
• application configs and license files
• HMI/SCADA project files
• historian databases (as appropriate)

Engineering workstations:

• tool installers + versions
• project files and version history
• hardware drivers and dongle/licensing procedures
• “known-good” VM images (if used)

Protect backups from ransomware

Recommended:

• offline or immutable backup copies
• separate admin credentials for backup systems
• restricted network reachability
• periodic restore tests

Restore tests: the difference between “we have backups” and “we can recover”

Set a schedule (quarterly for Tier 0/Tier 1 is a strong start) and test:

• restore of an HMI image
• restore of an OT server
• rebuild of an EWS
• validation of PLC logic baseline integrity

---

Logging and monitoring that supports OT investigations

Hardening reduces risk; monitoring helps you detect and respond when risk becomes reality.

What to log for OT hardening success

• authentication logs for jump hosts and OT servers
• remote access events (VPN + broker)
• changes to firewall rules on OT conduits
• Windows security logs (tuned) on HMIs/EWS/jump hosts
• controller programming activity signals where available (vendor tools or OT monitoring)

Monitoring use cases that benefit from hardening + segmentation

• new talkers to controller networks
• engineering protocol usage outside approved windows
• unusual admin logins to HMIs or OT servers
• lateral movement attempts blocked at conduits
• unauthorized changes to HMI/EWS configurations

---

Hardening validation: how to prove changes didn’t break production

Validation is the main reason OT hardening can be safe.

Build a “minimum operational test” per asset class

PLC validation:

• confirm process control remains stable
• verify HMI read/write operations
• verify alarms and interlocks behavior
• verify redundant comms where applicable

HMI validation:

• confirm HMI application launches reliably
• confirm required peripherals (printers, scanners, barcode readers)
• confirm network connectivity to required controllers/servers
• confirm performance under load (CPU/IO)

EWS validation:

• confirm programming tools function
• confirm ability to connect to controllers through approved paths
• confirm project open/build/download workflows (in a safe environment)
• confirm licensing/dongles work

Use maintenance windows and “one change at a time”

Hardening outages usually happen when teams change:

• firewall rules,
• endpoint policies,
• and server configurations simultaneously.

Do staged changes:

• enforce one boundary or policy,
• validate,
• then proceed.

---

Common mistakes (and how to avoid outages)

Mistake 1: Applying IT hardening templates to HMIs/EWS without testing

Fix: build OT-specific baselines and validate with vendor stacks in staging.

Mistake 2: Over-hardening PLC communications

Blocking needed services can cause intermittent process issues.
Fix: measure flows first, then allowlist minimally and monitor.

Mistake 3: Ignoring engineering workstations

Organizations often harden HMIs but leave EWS “as-is.”
Fix: treat EWS as Tier 0: isolate, control access, and standardize.

Mistake 4: “Security tools” that disrupt runtime

Aggressive EDR actions can break OT applications.
Fix: tune policies for OT, test, and prefer prevention via allowlisting and pathway control.

Mistake 5: No rollback plan

Fix: every hardening change gets a rollback plan and a stop condition.

---

30/60/90-day OT hardening roadmap

First 30 days: stabilize and build baselines

• classify OT assets into tiers (EWS/HMI/PLC/servers)
• document remote access paths and restrict obvious exposures
• create initial baselines for EWS and HMIs (software lists, services, accounts)
• ensure backups exist for projects and critical OT servers
• enable logging at jump hosts and conduits

Outcome: you can rebuild key systems and you understand current exposure.

Days 31–60: highest ROI hardening controls

• implement Engineering Zone access controls (jump host + MFA)
• remove shared local admin passwords (or start unique password rotation)
• implement application allowlisting in audit mode for HMIs/EWS
• restrict USB via policy + introduce a scanning workflow
• constrain admin protocols to jump hosts only

Outcome: reduced lateral movement pathways and better control of high-privilege actions.

Days 61–90: production-grade enforcement and verification

• enforce allowlisting (move from audit to enforce where ready)
• tighten conduits to controller networks (engineering protocols only from EWS)
• implement quarterly restore tests for Tier 0/Tier 1 systems
• formalize change control and exception expiry
• run a tabletop/technical drill: “suspected EWS compromise” rebuild + validation

Outcome: hardening becomes operational, measurable, and repeatable.

---

Checklists and templates (copy/paste)

Checklist: OT hardening readiness (applies to any change)

•  Asset tier and criticality known
•  Vendor support constraints reviewed
•  Current state captured (services, software, accounts, flows)
•  Backup completed (image/config/projects as applicable)
•  Maintenance window approved
•  Test plan written (what must still work)
•  Rollback plan written
•  Monitoring plan defined for post-change validation

PLC hardening checklist

•  Programming access restricted (accounts/roles)
•  Engineering protocols limited to approved EWS via conduits
•  Unused services disabled (web/FTP/SNMP/etc. as applicable)
•  Mode change controls enforced (keyswitch/protection)
•  Firmware inventory maintained and update policy defined
•  Logic/config backups stored and “known-good” baseline established
•  Physical access to cabinets/ports controlled

HMI hardening checklist

•  Unnecessary apps/services removed/disabled
•  Local admin usage minimized; operator accounts least-privileged
•  Application allowlisting deployed (audit → enforce)
•  USB controls + scanning workflow implemented
•  Browser/email restricted or removed
•  Patch strategy defined (test + maintenance windows)
•  Backup image and restore procedure tested

Engineering workstation hardening checklist

•  Dedicated Engineering Zone and controlled access (jump host + MFA)
•  Golden image maintained; rebuild process documented
•  No direct internet browsing/email
•  Toolchain minimized and controlled (no sprawl)
•  Project files versioned and backed up (offline/immutable copies)
•  Least privilege enforced (no daily local admin)
•  Engineering sessions logged; controller access monitored where feasible

Template: OT baseline record (one page per build)

• System type: HMI / EWS / OT Server / Jump Host
• Owner:
• Purpose:
• OS + version:
• Installed OT applications:
• Required services:
• Disabled services:
• Local accounts / roles:
• Network dependencies: (required ports, servers, PLCs)
• Patch/firmware policy:
• Backup method: image/config/projects + location
• Validation checklist:
• Rollback steps:

---

FAQ

What’s the single most important OT hardening target?

Engineering workstations (and the jump hosts used to access them). They often have the capability to modify PLC logic and configurations, so compromise there can turn an IT-style incident into a process integrity incident.

How do you harden HMIs without disrupting operators?

Start with low-risk changes (remove unused apps, restrict admin access), then implement application allowlisting in audit mode, and only enforce after validating required software behavior in a maintenance window.

Can you harden PLCs if they don’t support strong authentication?

Yes—by hardening the pathway: restrict programming protocols to approved engineering workstations, route access through a jump host with MFA, segment controller networks, and log engineering sessions and cross-zone access.

What if patching isn’t possible due to vendor certification?

Use compensating controls: segmentation (zones/conduits), application allowlisting, restricted remote access, least privilege, strong credential hygiene, and improved monitoring and recovery readiness.

How do you prove hardening didn’t break production?

Use a minimum operational test plan per asset class, implement one change at a time in a maintenance window, monitor process indicators post-change, and keep rollback procedures ready.