NIS2 vulnerability management: scans, patching and evidence for servers and VMware hosts

What NIS2 requires for vulnerability management

NIS2 vulnerability management rests on Article 21(2)(e) of the NIS2 Directive, Directive (EU) 2022/2555, which lists “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure” among the minimum measures. Commission Implementing Regulation (EU) 2024/2690 spells this out in point 6.10 of its Annex. A relevant entity under the regulation obtains information about technical vulnerabilities in its systems, evaluates its exposure and must “take appropriate measures to manage the vulnerabilities”. It monitors advisories, runs vulnerability scans where appropriate at planned intervals with a record of the results, and addresses vulnerabilities critical to its operations “without undue delay”.

Two neighbouring points complete the requirement. Point 6.6 sets the rules for security patches, and point 6.5 asks for a policy and procedures for security testing. None of the three sets a scan frequency or a patch deadline in days. The entity fixes its planned intervals and internal target times in its policy. Point 6.5.2(a) ties the frequency of security tests to the risk assessment.

All ten measures are covered in our guide to NIS2 Article 21 security measures; this article covers point (e) for an estate of 10 to 60 VMware hosts and 500 to 2,000 VMs.

Who Implementing Regulation 2024/2690 binds

The regulation binds only the “relevant entities” of its Article 1. These are DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed and managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers. Other essential and important entities take their obligations from Article 21 through the national act that transposes the directive, and can use the Annex as a detailed EU-level reference although it does not bind them. ENISA’s NIS2 Technical Implementation Guidance, published on 26 June 2025, follows the Annex requirement by requirement.

Your managed service provider may be bound directly. Point 5.1.4(f) also lists, for supplier contracts, “an obligation on suppliers and service providers to handle vulnerabilities” that present a risk to the entity’s systems. What customers ask their IT suppliers is in our guide to NIS2 supply chain requirements. Whether your company is an essential or important entity is a legal assessment for your legal department.

Points 6.10, 6.6 and 6.5: what to implement and the evidence

Each row gives an Annex requirement, a way to implement it in a VMware estate and the evidence an auditor can ask for.

Implementing Regulation (EU) 2024/2690, Annex points 5.1.4, 6.5, 6.6 and 6.10 (eur-lex.europa.eu, read 6 and 10 October 2026). The implementation and evidence columns are our summary for a VMware estate.

Our cyber resilience assessment reviews infrastructure, access, backups and compliance with NIS2 requirements and ends with a risk map and a prioritised action plan. Tell us how you scan and patch today and which records you already keep.

Asset inventory and scan scope for 10 to 60 VMware hosts

Scanning starts from the asset inventory, which point 12.4.1 requires to be “complete, accurate, up-to-date and consistent”. Advisories are matched against this inventory, so a system missing from it is left out of the matching. For a VMware estate the inventory lists each vCenter instance and ESXi host with its build number and the servers’ management controllers with their firmware. It also holds the VMs with their operating systems and owners, the backup server, the firewalls and the switches.

The scan scope has three layers. Guest operating systems on 500 to 2,000 VMs are scanned with credentials, because an authenticated scan reads installed packages and missing patches that a network scan from outside the guest cannot reliably see. The management network, where vCenter, the ESXi hosts and the management controllers sit, gets network scans from a scanner placed in that network. For ESXi and vCenter, compare each build number with the response matrix of every relevant Broadcom advisory, whatever the scanner reports. The scanner’s accounts are privileged accounts, kept under the controls described in our guide to privileged access management.

A company of this size can set a monthly authenticated scan of all VMs, a weekly scan of systems reachable from the internet and a build check of ESXi and vCenter whenever Broadcom publishes an advisory. Write the schedule into the policy and keep every dated report, since point 6.10.2(b) asks entities to “record evidence of the results of the scans, at planned intervals”.

VMware security advisories and the patch order for vCenter and ESXi

Broadcom publishes vulnerabilities in VMware products as VMware Security Advisories (VMSA). The vulnerability response policy hosted on Broadcom’s documentation site, a VMware document dated August 2022, maps its severity ratings to CVSS ranges: Critical covers 9.0 to 10.0, Important 7.0 to 8.9, Moderate 4.0 to 6.9 and Low 0.1 to 3.9. The policy adds that the ratings “do not depend only on the CVSS scoring”. Each advisory lists the affected supported products in a response matrix with the fixed version and any workaround.

VMSA-2025-0004 of 4 March 2025 shows how an advisory reads. Broadcom rated it Critical, with a CVSS score of 9.3 for CVE-2025-22224, and stated that it “has information to suggest that exploitation of CVE-2025-22224 has occurred in the wild”. The fixed build for ESXi 8.0 Update 3 was ESXi80U3d-24585383, and the workaround column said “None”. According to NIST’s National Vulnerability Database, CISA added the CVE to its catalogue of known exploited vulnerabilities on 4 March 2025, the day of the advisory. A company would usually rate an exploited flaw with no workaround as critical to its operations, to be addressed “without undue delay” under point 6.10.2(c).

