OT Patch Management: The Complete 2026 Guide for IEC 62443

OT patch management sits on a genuine tension: your plant is exposed from the moment a vulnerability becomes public until the patch is installed, and a patch is a change to a system that controls a physical process. Resolve that tension deliberately and you have a programme. Leave it unresolved and the default resolution — never patching — becomes a decision nobody recorded.

This guide covers how to verify a patch before it goes anywhere near a controller, how to test it, how to decide what “timely” means for you, and why the record of what you deliberately do not patch is the more valuable half.

What this guide covers

• Why OT patch management is not IT patch management
• OT patch management step one: verify authenticity and integrity
• Test every patch for compatibility with your IACS
• What “timely” means in OT patch management
• Confirm the patch did not undo your hardening
• The OT patch management record of what you do not patch
• Where OT patch management breaks down in practice
• Building the OT patch management process
• Frequently asked questions
• Where OT patch management fits in the programme

Why OT patch management is not IT patch management

The differences are structural, not cultural.

• A patch can stop production. Automatic deployment is never acceptable on a control system.
• Security patches are usually issued for operating systems and infrastructure software developed independently of the control application — so the control application can be affected by them.
• Outage windows are scarce and scheduled months ahead.
• A large proportion of components cannot be patched at all, because they are past end of support or the supplier never issued one.
• Patching commonly re-enables services and restores default accounts, undoing hardening.

None of that is an argument against OT patch management. It is an argument for a process that differs from the corporate one at every step.

OT patch management step one: verify authenticity and integrity

Every OT patch management process starts here. The standard requires the authenticity and integrity of all patches to be verified prior to installation. Patches are intercepted and infected in transit, and they have been infected at the supplier’s own site.

Where digital verification is not feasible — common for older industrial software — apply a compensating measure and record it. Obtaining the file by two independent routes and comparing them, or getting a hash from the supplier through a separate channel, both work.

A patch that fails verification is not installed. It is quarantined and the supplier is contacted.

Test every patch for compatibility with your IACS

Test in a representative environment where one exists. Where the product supplier or service provider performs the testing — which is the usual arrangement — obtain and record their evidence, and note which versions and configurations it actually covers.

Where no test environment exists, test on a single non-critical component first. Where even that is impossible, record the position as a risk and schedule installation into a planned outage with a verified backup and a tested rollback.

Testing is the step OT patch management is most often criticised for skipping, and it confirms four things: the component functions, the control application functions, performance is unaffected, and communications continue.

What “timely” means in OT patch management

The requirement is installation in a timely manner after release, because the IACS is vulnerable until the patch is on. But timely is not the same for every patch.

Assess each applicable patch for severity and actual exposure in your environment. A high-severity vulnerability in a service that is disabled and unreachable does not carry the same urgency as a moderate one that is exposed across a conduit.

The vendor’s severity score is an input to your OT patch management decision, not the answer. It is assigned without knowledge of your architecture.

Confirm the patch did not undo your hardening

This step is skipped more often than any other in OT patch management, and it matters. After installation, confirm the patch has not degraded the component’s security.

Patching commonly re-enables an embedded web server, restores a default account, resets a logging configuration or reverts a hardening setting. Verify against your hardening documentation and configuration baseline, and restore anything the patch reverted. The change is not closed until that is done.

The OT patch management record of what you do not patch

In most industrial estates, more vulnerabilities are mitigated than patched. Recording only what was patched describes the smaller half of your position.

Raise a record whenever an applicable patch is not installed, for any reason:

• No patch exists — the supplier has not issued one, or the product is past end of support.
• The patch cannot be installed — the component cannot accept it, or installation would break the control application.
• Installation is deferred — no outage available, testing incomplete, awaiting supplier validation.
• The patch failed testing.
• The risk of installing exceeds the risk of not.

This is the half of OT patch management that carries the most weight in an assessment. Each record carries the vulnerability, the affected components, an exposure assessment, the mitigation applied, the residual risk, who accepted it and a review date.

