Computing Library › Security & Safety-Critical Computing
Security & Safety-Critical Computing

Patch Management for Critical Systems

Keeping software current closes known vulnerabilities, but on safety-critical systems patching itself carries risk and must be managed carefully.

The Patching Dilemma

Most successful attacks exploit known vulnerabilities for which a patch already existed. Applying patches promptly is one of the highest-value security practices. Yet on safety-critical and operational systems, a patch can also break a certified configuration, disrupt a process, or require a shutdown to install. The discipline of patch management balances closing known holes against the operational risk of the change itself.

Why OT Patching Is Hard

Kronos motion — current ramp

A Managed Process

Effective patch management inventories what runs (an accurate SBOM helps), tracks disclosed vulnerabilities against that inventory, assesses severity and exposure, tests patches in a representative environment before deployment, and schedules installation during controlled maintenance windows. Patches are prioritized by real risk, an exposed, exploitable flaw first, not applied blindly in bulk.

Compensating Controls

When a system cannot be patched, whether legacy, certified, or unpatchable, security shifts to compensating controls: tighter segmentation, stricter access, and closer monitoring around the vulnerable device. Isolation reduces the exposure a missing patch would otherwise create.

Fusion Context

For the Hyperion breeder and burner control systems, patching follows the OT pattern: tested, scheduled, and staged so that a security update never compromises the safety case or interrupts a process uncontrolled. Where a device cannot be patched during operation, segmentation and monitoring compensate, and the independent safety instrumentation continues to protect the machine regardless of the patch state of the supervisory layer.