Back to Blog
    ot-patch-management

    OT Patch Management: A Practical Guide for Manufacturers

    Dustin CollettNovember 10, 2026

    OT patch management is the process of identifying, prioritizing, testing and deploying software and firmware updates on the systems that run your production floor: PLCs, HMIs, SCADA servers, historians and the networks between them. It is not IT patching on a slower clock. A patch on a plant system is an engineering change, so you decide what to patch, when, and how you will roll it back before anything is installed. This guide lays out a process a Wisconsin manufacturer can run with a small team.

    TL;DR

    • Start with a current inventory of every OT asset, including exact firmware versions and whether the vendor still supports it.
    • Rank patches by exposure and operational consequence, not by CVSS score alone.
    • Test on off-line or spare hardware, take a verified backup, and confirm you can remove the patch.
    • Apply patches in planned maintenance windows. Where you cannot patch, use compensating controls and document the risk you accepted.
    • Keep a written policy and a register of deferred patches so an auditor, insurer or customer sees a controlled process.

    Table of Contents

    Why OT patching is not IT patching

    In an office, a patch that breaks a laptop costs someone an hour. On a production line, a patch that changes communication timing between a controller and a drive can stop a line, scrap product or create a safety problem. That difference drives every other decision in this guide.

    SANS Institute's Dean Parsons writes that patching in ICS and OT environments does not normally follow traditional IT patching processes, schedules or methodologies, and that effective patching needs engineering-informed analysis and close coordination with the engineers who run the process. Four practical differences follow.

    Uptime. Many industrial processes run around the clock. EE Times explains that such systems can typically be updated only during scheduled maintenance periods, often once a quarter or twice a year.

    Age. The same article notes that industrial equipment can be 15 or more years old, so patches have to be carefully tested before they go anywhere near production.

    Hardware specificity. A patch may be written for the firmware of devices currently on sale rather than the version you have installed. Nexus Connect reports that OT patches are tailored to specific hardware deployments and must account for backward compatibility.

    Vendor control. Many controllers and machine-embedded PCs carry vendor certification. Installing an update the vendor has not validated can put support, and sometimes the warranty, at risk.

    The standards world treats this as its own discipline. ISA's technical report ISA-TR 62443-2-3 on patch management for industrial automation and control systems describes what suppliers and asset owners each do, and recommends a defined format for passing security-patch information between them.

    Step 1: Build an inventory you can trust

    You cannot patch what you cannot see. Every other step depends on this one.

    A useful OT inventory lists every networked device: PLCs, RTUs, DCS controllers, HMIs, engineering workstations, SCADA servers, historians, firewalls and switches. For each one, record the exact firmware or software version, the vendor, and whether the vendor still supports that hardware and firmware combination. That is the baseline Beacon Security describes for OT patch programs.

    Practical tips for a mid-sized plant:

    1. Walk the floor. Spreadsheets from the last project usually miss the machine-embedded PCs, the vendor laptops left behind and the Wi-Fi bridge someone added.
    2. Record who owns each asset, the production line it serves and what happens to the product if it stops.
    3. Note how each asset connects: to the plant network, to the office network, to the internet, or to a vendor's remote access tool.
    4. Capture the support status. "Vendor no longer issues patches" is the single most useful field when you plan compensating controls later.
    5. Include the less obvious devices. IP cameras, badge readers and building controls often share the plant network and run their own firmware. If you manage cameras there, a walkthrough such as ONVIF profile migration steps for technicians shows why you should confirm installed models and supplier guidance before changing anything.

    Our guide to IT/OT convergence for manufacturers covers how to draw the line between your office network and your plant network, which makes the inventory far easier to keep current.

    Step 2: Prioritize by risk, not by score

    Once you know what you have, match it against known vulnerabilities. ISA recommends using automated tools that compare your OT inventory with NIST's CVE database and ICS-CERT advisories to find affected assets and available patches.

    Then resist the urge to sort by CVSS. SANS states that CVSS scores are insufficient on their own for prioritizing ICS patching, and that ranking on score alone can cause downtime or safety risk with very little security payoff. Better inputs are the threat vector, how critical the asset is, what downtime would cost and how the threat landscape is moving.

    ISA gives a clear example: a critical vulnerability (CVSS above 9.0) on a training asset should wait behind a high vulnerability (7.0 to 8.9) on a safety system monitoring poisonous gas, because exploiting the second one affects people, the environment and the plant. The same article is where that guidance comes from, so read it in full: ISA's OT patch management best practices.

    A simple scoring approach that works for a small team:

    FactorQuestion to askRaises priority when
    ExposureCan the asset be reached from the internet, a vendor VPN or the office network?Reachable from outside the plant
    ExploitationIs the flaw being used in attacks?It appears in CISA's Known Exploited Vulnerabilities catalog
    ConsequenceWhat happens if this asset fails or is compromised?Safety, environmental or line-down impact
    Compensating controlsDo segmentation, allow-listing or monitoring already limit the risk?No such controls exist
    Patch riskHas the vendor validated the patch for your version?Validated and tested

    Exposure often outranks the raw score. Beacon Security's example: a moderately scored flaw on an internet-facing historian can deserve more urgency than a higher-scored flaw on a PLC reachable only from one isolated workstation.

    Who decides? CISA's recommended practice says reviews should be done by people who know the system and its use, with authority to set the urgency of patching, and that scheduling is a business decision. In practice that means operations, engineering and IT sit in the same room, and the plant manager signs off.

    Step 3: Verify the patch before you trust it

    A patch is software from a third party that you are about to put on a system you cannot afford to lose. Confirm three things:

    The same document recommends a test environment that closely simulates operations, with dedicated test-bed hardware. You do not need a full replica of the plant. A spare PLC, an engineering workstation image and a virtual copy of the SCADA server will catch most problems. CISA's broader guidance says to test all patches in off-line test environments before implementation.

    Step 4: Deploy inside a maintenance window

    SANS notes that mature ICS organizations have moved beyond "patch everything month" and instead apply updates during planned engineering maintenance windows that match operational needs and the analysis of risk to operations.

    Before each window:

    1. Take a backup you have verified. CISA's practice requires a current, functional backup or archive made before patching, a last good snapshot of the working production system. The plan should state backup frequency, how it is created, how it is verified, how long it is retained and where it is stored. See CISA's patch management practice.
    2. Test the rollback. Confirm in the test environment that the patch can be removed without disrupting operations.
    3. Write the checklist. CISA recommends checklists and procedures so patching is accurate and repeatable. Include who does what, the order of systems, the go or no-go point and the contact for the vendor's support line.
    4. Line up the vendor. Where the vendor must validate or install the update, book them early. Windows are rare and fixed, so missing one can delay remediation for months.

    After the window, check that the process runs normally, confirm communications between PLCs, SCADA and historians are healthy, and record the result.

    Backups are the safety net under all of this. Our guide to managed backup and disaster recovery explains how to structure and test them so the "last good snapshot" actually restores.

    When you cannot patch: legacy and vendor-controlled systems

    Every plant has a machine that runs an operating system its vendor retired years ago. Patching it may not be possible, and replacing it may be a capital project that is two budgets away.

    A layered approach, as described by the EngineersUniverse editorial team, works well:

    1. Patch the highest-risk systems during planned outages.
    2. Put compensating controls around systems that cannot be patched.
    3. Track unpatched systems in a risk register, with residual risk accepted in writing by the asset owner.

    Typical compensating controls are network segmentation, firewall rules that allow only the traffic the machine needs, application allow-listing, removal of direct internet access, restricted and logged vendor remote access, and monitoring for unusual traffic. These can reduce the effective risk of a vulnerability even before it is patched.

    CISA also advises organizations to replace out-of-date software and hardware. Your risk register is the argument for doing so: it turns "this old box worries us" into a documented risk with a cost.

    For more on the exposure side, see our article on what industrial IoT security requires.

    Patching air-gapped networks

    An air gap does not remove the need for patches. It changes how they arrive. Every transfer by USB drive or laptop is a path for malware, so the transfer process needs the same discipline as the patch itself.

    CISA's guidance on updating antivirus in an ICS describes a model you can borrow. Updates move by removable media to a patch server in the control center DMZ. You verify the update source and hashes, handle media securely, and install first on corporate IT, then the ICS DMZ, and finally the ICS network, with non-critical assets first. The details are in CISA's recommended practice.

    A sound transfer routine includes:

    • A dedicated, hardened workstation used only to prepare media.
    • Malware scanning of the files before they cross the gap and again on the other side.
    • Hash verification against the vendor's published value.
    • A log showing who handled the media and when.
    • Media that stays in the plant's controlled custody, not in a toolbox.

    Write the policy down

    An OT patch policy is short. It should state:

    • Who owns the inventory and how often it is reviewed.
    • How vulnerabilities are monitored and who reviews them.
    • The scoring method used to set priority.
    • Testing requirements and who approves production changes.
    • Backup and rollback requirements.
    • How deferred patches are documented, with the compensating controls, the owner who accepted the risk and the date to review again.

    ISA's 62443-2-3 report is the reference for the supplier and asset-owner activities a policy should reflect. Regulated sectors have their own rules, such as the NERC CIP standards for the electric sector, so check whether any apply to you. Most manufacturers are not covered by them, but customers, insurers and frameworks like NIST 800-171 increasingly ask for the same evidence. Our NIST 800-171 self-assessment guide shows how to score your own documentation honestly, and our NIST and CISA aligned patch management guide covers the IT side of the same program.

    A realistic first 90 days

    PeriodFocusOutput
    Days 1 to 30Inventory and segmentation reviewAsset list with versions, owners and support status
    Days 31 to 60Risk ranking and test setupPrioritized patch list, test bed, backup verification
    Days 61 to 90First maintenance window and policyCompleted change record, risk register, written policy

    The goal is not to clear every patch in 90 days. It is to have a repeatable process, so the next window goes faster than the first.

    Our perspective

    Most manufacturers we meet do not have a patching problem. They have a visibility problem and an ownership problem. Nobody can say with confidence what is on the plant network, and nobody owns the decision to change it.

    We treat IT and OT as one environment with different rules. The office side gets steady, automated patching. The plant side gets inventory, segmentation, tested change windows and documented exceptions. Both sit under one standard stack, one fixed per-user cost and one team that answers the phone.

    That is why we do not sell patching as a tier or an add-on. Proactive infrastructure ownership, 24/7 monitoring, backup and audit-ready documentation are part of how we work, so the risk register, the rollback plan and the evidence are there when a customer, insurer or auditor asks for them.

    If a system cannot be patched, that is not a failure. It is a documented decision with controls around it, and we help you make it.

    Dustin Collett

    How Collett Systems can help

    We provide managed IT for small and mid-sized businesses in West Bend and Southeastern Wisconsin, including manufacturers that cannot afford security or downtime surprises. Our work covers 24/7 monitoring, proactive support, backup and disaster recovery, compliance documentation and security management for a fixed cost per user.

    The best place to start is a paid look at what you actually have. Our IT & Security Assessment gives you a clear picture of your environment and a prioritized list of fixes.

    Collett Systems LLC

    If you already have an internal IT or engineering team, co-managed IT services let us carry the monitoring, patching and documentation load alongside them. You can also see how managed IT services work, or use our security assessment checklist to score yourself first. For the wider picture, read our manufacturing cybersecurity guide.

    FAQ

    How often should OT systems be patched?

    There is no universal interval. Plants patch when a planned maintenance window allows it, and often that means once or twice a year for critical processes. Review vulnerabilities continuously, then schedule the patches that your risk ranking supports for the next window.

    Should we patch every OT vulnerability?

    No. Prioritize by exposure and operational consequence. Some flaws are better handled with segmentation or allow-listing while you wait for a window, as long as you document the decision and revisit it.

    Can we use our IT patching tool on the plant floor?

    Not without care. Many OT devices need vendor-validated updates, and automatic deployment can break communications or void support. Use IT tooling for office systems and standard Windows hosts that the vendor has cleared, and use engineered change control for controllers and machine PCs.

    What do we do about unsupported equipment?

    Isolate it, restrict what can talk to it, monitor it and list it in your risk register with a named owner. Then build its replacement into your capital plan, so the risk has an end date.

    Sources