Broadcom’s KB 314601 gives the usual order in its examples: “vCenter must be upgraded first”, and “Then the ESXi version follows”. The same KB allows ESXi to be ahead in minor update paths, “especially when an express patch has been released for ESXi without a corresponding path for vCenter”. VMSA-2025-0004 itself covered ESXi, Workstation and Fusion, not vCenter. KB 308161, the update sequence for vSphere 8.0, puts vCenter Server at step 11, ESXi at step 12, VMware Tools at step 13 and virtual hardware at step 14. Neither KB showed an update date on 10 October 2026.

Access to patches depends on the support contract, and KB 314603 makes patches for Critical advisories “with a Common Vulnerability Scoring System (CVSS) score greater than or equal to 9.0” available to vSphere 8.x perpetual-licence customers with expired support contracts. The KB covers only that class of patch and only vSphere 8.x, so the end of general support of each release belongs in the vulnerability plan, as our article on vSphere 8 end of general support explains. The settings that reduce exposure between patches are in our guide to ESXi ransomware hardening.

Maintenance windows, rollback and the exceptions register

Point 6.6.1 asks that security patches are “tested before being applied in production systems” and that they “come from trusted sources and are checked for integrity”. Take an estate of 40 hosts in four clusters of ten. Testing there means a test cluster or two pilot hosts that take the patch first and run for an agreed period before the rest. Production clusters are then remediated host by host in maintenance mode, with VMs moved off by vMotion, so each cluster must carry its load on nine hosts. vCenter gets a backup before its patch, and the change record names the previous build to return to.

Some patches cannot go in on time, for example when an appliance vendor has not yet approved the new ESXi build. Point 6.6.2 lets an entity skip a patch only “when the disadvantages of applying the security patches outweigh the cybersecurity benefits”, with the reasons documented. Point 6.6.1(d) then asks for additional measures and accepted residual risks. Under point 6.10.3, a vulnerability gets a mitigation plan where its impact justifies one. Otherwise the entity documents “the reason why the vulnerability does not require remediation”.

One exceptions register covers all three cases. Each entry names the advisory or CVE, the affected assets, the reason, the compensating measure, the risk owner who accepted the residual risk and a review date. ENISA’s tips for requirement 2.1.4 say that risk from vulnerabilities in the highest class, such as “‘critical’ in the common vulnerability scoring system (CVSS)”, is “not accepted, if possible”.

Our engineering partner Vixen.UNO updates vSphere estates in agreed maintenance windows with a rollback plan. Send us your vCenter and ESXi builds through the form below with the advisories still open.

Security testing and NIS2 penetration testing under point 6.5

Point 6.5.1 asks for “a policy and procedures for security testing”. Under point 6.5.2 the entity sets “the need, scope, frequency and type of security tests” from its risk assessment and carries out tests “according to a documented test methodology”. It documents “the type, scope, time and results of the tests” and applies “mitigating actions in case of critical findings”. Point 6.5 names no test type, penetration tests included.

For a company with 10 to 60 hosts, the test plan can include a penetration test of the systems reachable from the internet and of the path from a user network to the management network. Findings enter the same ticket flow and exceptions register as scan results. ENISA’s guidance also says “Include the testing of monitoring and logging procedures in security testing (section 6.5).” A test therefore also shows whether the attempt appeared in the logs. Which events to log is covered in our guide to NIS2 logging and monitoring requirements.

A monthly vulnerability handling cycle

1. Collect the month’s advisories from Broadcom, the other vendors in the inventory and the CSIRT channels the policy names, and open one ticket per relevant advisory.
2. Match each ticket with the inventory and build numbers, and rate it by the vendor’s severity, known exploitation and the exposure of the affected systems.
3. Run the scheduled scans, attach the dated reports to the month’s record and open tickets for new findings.
4. Patch the test cluster or pilot hosts and the test VMs, and record the result in the change.
5. Patch production in agreed maintenance windows, vCenter before the ESXi hosts unless the advisory fixes ESXi alone, with the rollback plan in the change record.
6. Scan again to confirm each fix and close the ticket with that evidence.
7. Review the exceptions register, and report open critical items and fix times to management.

A critical vulnerability exploited between two cycles goes through an emergency change instead of waiting for the next window. For point 7.2, which asks the entity to decide what it measures and who evaluates the results, two metrics fit: the time from advisory to fix per rating and the share of assets covered by the last scan.

General information on EU law as of October 2026, not legal advice for an individual case.

What we do

Under our cyber resilience service, our engineering partner Vixen.UNO audits infrastructure, access, backups and compliance with NIS2 requirements. You receive a risk map, a prioritised action plan and a NIS2 compliance map with the gaps listed and a plan to close them. The compliance map is a technical assessment: the legal opinion on compliance is prepared by your legal department, and we do not issue compliance certificates. Our VMware optimisation service modernises vSphere, vSAN and NSX in agreed maintenance windows, with a rollback plan at every stage. Support continues under an agreed SLA, on one EU contract and invoice.

FAQ