OT vulnerability management for Windows and Linux workstations

OT vulnerability management for Windows and Linux workstations means discovering, assessing, prioritizing and remediating, or deliberately mitigating, software flaws on the general-purpose computers that run supervisory control, historian and engineering functions inside a plant, without disrupting the physical process those computers support. That definition already implies a second, separate layer: the PLCs, RTUs and field devices that this same approach cannot safely touch.

This article is written for OT security leaders, plant engineering and automation managers, and OT engineers who are building or inheriting a vulnerability-management program and need to know exactly which layer a given tool, including Acronis, actually covers. It draws that line clearly, then works through what belongs on each side of it.

Key takeaways:

• OT vulnerability management splits into two genuinely different disciplines: the workstation layer (Windows and Linux systems running OT applications, including HMIs, historians, jump servers and other OT PCs, not only individual workstations) and the industrial device layer (PLCs, RTUs, IEDs and native industrial protocols). Treating them as one program can create blind spots or generate unsafe scanning traffic against fragile controllers.
• Patching is one possible remediation, not the definition of the discipline. Compensating controls, network segmentation, application allowlisting, restricted access and increased monitoring, are legitimate and common outcomes when OEM validation cycles or infrequent maintenance windows will not allow a patch.
• Mapping a vulnerability finding to MITRE ATT&CK for ICS and to an IEC 62443-3-2 zone and conduit turns a raw CVE list into a prioritized, auditable risk decision.
• Acronis Cyber Protect for OT brings backup, recovery and selected endpoint-management and security capabilities together in an integrated platform for PC-based OT systems (Windows- and Linux-based HMIs, SCADA hosts, historians, jump servers and similar systems). For the Local/on-premises deployment described in this article, current SalesFirst Acronis Cyber Protect materials document vulnerability assessment for supported Windows systems. The Acronis materials reviewed do not document vulnerability assessment of PLCs, RTUs, IEDs or industrial protocols. Organizations requiring that visibility should evaluate OT-native platforms such as Tenable OT Security, Claroty xDome, Nozomi Guardian and the Dragos Platform.

Quick definition: OT vulnerability management is the ongoing process of discovering OT assets and their vulnerabilities, assessing each one against technical exposure and operational or safety consequence, then remediating, mitigating with compensating controls, or formally accepting the resulting risk, without unnecessarily disrupting the industrial process. Remediation, mitigation and acceptance are three distinct outcomes, not synonyms: remediation closes the vulnerability, typically by patching; mitigation reduces the risk without closing it; acceptance is a documented decision to carry the risk unchanged.

OT vulnerability management is not enterprise IT vulnerability management pointed at a factory. It is the ongoing process of discovering assets and their vulnerabilities, assessing and prioritizing each one by technical exposure plus operational and safety consequence, then remediating, mitigating or formally accepting the resulting risk, without unnecessarily disrupting the industrial process. Dragos describes this as a cycle of asset discovery, vulnerability identification and classification, prioritization, then remediation, mitigation or acceptance. NIST SP 800-82 Rev. 3 independently frames OT security around performance, reliability and safety constraints that do not apply the same way inside a data center.

That framing rules out a shorthand definition of "scan and patch." Mitigation and acceptance are legitimate program outcomes, and NIST notes that OT patching is sometimes delayed or handled differently because of operational constraints. Any workable definition also has to hold two separate layers at once, covered next.

OT vulnerability management for Windows and Linux workstations is only half the discipline. A practical two-layer model, an editorial synthesis of NIST's own architecture rather than a term NIST uses verbatim, separates it cleanly.

The workstation layer (this article uses the term as shorthand for every Windows- and Linux-based OT PC in this category, including servers, historians and jump servers, not only individual workstations) covers general-purpose Windows, Unix and Linux systems used as engineering workstations, historians, maintenance laptops and backup servers, the computers that run HMI and SCADA software and sit inside the OT network without directly manipulating the physical process. Because these systems run standard operating systems, they can be affected by operating-system and application CVEs also encountered in IT environments, which is why CVE-based scanning is appropriate here in a way it is not one layer down.

The industrial device layer covers PLCs, RTUs, intelligent electronic devices and other field devices that communicate over OT-specific, often proprietary industrial protocols such as Modbus, DNP3 or PROFINET. This layer requires protocol-aware discovery and safe-querying techniques rather than conventional scanning, since standard IT probing can crash or destabilize legacy controllers.

Within the two-layer model used in this article, the Acronis materials reviewed document backup, recovery and selected endpoint-management and security capabilities for PC-based OT systems. For the Local/on-premises deployment described here, they document vulnerability assessment for supported Windows systems, not vulnerability assessment of PLCs, RTUs, IEDs or industrial protocols. Organizations requiring PLC, RTU or industrial-protocol visibility should evaluate an OT-native device-layer capability separately, a category covered in the next section.

