The most dangerous user in OT isn’t an operator. It’s a “trusted” update.

Attackers are increasingly winning through channels we treat as safe by default:
– Vendor tools and remote service utilities
– Signed installers and “legitimate” certificates
– Update servers and file shares
– Integrator and contractor laptops

In many environments, the update path is a blind trust workflow: download, run, deploy.

Flip the assumption. Treat every firmware patch, driver, and vendor package like an untrusted executable until it proves otherwise.

Before the next maintenance window, map your real update path end-to-end:
Supplier portal or media → IT staging → engineering workstation → jump host → OT network → asset

Then add verification gates that make compromise harder to propagate:
1) Provenance checks: verify publisher, signatures, hashes, and source integrity. Capture evidence.
2) Offline validation: scan and detonate updates in a non-production sandbox before OT exposure.
3) Staged rollouts: pilot on a representative test asset, then expand with change control and rollback plans.
4) Allowlist execution: only approved binaries, scripts, and drivers can run on engineering and maintenance systems.
5) Tooling control: isolate vendor utilities, restrict admin rights, and log every update action.

When you control the update chain, a supplier incident becomes a contained event, not a plant-wide outage.

If you had to prove today that your last OT update was authentic and unchanged end-to-end, could you?