How can we reconcile IT patching policies with OT uptime requirements?

Reconciling IT patching policies with OT uptime requirements usually means replacing a generic “patch everything monthly” rule with a joint, risk-based approach. You will not get a single schedule that satisfies both sides; you need a structured compromise that treats OT differently from office IT while still addressing cyber risk.

1. Establish joint governance, not IT-only control

Start by making patching a shared responsibility between IT, OT/engineering, and quality, rather than an IT-driven activity:

• Create a cross-functional patching forum (IT security, OT engineering, operations, quality/validation where applicable).
• Define who can approve, defer, or reject patches on regulated or validated systems.
• Document decision criteria and keep records for auditability and future incident reviews.

Without explicit joint governance, IT will optimize for cyber posture and OT will optimize for uptime; both will be “right” in their own frame and the plant ends up with unmanaged risk and conflict.

2. Build an OT-specific patching policy

Using the corporate IT policy as-is in production environments rarely works. You need an OT-specific policy aligned but not identical to IT:

• Scope: Clarify that OT patch rules apply to PLCs, HMIs, SCADA, historians, MES nodes, lab systems, and equipment controllers, not just standard Windows/Linux clients.
• Risk-based approach: Tie patch urgency to exploitability, exposure (e.g., DMZ vs isolated cell), and safety/quality impact, not just vendor severity labels.
• Validation constraints: For regulated and validated systems, define when a patch requires revalidation or regression testing, and acceptable evidence for “no impact” determinations.
• Deferal rules: Explicitly define when and how patches can be deferred, for how long, and what compensating controls are required.

This policy should acknowledge that some OT assets cannot be patched on IT timelines because of validation burden, vendor support limitations, or high downtime impact.

3. Classify assets and patching criticality

Not all systems need the same patch cadence. Create a basic asset and criticality model and align patch expectations per class:

• Tier 1: Exposed or critical cybersecurity assets (firewalls, jump servers, remote access gateways, active directory, DMZ servers). These should track IT patch cycles as closely as possible, with high testing rigor.
• Tier 2: OT servers and infrastructure (MES, historians, batch servers, OPC servers) with production impact but that can be restarted in planned windows. Use monthly or quarterly cycles, with plant approval and rollbacks.
• Tier 3: Line-level HMIs, engineering workstations, and controllers where downtime and requalification are expensive. Patching might be quarterly, semi-annual, or aligned with major maintenance, based on risk and vendor guidance.
• Tier 4: Legacy or vendor-locked systems where patches are unavailable or would break support.

The key is that IT policies recognize these tiers explicitly instead of treating everything like a corporate laptop.

4. Use maintenance windows and patch waves

To reconcile uptime with security, formalize when and how you touch OT systems:

• Standard maintenance windows: Agree on fixed weekly or monthly windows per area or line, even if they are not always used. This allows IT to plan work without constant firefighting.
• Patch waves: Deploy first to test or lower-criticality systems, then to high-criticality assets once stable. For example, patch lab or pilot equipment first, then production lines.
• Seasonal constraints: Respect known blackout periods (e.g., peak production, qualification runs), documented in the patching plan.

Maintenance windows will still be tight in many plants, particularly in high-utilization or continuous-process facilities, so expectations for what can actually be patched each window must be realistic.

5. Always test and provide rollback paths

In OT environments, untested patches can cause quality escapes or extended downtime, not just user complaints. Minimize that risk by:

• Testing in a representative environment: Ideally a staging system or a virtualized copy of MES/SCADA where you can test key workflows against patched images.
• Coordinating with vendors: Use vendor-approved patch lists or images where they exist. Recognize that some suppliers lag behind IT patch cycles significantly.
• Ensuring backups and snapshots: Take full backups or system snapshots before patching. Validate that restores are actually feasible within your downtime window.
• Standardizing rollback decisions: Define what conditions trigger rollback (e.g., failure to start, data integrity issues, performance regressions) and who can authorize it on a live system.

Where systems are part of validated processes, capture evidence from testing and patch deployment as part of change control records.

6. Use compensating controls when you cannot patch

Some OT systems cannot be patched at all, or only very infrequently, because of vendor constraints, antiquated hardware, or validation impact. Acknowledge this openly and apply compensating controls instead of pretending to be compliant with IT policy:

• Network segmentation and isolation for high-risk legacy systems.
• Strict access controls and jump hosts instead of direct RDP/SSH from office networks.
• Application allowlisting and locked-down configurations on older Windows hosts.
• Increased monitoring and logging on unpatched systems and their network zones.
• Documented risk acceptance with a schedule for eventual remediation or replacement.

This does not eliminate risk, but it makes the residual risk visible and managed, rather than hidden behind nominal patch compliance metrics.

7. Integrate patching with change control and validation

In regulated environments, patches are changes that can affect validated state, data integrity, and audit trails. Reconciliation with OT uptime must respect these constraints:

• Route relevant patches through formal change control, with documented impact assessments, approvals, and post-implementation reviews.
• Define which component types require revalidation (e.g., MES application servers) versus those that typically do not (e.g., infrastructure hypervisors, with caveats).
• Use change records to capture what was patched, where, and how it was tested, for traceability in future audits or investigations.

This can slow patch cycles, especially for core systems. Recognize this constraint in the IT policy rather than trying to bypass it informally.

8. Account for brownfield complexity and long asset lifecycles

In many plants, replacing or upgrading OT platforms just to ease patching is unrealistic. Reasons include:

• Legacy MES/SCADA and controllers with limited vendor support and incompatible new OS patches.
• Integration dependencies across ERP, PLM, QMS, data historians, and custom middleware that make platform upgrades risky and costly.
• Qualification and validation burden for every significant software or hardware change.
• Limited downtime windows due to 24/7 operations or complex restart sequences.

Because full replacement is often infeasible in the short term, practical reconciliation relies heavily on segmentation, hardened configurations, selective patching, and disciplined change control rather than “modernize everything” strategies.

9. Make the tradeoffs explicit

Reconciling IT patching and OT uptime is essentially about explicit tradeoffs, not hidden compromises:

• Document which systems follow IT patch cycles and which follow OT-specific cycles, with rationale.
• Track deferred patches and their associated risks, including known vulnerabilities and compensating controls.
• Periodically review these decisions in the cross-functional forum, especially after incidents or near-misses.

This allows leadership to see where risk is being carried to protect uptime, instead of assuming uniform compliance that does not exist in practice.

Summary

Reconciling IT patching policies with OT uptime requirements requires a dedicated OT patching strategy, not a watered-down IT one. The key elements are joint governance, asset criticality tiers, realistic maintenance windows, robust testing and rollbacks, compensating controls where patching is infeasible, and tight integration with change control and validation. Outcomes will depend heavily on your current system inventory, vendor support, integration quality, and the maturity of your change and validation processes.