Workstation-layer vulnerability management in OT means finding and assessing CVEs on the Windows and Linux systems, HMIs, SCADA hosts, historians, engineering workstations and jump servers that support the process, then deciding how to act on each finding given OEM validation cycles and infrequent maintenance windows.

Automation vendors qualify operating system updates before customers apply them. Rockwell Automation advises against applying Microsoft updates until Rockwell has qualified and published results for them. Siemens publishes Windows security-patch compatibility reports for relevant products. AVEVA likewise tests its industrial software against Microsoft updates and recommends scheduling installation during planned shutdown periods, since background updates can affect running processes. NIST adds that OS patching can alter how a control application interacts with the operating system, so patches should be tested offline or with the vendor before deployment.

The practical result: identifying a vulnerability on an HMI rarely triggers same-week patching the way it might in a corporate data center. More often it triggers a scoped decision between waiting for OEM validation and applying a compensating control, covered later in this article.

Industrial device-layer vulnerability management uses protocol-aware discovery to find and assess vulnerabilities on PLCs, RTUs, IEDs and other field devices without generating the kind of traffic that can destabilize them. Four vendors illustrate the category, described here from their own published materials rather than as a competitive ranking against Acronis, which does not operate at this layer.

The cited platform materials describe device and protocol visibility that the Acronis materials reviewed do not document, including identifying controller firmware and assessing protocol implementations while avoiding disruptive or unsupported network probing. The descriptions above are illustrative of the device-layer category; they are not recommendations, rankings or validated Acronis integrations, and readers should confirm current capability directly with each vendor.

MITRE ATT&CK for ICS is a separate matrix from the more familiar Enterprise ATT&CK framework, built to describe adversary tactics and techniques against industrial and cyber-physical environments, including tactics with no IT equivalent such as Inhibit Response Function and Impair Process Control. It should not be treated as a vulnerability scoring system or as something that automatically maps every CVE to an ICS technique.

The defensible workflow runs the other direction: start with a CVE finding, determine the credible exploitation behavior and the asset or process it affects, then map that behavior to the applicable ATT&CK technique. MITRE's Center for Threat-Informed Defense published a formal methodology for this kind of mapping, explaining that ATT&CK context connects a vulnerability finding to threat modeling and to compensating-control decisions.

Technique T0819, Exploit Public-Facing Application, is a workable example. It describes adversaries exploiting weaknesses in internet-facing software, including workstations, as an entry point into industrial networks, with software updating and vulnerability scanning listed among its mitigations.

When a Windows or Linux OT workstation cannot be patched immediately, because of OEM validation timelines, an unsupported operating system or a maintenance window that will not arrive for months, NIST recommends determining appropriate compensating controls rather than leaving the finding unaddressed.

Four controls recur across guidance:

• Network segmentation, separating OT from corporate networks and controlling communication between segments, which Dragos also names as a remediation alternative when patching is unavailable.
• Application allowlisting, well suited to the relatively static software footprint of an HMI or SCADA host, subject to vendor coordination and testing.
• Increased monitoring, more auditing and traffic inspection where other protections cannot be applied.
• Restricted, time-bound remote access to exposed systems.

None of these controls fix the underlying flaw. They reduce residual risk for however long remediation has to wait, and they are the mechanism that lets a vulnerability management program stay honest about risk it has not yet closed.

IEC 62443-3-2 is the system-design security risk assessment standard within the ISA/IEC 62443 series. It requires defining a system under consideration, partitioning it into zones and conduits, assessing risk for each one and setting a target security level with documented requirements. ISA Global Cybersecurity Alliance guidance on that workflow places vulnerability identification, drawing on vulnerability assessments, prior audits and vulnerability databases, among the inputs to the detailed risk assessment step, alongside likelihood, consequence and countermeasure analysis.

That is the bridge between an ongoing vulnerability-assessment process and a compliance document: findings from the workstation layer feed the zone and conduit risk calculation, they are not a stand-alone checklist item. IEC 62443-3-2 is a risk assessment standard, not a patching specification. Patch mechanics belong to a separate part of the 62443 series, not here.

Acronis Cyber Protect for OT brings backup, recovery and selected endpoint-management and security capabilities together in an integrated platform for PC-based OT systems: Windows- and Linux-based HMIs, SCADA hosts, historians, jump servers and patch servers, kept running and recoverable with legacy OS support, air-gapped operation and fast, operator-led recovery. The product page lists vulnerability assessment, patch management and hardware and software inventory among the platform's OT capabilities.

Backup and recovery support is explicitly documented across both Windows and Linux, with a range from Windows XP through Windows 11 and Windows Server 2003 through 2022, plus Linux kernels 2.6.9 through 5.19. Vulnerability assessment is a separate capability with its own scope. For Acronis Cyber Protect Local/on-premises, the current SalesFirst product materials reviewed document supported Windows systems.

