VMware NIS2 Compliance: Mapping NSX-T, vSphere, and Aria Operations to Article 21(2)(e) and the CIR Technical Annex

Three of the VMware-to-NIS2 mappings now circulating in vendor briefs and consultant slide decks are wrong. “CIR Annex 6.11” for logging doesn’t exist — Section 6 of the Commission Implementing Regulation’s Annex stops at 6.10. Microsegmentation gets filed under 6.7 when the actual network-segmentation point is 6.8. Hardening baselines get pointed at 6.8 when they belong under 6.3, configuration management. None of this makes the underlying idea wrong — VMware’s stack genuinely does the work — but a wrong citation number on an audit-evidence table is exactly the kind of detail an auditor or a regulator’s technical assessor checks first.

This guide maps four VMware by Broadcom controls — NSX-T microsegmentation, the vSphere Security Configuration Guide, Aria Operations for Logs, and vCenter’s identity stack — to the specific NIS2 Directive measure and CIR Annex sub-point each one actually supports, corrects the citation errors above against primary text, and walks through what closing each gap costs under Broadcom’s post-2023 subscription licensing model.

Does This Actually Apply to Your VMware Environment?

NIS2 doesn’t regulate VMware, or virtualisation, as a category. It regulates the essential and important entities listed in Annex I and Annex II of Directive (EU) 2022/2555 — energy, transport, banking, health, digital infrastructure, manufacturing, and more — and Article 21 requires those entities to secure the network and information systems they depend on, whatever runs on them. If your organisation is in scope and any part of your production estate runs on ESXi, vCenter, NSX, or the Aria/vRealize operations suite, Article 21(2)(e)’s acquisition, development, and maintenance obligations apply to that estate directly. NIS2’s proportionality principle means the expected depth of those controls scales with size and risk exposure — a five-person managed service provider running one vCenter cluster isn’t held to the same segmentation granularity as a national grid operator’s data centre, even though the same Article 21(2)(e) text covers both.

Article 21(2)(e) of the NIS2 Directive requires “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure” [1]. For most mid-size and large organisations, the virtualisation layer is the network and information system — it’s where segmentation, patching, and access control decisions actually get enforced, not just documented.

The VMware-to-NIS2 Citation Table — And Where Most Briefs Get It Wrong

The Commission Implementing Regulation (EU) 2024/2690 — which sets the detailed technical requirements behind Article 21(2) for digital infrastructure and certain digital-service entities, and is widely used sitewide as best-practice reference even outside that binding scope — organises its Annex into 13 numbered sections. Section 6, “security in acquisition and development,” runs from 6.1 through 6.10; there is no 6.11. Section 3.2 covers monitoring and logging as part of incident management, not acquisition and development.

VMware control	What it does	Correct CIR 2024/2690 citation	NIS2 Directive measure
NSX-T Data Center microsegmentation (distributed firewall)	East-west traffic inspection between workloads; confines lateral movement to a single segment	Section 6.8 — network segmentation	Art. 21(2)(e)
vSphere Security Configuration Guide baselines	Documented hardening standard for ESXi, vCenter, and VM settings, refreshed each vSphere release	Section 6.3 — configuration management	Art. 21(2)(e)
Aria Operations for Logs (formerly vRealize Log Insight)	Centralised log collection across the vSphere/NSX estate with retention and correlation	Section 3.2 — monitoring and logging	Art. 21(2)(b) / Art. 23
vCenter SSO + NSX identity firewall (MFA, RBAC)	Authentication strength and role-scoped administrative access to the management plane	Section 11 — access control (11.6 authentication, 11.7 MFA)	Art. 21(2)(i)/(j)

The pattern behind the errors is consistent: whoever wrote the wrong version pattern-matched a plausible-sounding number to a topic instead of checking the Annex text. Network security (6.7, which covers secure network architecture, DNS, routing, and remote access) and network segmentation (6.8, which covers zoning systems by risk and separating them from third-party systems) are adjacent but distinct points — microsegmentation is squarely the second one. Our own Article 21 to CIR mapping reference and CIR overview are worth cross-checking against any brief that cites a specific sub-point before you build an audit-evidence table around it.

Why the Citation Matters: The ESXiArgs Lesson

In February 2023, CISA and the FBI issued a joint advisory after ransomware operators compromised more than 3,800 ESXi servers worldwide, concentrated in France, Germany, the United States, Canada, and the Netherlands, by exploiting a known, unpatched heap-overflow vulnerability (CVE-2021-21974) in ESXi’s OpenSLP service [4]. The advisory’s core recommendations were unglamorous: patch to a current ESXi build, disable the OpenSLP service if it isn’t in use, and don’t expose the hypervisor management interface to the public internet.

Every one of those three recommendations lands on a different Annex point covered above. Patching is Section 6.6, one step removed from the hardening baseline in 6.3. Disabling an unused service is a configuration-management control (6.3) in its own right. Keeping the management interface off the public internet is what network segmentation (6.8) is for. None of those controls existed in isolation on the servers that got hit — the incident is a case study in why the CIR treats acquisition-and-development security as one connected set of ten sub-points rather than a single checkbox. It’s also a reminder of why logging isn’t just a Section 3.2 filing exercise: Article 23’s incident-notification clock only starts once an event is detected, and detection depends on the monitoring this whole guide keeps circling back to.

Gap Analysis: Closing Each Requirement, by Effort Level

