Patching Vulnerabilities on the Factory Floor and in Medical Devices

In a typical enterprise, a critical vulnerability on an internet-facing server is a 24-hour patch. In a medical-device manufacturer, the same CVSS score on a production controller or a fielded infusion pump is one of the hardest problems in security — because you often cannot patch it without risking either a stopped production line or a patient's safety. This is where a disciplined patch lifecycle meets its most demanding test.

The standard patch lifecycle

Every patch, everywhere, should move through the same repeatable, tracked lifecycle:

Step	What happens
1 · Identify	Vulnerability & missing patches detected by scanners
2 · Assess	Risk-score, business impact, dependencies
3 · Test	Deploy to staging; regression & smoke tests
4 · Approve	Change Advisory Board (CAB) review for production patches
5 · Deploy	Rolling release via SCCM / Intune / Ansible / CI-CD
6 · Verify	Rescan to confirm the fix; close the ticket; report

Actively exploited (KEV) vulnerabilities bypass the standard CAB cycle and follow an expedited 24-hour path with post-deployment review. That works for IT assets. Now watch what happens on the factory floor.

Why the factory floor is the hard part

Operational technology (OT) — the PLCs, HMIs, SCADA, and manufacturing execution systems that run a production line — breaks almost every assumption the IT lifecycle makes:

• Uptime is revenue and product. A production line runs continuously; an unplanned reboot can scrap in-process batches and halt output. Patch windows are rare and scheduled quarters ahead.
• The OS is frozen and often unsupported. Controllers run embedded or legacy Windows validated years ago; the vendor may void support — or the equipment's regulatory validation — if you patch it.
• Active scanning can crash fragile devices. Aggressive vulnerability scans have knocked PLCs offline; OT needs passive discovery and careful, credentialed checks, not IT-style hammering.
• The network is flat. Legacy OT segments were built for reliability, not isolation, so one compromised HMI can reach the whole line.

You cannot simply push Patch Tuesday to a filling line. The tools (SCCM/Intune) and the 24-hour clock do not apply.

Why the devices themselves are harder still

The manufactured medical devices and their embedded applications add a regulatory dimension no IT patch has:

• A patch is a regulated change. Under design controls and software-lifecycle rules (21 CFR 820, IEC 62304), a software change may require re-verification and re-validation — and, depending on impact, a regulatory notification or filing rather than a simple letter-to-file.
• Patient safety gates everything. A rushed patch that changes device behavior can harm a patient; validation is not bureaucracy, it is the safety case.
• Lifecycles are 10–20 years. Devices in the field run operating systems and libraries long past vendor support, with vulnerabilities that will never get an upstream fix.
• You must know what's inside. A software bill of materials (SBOM) — now expected in premarket submissions — is what lets you map a new CVE to every device and application that embeds the affected component.
• Fielded devices aren't laptops. A pump in a hospital or an analyzer in a lab can't be reached by your endpoint patch channel; updates are coordinated, staged, and sometimes require a field service visit.

How you actually manage it

You do not lower the security bar — you change the mechanism from "patch fast" to "reduce risk defensibly":

• Compensating controls first. Network micro-segmentation and VLAN isolation, application allowlisting, and EDR where the platform supports it contain the risk while a validated patch is prepared. In the risk score, these controls are a first-class input.
• Risk-accepted, time-boxed exceptions. When a 24-hour patch is impossible, the output is a documented exception with named compensating controls and a validation-and-deploy date — not a silent missed SLA.
• Staged validation environments. Mirror the line or the device configuration so patches are regression-tested against the real safety case before they touch production or a patient.
• SBOM-driven monitoring. Continuously match new CVEs against every device's component list, so you learn about exposure the day a CVE lands, not at the next audit.
• Virtual patching as a bridge. WAF/IPS rules and protocol filtering blunt an exploit while the validated fix works through change control.
• Coordinate with the vendor and the regulator. Coordinated vulnerability disclosure, vendor patches validated for the device, and regulatory notification where the change requires it.

Bringing it back to the unified program

None of this lives outside the unified vulnerability program — it lives inside it. OT and fielded devices are asset classes in the same inventory; their findings are scored by the same composite model (with asset criticality and compensating controls weighted appropriately); and their exceptions are tracked in the same repository as every IT patch. The difference is the remediation path, not the visibility.

The path to implement

1. Inventory OT and fielded devices in the same asset graph as IT — no separate spreadsheet.
2. Discover passively on OT; never point an aggressive IT scanner at a production controller.
3. Drive SBOM-based CVE matching so device exposure is known immediately.
4. When you cannot patch, apply compensating controls + a time-boxed, risk-accepted exception.
5. Validate every device/OT patch in a mirrored environment before production, coordinating vendor and regulatory steps.

Incipient's LineageLens catalogs OT and device assets alongside IT with their SBOM and dependency graph, and GovPilot manages the risk-accepted exceptions and audit evidence — so a patch you cannot apply in 24 hours is still a governed, defensible decision.

On the factory floor and in a fielded device, the goal is not "patch fastest" — it is "reduce risk without breaking a safety-critical, regulated system." That is an engineering discipline, not a scanner setting.

Talk to us about OT & device vulnerability management →