Mitigations that actually reduce exposure

Disable the vulnerable service or feature. Restrict network access to the component or the affected port. Move it to a more restricted zone. Restrict which identities can reach it. Remove remote access to it. Tighten media and transient device control around it. Add monitoring for exploitation indicators. Increase integrity checking and backup frequency.

A mitigation recorded but not implemented provides no protection, and should not be credited in your risk register.

Where OT patch management breaks down in practice

Unknown versions. Components whose firmware or software version is unknown cannot be matched against an advisory at all. Track that count and drive it to zero — it is the population you cannot even reason about.

Deferrals that never end. A deferral extended more than twice has stopped being a deferral. Escalate it rather than re-dating it a third time.

Enterprise patch services reaching the plant. Patches should be staged in the demilitarised zone, verified, tested, approved and pushed under change control. Connecting control hosts to a corporate update service defeats the entire process.

No route back. OT patch management without a rollback is a one-way change. Installation should never proceed without a verified backup and a tested rollback. “We will restore from backup” is not a rollback plan unless somebody has actually restored from that backup.

Building the OT patch management process

Six documented steps cover the whole cycle, and an assessor will look for each of them:

1. Monitor. Subscribe to supplier advisories and to the national ICS advisory feed for your region, and match each advisory against your inventory. This step only works if the inventory records firmware and software versions.
2. Assess applicability and urgency. Decide whether the vulnerability is present, reachable and consequential in your architecture, and set a target date from that.
3. Verify. Authenticity, integrity and malware, before the file goes anywhere near the plant.
4. Test. In your environment, or on supplier evidence, or on one non-critical component.
5. Install under change control, with a verified backup and a tested rollback, inside a planned window.
6. Confirm and close. Component and process functioning, hardening intact, inventory version updated, record complete.

Two roles make OT patch management work in practice. Someone owns the process and the register — usually the OT security lead. Someone else, from operations, approves installation on each system, because they are the person who carries the production consequence. Splitting those two decisions is what stops patching being either reckless or permanently blocked.

Measure the programme on four things: applicable advisories assessed within your target window, patches installed against target date, open mitigation records with a review date in the past, and the count of components with unknown versions. Percentage-patched on its own tells you almost nothing about an industrial estate.

Frequently asked questions

How often should we patch OT systems?

There is no universal cadence, and imposing the corporate one is the classic mistake. The rhythm is set by your outage schedule and by per-patch urgency assessment. What matters is that every applicable patch is assessed and dispositioned, not that a fixed percentage is installed each month.

What if the vendor will not support patching?

Some vendors void support if you patch outside their validated releases. Record that constraint, follow their validated cadence, and treat the gap between vendor releases as a mitigation problem rather than a patching one. It is also a question to ask before you buy the next system.

Do we need a test environment?

It is the single most useful investment in OT patch management, but it is not the only option. Supplier test evidence, a single non-critical component, or a planned-outage installation with a verified rollback all work. What does not work is installing untested on a live control system and hoping.

What about end-of-support equipment?

No patch will ever come, so close the vulnerability as permanently mitigated, record the compensating measures, and feed it into the replacement case. A component accumulating permanent mitigations is making its own argument for replacement — that register is where the investment case gets evidenced.

Where OT patch management fits in the programme

Patching is easier when the network around a component is tight, which is why zones and conduits work makes OT patch management cheaper. The urgency assessment depends on your IEC 62443 security levels and on which zone the component sits in.

Patch management guidance for industrial environments is the subject of its own technical report in the series — see IEC 62443 parts explained for where 2-3 fits. The asset owner requirements themselves are in IEC 62443-2-1:2024.

Our IEC 62443 Toolkit includes the patch management procedure, the patch status and validation register, and a dedicated mitigation record for everything you deliberately do not patch. That last document is the one most estates are missing, and it is the one an assessor asks for first.