The honest starting point for most infrastructure teams isn’t zero — vSphere and NSX ship with the relevant capability already licensed in most current editions. The gap is almost always documentation and enforcement, not missing technology.

Requirement	Typical current state	Required state	Effort to close
Network segmentation (6.8)	NSX deployed for performance/mobility, distributed firewall rules ad hoc or default-allow	Documented zone model with rule justification per segment, reviewed on a set cycle	Medium — mostly policy authoring and a rule audit, not new infrastructure
Configuration management (6.3)	Hardening applied at initial build, guide not re-checked against newer releases	Baseline re-validated against the current vSphere Security Configuration Guide with a documented exception process	Low — the guide and its companion audit spreadsheet are free from Broadcom [6]
Monitoring and logging (3.2)	Aria Operations for Logs collecting vSphere/NSX logs, retention and time-sync not formally documented	Documented log-source list, retention period, and synchronised time source across systems, matching CIR 3.2’s specific content requirements [2]	Medium — configuration exists; the gap is usually the written procedure
Access control / MFA (Section 11)	vCenter SSO configured, MFA enforced inconsistently across admin accounts	MFA mandatory for all privileged accounts, access reviewed on a defined schedule	Low to Medium — depends on identity-provider integration already in place

The Broadcom Licensing Shift and Your Compliance Budget

Since completing its 2023 acquisition of VMware, Broadcom has moved the entire portfolio to subscription-only licensing — new perpetual licenses and support renewals ended across thirteen product lines, including vSphere, NSX, and the Aria suite [5]. NSX is no longer sold as a standalone product; it ships as the networking layer inside VMware Cloud Foundation. Per current third-party licensing-model analyses (Broadcom does not publish this breakdown as a public price list), the distributed-firewall capability that does your microsegmentation now sits behind a separate, per-core “vDefend” attach SKU, billed against a minimum of 16 cores per CPU regardless of how many cores the processor actually has [8].

The compliance implication is direct: a segmentation control you already rely on for Section 6.8 evidence may now carry a recurring licence cost your original budget didn’t plan for, and that cost is set at the cluster level, not the workload level — which is why scoping which clusters actually need the attach SKU is worth doing before renewal, not after. Organisations that moved to VMware Cloud Foundation before the 2024 repricing may already have the attach SKU folded into their existing bundle — check the actual entitlement list rather than assuming a gap exists from the marketing tier name alone.

Who Owns This: A Role-Responsibility Split

NIS2 audits fail as often on ownership gaps as on missing controls — a policy nobody’s job description covers doesn’t get maintained.

Role	Owns
Virtualisation / infrastructure lead	NSX segmentation rules, ESXi/vCenter hardening baseline, patch cadence
CISO / IT security manager	Log retention policy, MFA enforcement standard, exception approvals
Compliance officer	Citation accuracy in audit evidence, mapping controls to the correct Article 21(2) measure, licence-cost documentation for the board

Documentation Checklist for Your Next Audit

• Current vSphere Security Configuration Guide version used, with a dated diff against the previous baseline [6]
• NSX segmentation/zone diagram with a rule-justification note per segment
• Aria Operations for Logs retention setting and a list of monitored log sources, matching CIR 3.2’s named categories [2]
• MFA enforcement report for privileged vCenter and NSX accounts
• Current VMware/Broadcom subscription and entitlement records, current to the licence term

Frequently Asked Questions

Does CIR 2024/2690 legally apply if my organisation isn’t a digital-infrastructure provider?

Only entities in the CIR’s specific scope — DNS and TLD registries, cloud/data-centre/CDN providers, managed service and security providers, and a handful of digital-service categories — are legally bound by it. Everyone else answers to Article 21(2) directly, without the CIR’s sub-point detail. Many organisations outside that scope still use the CIR’s structure as a practical checklist, which is why it appears so often in vendor-mapping content — just don’t present it as a binding citation if your entity type isn’t covered.

Does using vSphere or NSX by itself satisfy Article 21(2)(e)?

No single product satisfies a legal measure on its own. The technology can support the segmentation, hardening, and logging outcomes the measure requires — whether it does depends on how it’s configured, documented, and reviewed.

What changed for VMware customers with the Broadcom acquisition that affects compliance planning specifically?

The move to subscription-only licensing and the unbundling of NSX’s advanced security features into a separate per-core SKU [5][8] mean a control you may have treated as a sunk cost now needs to be re-budgeted at renewal — worth flagging to whoever owns the compliance budget line before the next renewal cycle, not during it.

Is Aria Operations for Logs the only supported logging option for CIR Section 3.2?

No — VMware’s own documentation notes NSX environments can be monitored through Aria Operations for Logs or a third-party SIEM such as Splunk. The CIR’s requirement is about what the logs capture and how they’re retained, not which specific tool is used.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Article 21, NIS2 Directive (EU) 2022/2555 — nis2resources.eu
2. Commission Implementing Regulation (EU) 2024/2690, Annex point 3.2 — EUR-Lex
3. CIR 2024/2690 Annex structure (13 sections) — OpenKRITIS implementing-acts mapping
4. ESXiArgs Ransomware Virtual Machine Recovery Guidance, AA23-039A — CISA/FBI joint advisory (cisa.gov)
5. VMware by Broadcom: Business Transformation — Broadcom News
6. vcf-security-and-compliance-guidelines repository — VMware/Broadcom official GitHub
7. VMware Aria Operations for Logs documentation — Broadcom TechDocs
8. VMware NSX Licensing 2026: Editions and Cost — Redress Compliance