For Acronis, a vulnerability finding is part of a broader recovery-ready approach: a PC-based OT system is assessed, protected before a change is made, and recoverable if that change or an attack disrupts operations. The Acronis materials reviewed for this article do not document vulnerability assessment of PLCs, RTUs, IEDs or industrial protocols. Organizations requiring that visibility should evaluate an OT-native device-layer capability separately, such as the platforms described above. Acronis frames its own scope the same way in its practices guidance: of eight recommended OT security practices, it covers two directly, compensating controls for unpatchable systems and image-based recovery, and recommends pairing with OT-specialist platforms for the rest, stating plainly that "the right architecture is not one vendor for everything".

When evaluating a PC-based OT system security tool, buyers should evaluate: whether scanning and assessment run safely without disrupting production, the exact operating systems and applications covered for each specific capability rather than the platform overall, suitability for air-gapped deployment, how the tool coordinates with OEM validation cycles rather than around them, the depth of severity and exploitability reporting, and how quickly an affected system can be recovered if a patch or an attack disrupts it. For patch qualification, testing, deployment and rollback mechanics, see our industrial patch management guide. To see how Acronis Cyber Protect for OT applies to a specific environment, talk to an OT specialist or start a trial.

How often should Windows and Linux OT workstations be scanned for vulnerabilities?

There is no universal scan-frequency rule for OT the way there sometimes is in IT compliance regimes. NIST SP 800-82 Rev. 3 calls for vulnerability identification on an ongoing basis and notes that scan technique and frequency should account for potential impact on OT equipment and communications. A defensible baseline is a risk-based cadence set by asset criticality, plus event-driven reassessment after a significant configuration change, a new high-severity disclosure or a known-exploited-vulnerability listing, rather than an invented weekly or monthly requirement.

Can vulnerability scanning itself disrupt OT systems?

Yes, and this is why workstation-layer and device-layer assessment use different techniques. NIST warns that vulnerability discovery methods can affect OT components and communications, and recommends testing scanning tools in an offline environment before running them in production. The device layer presents particular disruption concerns, since conventional IT scanner traffic can destabilize a legacy controller, which is why Tenable, Claroty, Nozomi and Dragos build passive monitoring and protocol-aware safe querying instead of running standard network scans against PLCs.

How should OT teams prioritize CVEs when patch windows are infrequent?

Start with more than a CVSS score. CISA recommends using its Known Exploited Vulnerabilities catalog as an input to prioritization, and OT-specific practice layers in asset and process criticality, network exposure and potential safety or availability consequence on top of that. As an illustrative scenario, not a universal ordering rule: an internet-facing engineering workstation with a known-exploited CVE could reasonably outrank a higher-CVSS finding on an isolated, air-gapped historian, because exposure and exploitation evidence change the real-world likelihood of attack for that specific pair of assets.

Can one platform realistically cover both the workstation layer and the industrial device layer?

That depends on what a specific product documents, not on a fixed industry rule. Workstation-layer assessment (Windows and Linux CVE scanning) and device-layer assessment (protocol-aware discovery of PLCs, RTUs and IEDs) are functionally different jobs that require different techniques and different safety guarantees. Evaluate each candidate against both requirements separately and confirm current documented capability directly with the vendor, rather than assuming either that one tool covers both or that any two tools are validated to work together. Acronis frames its own OT role this way, describing itself as covering two of eight recommended security practices and recommending specialist platforms for the rest rather than positioning itself as a full-stack replacement.

What happens when a Windows or Linux OT workstation reaches end of support and can't be patched?

If no vendor patch exists, NIST recommends considering an OS upgrade where the industrial application will support it, and layering additional protective controls, segmentation, allowlisting and restricted access, around systems that cannot be upgraded. Patch deferral on an unsupported system should come with compensating controls attached, not be treated as a dead end with no further action.

Is passive or active discovery better for OT vulnerability assessment?

Usually both, applied to different layers rather than as a single either-or choice. NIST recognizes both passive and active identification approaches and says the choice should account for operational impact. Passive OT sensors such as Nozomi Guardian continuously observe device, firmware and protocol context without generating traffic, while agent-based approaches to workstation assessment can surface OS and application-level detail that passive network observation alone does not expose.

What's the difference between OT vulnerability management and OT vulnerability assessment?

Vulnerability assessment is the discovery and scanning step: identifying which CVEs exist on which assets. Vulnerability management is the larger, ongoing discipline that assessment feeds into: prioritization, remediation, mitigation through compensating controls, or formal risk acceptance. A vendor description that says "vulnerability assessment" is describing one input to vulnerability management, not the whole discipline, which is why this article uses the more precise term wherever it is describing a single vendor's documented capability.