What is Vulnerability Management?
Vulnerability management is the continuous process by which an organisation discovers, assesses, prioritises, remediates or contains vulnerabilities (security weaknesses) in systems, applications, networks and devices, and tracks the progress of that work. The aim is to prevent attackers from exploiting known weaknesses in your IT or OT environment. Vulnerability management is broader than patching: it also covers the decision to accept a vulnerability temporarily or to shield it with other controls. In industry that is the normal situation, because a PLC or SCADA server often cannot be updated straight away.
🧠 What exactly is a vulnerability?
A vulnerability is a weakness in software, firmware, hardware or configuration that an attacker can use to compromise confidentiality, integrity or availability. Typical examples:
- Outdated software with known bugs - for example a Windows version on an HMI that no longer receives security updates
- Unpatched firmware - in PLCs, RTUs, switches or the network cards of controllers
- Weak or default passwords - a classic with industrial equipment that is commissioned with factory settings
- Configuration errors - unnecessary open ports and services, or a web interface reachable without authentication
- Design weaknesses - industrial protocols that have no authentication or encryption
Publicly known vulnerabilities receive a unique CVE number. Configuration and design flaws usually do not, but they still belong in the process: a forgotten test account is just as exploitable as an unpatched flaw.
🔄 How does it differ from patch management and vulnerability scanning?
The three terms are often used interchangeably, but they are not the same:
| Term | Question it answers | Result |
|---|---|---|
| Vulnerability Scanning | Which known vulnerabilities are present in my systems? | List of findings per asset |
| Patch Management | How do we roll out updates in a controlled and safe way? | Tested and installed patches |
| Vulnerability management | Which vulnerabilities do we address, when and how, and who owns them? | Prioritisation, decisions, controls and reporting |
Scanning is therefore one source of information and patching one of the possible remedies. Vulnerability management is the overarching decision process that links both to risk, ownership and accountability.
🔁 How does the vulnerability management process work?
| Step | What you do | Explanation |
|---|---|---|
| 1. Inventory | Map all systems, applications and devices | Without an asset inventory that includes firmware and software versions, you do not know what is affected (Asset Management) |
| 2. Intake | Collect information on new vulnerabilities | Scans, vendor advisories, NCSC advisories, the KEV catalogue from CISA and machine-readable CSAF files |
| 3. Assessment | Determine whether and how the vulnerability can be exploited in your situation | Is the vulnerable function enabled? Is the system reachable? A VEX statement from the vendor helps eliminate false positives |
| 4. Prioritisation | Decide the order of action | Combine severity, likelihood of exploitation, active exploitation and business impact |
| 5. Remediation or mitigation | Patch, change the configuration or apply compensating controls | Through change management; in OT often scheduled in a maintenance shutdown |
| 6. Verification and reporting | Check that the control works and track trends | Rescan and record exceptions in the risk register |
The process is a cycle. New CVEs appear every day, so a one-off scan or audit quickly goes out of date. Vendors such as Siemens publish their advisories on a fixed day (the second Tuesday of the month), which gives a natural rhythm for assessment.
📊 How do you prioritise vulnerabilities?
Nobody can fix everything at once. Good prioritisation combines several signals, because each signal answers a different question:
| Method | Maintained by | Question | Output |
|---|---|---|---|
| CVSS | FIRST | How severe is the vulnerability technically? | Score 0.0–10.0; version 4.0 since 2023 |
| EPSS | FIRST | How likely is exploitation in the next 30 days? | Probability 0–1, updated daily |
| KEV | CISA | Is the vulnerability already being exploited? | Yes or no, with required action |
| SSVC | Carnegie Mellon SEI and CISA | Which action fits this vulnerability in our context? | Track, Track*, Attend or Act |
SSVC (Stakeholder-Specific Vulnerability Categorization) was developed in 2019 by the Software Engineering Institute at Carnegie Mellon University, together with CISA. It uses a decision tree based on exploitation status, technical impact, automatability, how deeply the affected product is embedded in mission-essential functions (mission prevalence) and the impact on public well-being. The output is not a number but an action: from Track (monitor and fix within normal timelines) via Attend (faster than normal timelines, with supervisors involved) to Act (leadership agrees the response and the flaw is fixed as soon as possible). The public well-being criterion in particular makes SSVC useful for critical infrastructure.
CVSS 4.0 also has a supplemental metric group that includes Safety and Automatable. These do not change the score, but they let a vendor state whether exploitation can have physical safety consequences: exactly the information that matters in OT.
🧱 Why is vulnerability management different in OT?
In OT, patching is often harder than in IT:
- Production continuity - a restart can stop a continuous or real-time process; patching waits for a planned shutdown
- Vendor qualification - updates for SCADA, PLCs, RTUs or MES must first be tested and approved by the system vendor
- Compatibility risk - a poorly tested patch can itself cause a production or safety incident
- Long service life - legacy systems often run for fifteen years or more, sometimes on operating systems without support
- Fragile devices - active scans can disrupt older controllers, which is why OT often relies on passive monitoring to infer versions and vulnerabilities
That is why compensating controls are a fully valid outcome of the process in OT:
| Situation | Compensating control |
|---|---|
| Vulnerable service on a PLC or HMI | Network segmentation following the zones and conduits model and a firewall that allows only necessary traffic |
| Vulnerability in a remote access path | Access only via a jump server in the DMZ, with MFA and time-limited approval |
| Data must reach the office or the cloud | One-way flow to a historian in the DMZ, with no direct connection to the control network |
| System without patch or support | Hardening, disabling unused services and additional network monitoring |
| Vulnerability reachable from the internet | Shut it off or shield it immediately; see internet-exposed OT |
Segmentation, access restriction and monitoring together form defence in depth: several layers, so that a single unpatched flaw does not lead directly to an incident.
🛠️ Which tools support vulnerability management?
- For IT - scanners such as Nessus, Qualys, Rapid7 and OpenVAS, complemented by patch tools for workstations and servers
- For OT and ICS - platforms from Nozomi, Tenable OT, Dragos and Claroty, which infer assets and vulnerabilities mainly passively from network traffic and query devices actively in a targeted way
- Vulnerability sources - the NIST National Vulnerability Database, the MITRE-operated CVE programme, the KEV catalogue, ENISA’s European Vulnerability Database and vendor advisories in CSAF format
- Component overview - an SBOM shows which software libraries a product contains, so you can quickly link a new vulnerability in such a library to your installations
🔐 Which standards and laws require vulnerability management?
| Framework | What it requires |
|---|---|
| ISO 27001 / ISO 27002 | Control 8.8: management of technical vulnerabilities |
| IEC 62443-2-1 | Vulnerabilities and patches as part of the asset owner’s security programme, within the IEC 62443 series |
| IEC TR 62443-2-3 (2015) | Exchange of patch information between asset owner and supplier |
| IEC 62443-4-1 | Manufacturers must set up defect management (DM) and security update management (SUM) |
| NIS2 / Cybersecurity Act | Article 21(2)(e): security in acquisition, development and maintenance, including vulnerability handling and disclosure; the Dutch Cybersecurity Act (Cbw) has applied since 15 August 2026 |
| Cyber Resilience Act | Manufacturers handle vulnerabilities throughout the support period (normally at least five years, shorter only if the product is expected to be in use for less time) and have had to report actively exploited vulnerabilities since 11 September 2026 (CRA reporting) |
| BIO | BIO2, adopted on 23 September 2025, follows ISO 27001/27002 and therefore includes technical vulnerability management |
Article 12 of NIS2 covers the other side too: each member state designates a CSIRT as coordinator for coordinated vulnerability disclosure (CVD), and ENISA maintains a European vulnerability database. In the Netherlands, the NCSC acknowledges a CVD report within one working day, assesses it within three working days and aims for a resolution within 60 days.
🧭 How do you set up vulnerability management in an OT environment?
- Assign owners - for each installation, an asset owner who decides on patching, mitigating or accepting, with an OT security specialist as adviser.
- Complete the inventory - including firmware versions, engineering stations and network components; passive detection supplements manual lists.
- Subscribe to the right sources - advisories from your own vendors (preferably as a CSAF feed), NCSC advisories and the KEV catalogue.
- Define prioritisation rules - for example: anything actively exploited and reachable from the internet or the DMZ takes precedence, regardless of the maintenance schedule.
- Link to the maintenance plan - schedule OT patches in planned shutdowns and test them first on a test system or redundant node.
- Document exceptions - every unpatched vulnerability gets a compensating control, an owner and a review date.
- Measure and improve - track, for example, inventory coverage, the number of open KEV vulnerabilities and the lead time from advisory to action; a periodic pentest tests whether the controls work.
If you record this, you can show a supervisory authority under the Dutch Cybersecurity Act that vulnerabilities are managed demonstrably and on a risk basis, even when not everything can be patched immediately.
❓ Frequently asked questions
Is vulnerability management the same as patch management?
No. Vulnerability management decides which vulnerabilities an organisation addresses, when and how; patch management is the controlled rollout of updates. Patching is one possible outcome of vulnerability management, alongside configuration changes, compensating controls or consciously accepting a risk.
How often should you scan for vulnerabilities?
In IT, you ideally scan continuously or on a short, fixed cycle and always after major changes, because new CVEs appear every day; internet-facing systems deserve the highest frequency. In OT, active scans are riskier, so passive monitoring that continuously infers versions from network traffic is used more often. Active scans of controllers are then scheduled and agreed with operations.
Why is a high CVSS score not always urgent?
CVSS measures the technical severity of a vulnerability, not the risk in your situation. A critical score on an isolated system without a network connection can be less urgent than a medium score on an actively exploited VPN gateway. That is why vulnerability management combines CVSS with EPSS, the KEV catalogue and the reachability of the system.
What do you do when an OT system cannot be patched?
When an OT system cannot be patched, you limit its exposure with compensating controls such as segmentation, strict firewall rules, hardening and additional monitoring. Record the exception in the risk register, with an owner and a date for reassessment. Also plan replacement or migration if the system no longer receives support.
Is vulnerability management mandatory under NIS2?
Yes. Article 21 of NIS2 explicitly lists vulnerability handling and disclosure as a mandatory security measure, and in the Netherlands this has applied through the Cybersecurity Act since 15 August 2026. ISO 27001, IEC 62443 and the BIO also require demonstrable management of technical vulnerabilities.
What is coordinated vulnerability disclosure?
Coordinated vulnerability disclosure (CVD) is the agreed reporting of a discovered vulnerability to the owner or manufacturer, so that the flaw can be fixed before details are made public. In the Netherlands, the NCSC mediates CVD reports, and NIS2 requires every member state to designate a CSIRT as CVD coordinator.
📌 In summary
Vulnerability management is a continuous process for finding, prioritising and demonstrably remediating or containing vulnerabilities in your IT and OT landscape. In OT it is less about patching as fast as possible and more about sound prioritisation, compensating controls and recorded decisions, so you reduce risk and comply with NIS2, IEC 62443 and ISO 27001.