You've done the foundations — Purdue, defense in depth, 62443, secure remote access. This is the sequel for the questions that actually stump teams in the field: how do I handle a CVE I can't patch? what really stops ransomware reaching OT? how do I write PLC code that's secure by design? what does the law require? Six hard parts, with a CVE-triage simulator and a data-diode you can test.
In IT you patch on Tuesday. In OT the controller runs 24/7, the patch needs a vendor-validated shutdown, and sometimes there is no patch. So OT vulnerability management isn't "patch fast" — it's triage + compensating controls. The question is never "is it vulnerable?" (everything is) but "is it exposed, and what can I do around it?" Work the case below.
A compensating control reduces the risk of a vuln you can't remove: segmentation, disabling the affected service, an IDS rule, stricter access. A high CVSS score on an asset an attacker can't reach is lower real risk than a medium one sitting on a flat network.
Prevention fails eventually — the test of a program is recovery. OT recovery is its own discipline: the backups IT keeps don't include your PLC programs, HMI projects, drive parameters or network config. Here's what "recoverable" really means on the floor.
💾 Back up the right things
PLC logic and firmware versions, HMI/SCADA projects, drive & instrument parameters, network/switch config, the OS images of engineering workstations. A "file backup" of a server misses all of it.
🔌 3-2-1, and offline
3 copies, 2 media, 1 off-site — and at least one offline / immutable so ransomware can't encrypt your backups too. The gold copy is air-gapped, not on the same domain.
⏱️ Rehearse the restore
An untested backup is a rumour. Time a full controller restore. Know your RTO (how fast you must be back) and RPO (how much data you can lose) — and whether you can run manually meanwhile.
🚨 The hard truth: in many OT ransomware cases the plant goes down not because OT was encrypted, but because IT was — and operators lose the MES, historian, EWS and the confidence to keep running. Recovery planning must cover "IT is gone, can the line run safely without it?"
Most ICS security is network and access — but the person writing the logic has real power too. Secure-by-design means the code itself fails safe and distrusts its inputs. Three habits that cost nothing and prevent real incidents:
① Validate every externally-writable value — an HMI or MES can be compromised.
// HMI writes the setpoint straight to the process
Tank_SP := HMI_Setpoint;// clamp to safe engineering limits, always Tank_SP := LIMIT(SP_MIN, HMI_Setpoint, SP_MAX);
② Fail to a safe state on lost comms — don't hold the last command forever.
// if MES/HMI dies, valve stays wherever it was
Valve := Remote_Cmd;IF CommsAlive THEN Valve := Remote_Cmd; ELSE Valve := FALSE; // fail closed END_IF
③ Least privilege in the controller itself — and integrity you can check.
Use the PLC's user roles so an operator HMI can't download logic; keep the controller keyswitch/mode in RUN-locked; enable change detection (a logic checksum/audit log) so an unauthorised download is visible. Secure-by-design = the attacker who reaches the wire still can't quietly rewrite your program.
A firewall filters traffic both ways — and a misconfig or exploit can open it. For the highest-assurance boundary (e.g. sending plant data out to IT while letting nothing back in), you use a data diode: hardware that physically can only pass light one direction. Try to send a packet the wrong way through each and watch what happens.
A firewall can allow return traffic (and be misconfigured or breached to allow more). A data diode is physics — there is no return path to misconfigure, which is why they guard safety systems, generation plants and anything where "absolutely nothing comes back in" is the requirement.
Past a certain sector or size, OT security stops being best-practice and becomes law, with audits and fines. You don't need to memorise the clauses — you need to know which regime applies to your plant and what it forces you to do.
| Regime | Who it covers | What it forces |
|---|---|---|
| NERC CIP | Bulk electric power (North America) | Asset inventory, electronic security perimeters, access control, recovery plans — audited, with real fines. |
| EU NIS2 | "Essential/important" entities — energy, water, food, manufacturing (EU) | Risk management, incident reporting (early warning ~24 h), supply-chain security, management accountability. |
| TSA Security Directives | US pipelines & rail | Segmentation, access control, continuous monitoring, an actioned incident-response plan. |
| IEC 62443 | Cross-sector reference (often cited by the above) | Zones & conduits, security levels SL1–4 — the "how" many regulators point to. |
| FDA 21 CFR / GMP | Pharma & food | Data integrity, audit trails, validated systems — security overlaps with traceability. |
🧭 The shift to know about: regulations like NIS2 now put personal accountability on management and demand supply-chain security — you're responsible for your vendors' security too, not just your own perimeter.
The last two gaps are the ones teams skip until they're burned. Both are about threats that walk in through the front door — in a software update, or on two legs.
📦 Supply chain & SBOM
A single library flaw ripples across hundreds of vendors (recall the CODESYS-runtime CVEs). An SBOM — Software Bill of Materials — lists every component inside a product, so when the next library CVE drops you can answer "am I affected?" in minutes, not weeks. Demand SBOMs from vendors; verify firmware signatures; vet update channels.
🔒 Physical security
All the segmentation in the world fails if someone opens the panel and plugs into the service port, or walks off with the engineering laptop. Lock the cabinet, disable/epoxy unused USB ports, control physical keys, badge the control room, and treat the EWS like crown jewels. The air gap is also a door someone can walk through.
🧩 Tie-back: every "advanced" topic here is still the same principle from the foundations — assume breach, limit blast radius. A CVE you can't patch, a vendor you can't fully trust, a person at the panel: you can't eliminate them, so you contain what they can reach.
The grown-up additions to the foundations checklist — the things audited programs actually do.