Security hardening conversations tend to go one of two ways. Either they happen before an audit, which means you’re scrambling to document what you’ve already done (or haven’t), or they happen after an incident, which is the version of the conversation nobody wants. The better approach is to bake hardening into how you operate VCF from day one, so it’s a baseline rather than a project.
This post covers the areas that matter most in a VCF 9.0 environment — ESXi host hardening, vCenter RBAC, encryption at rest, audit logging, and a few NSX-specific items that often get overlooked.
ESXi Host Hardening
Disable SSH after deployment. SSH is enabled during VCF bring-up because Cloud Builder needs it. Once bring-up is complete and you’ve verified your environment, disable SSH on all management domain hosts. In vCenter, select each host, go to Configure > System > Security Profile, and stop the SSH service. Set the startup policy to “Start and stop manually” so it doesn’t restart after a host reboot. If you need SSH access for troubleshooting, enable it temporarily, do your work, and disable it again. Leaving SSH permanently enabled is unnecessary attack surface.
Enable lockdown mode. Lockdown mode prevents direct management of ESXi hosts except through vCenter. There are two levels: normal lockdown (SSH still works but only for users in the DCUI access list) and strict lockdown (DCUI is disabled entirely). For production environments, I recommend normal lockdown with a break-glass local account defined in the Exception Users list. This gives you a recovery path if vCenter is unavailable while still ensuring all normal management goes through vCenter where it’s logged and auditable.
Enable lockdown from vCenter: select the host, Configure > System > Security Profile > Lockdown Mode > Edit. Before enabling, make sure you’ve added your break-glass account to the Exception Users list, otherwise you’ll lock yourself out.
Configure the ESXi firewall. ESXi has a host-level firewall enabled by default, but it’s permissive by default to allow management traffic from any source. Tighten the allowed sources: under Configure > System > Security Profile > Firewall, restrict each allowed service to specific source IPs or CIDR ranges. vSphere Client traffic (TCP 443) should only be allowed from your management jump hosts or management network, not from any IP. Same for the management agent traffic on TCP 902.
Disable unused services. Check which services are running on each host: Configure > System > Security Profile > Services. CIM server, the Direct Console UI, and the ESXi shell are typically not needed in a VCF environment managed entirely through vCenter. Disable them if they’re running.
vCenter RBAC
The default vCenter Administrator role is too broad for day-to-day operations. Most people who need to manage VMs don’t need to configure vCenter networking, change cluster settings, or manage hosts. Giving everyone the Administrator role is convenient and dangerous.
Set up role-based access that matches what people actually need. vCenter ships with several built-in roles — Virtual Machine Administrator, Virtual Machine User, Resource Pool Administrator, Datastore Consumer — that cover most common use cases without granting full control. For operational teams that need more than the built-in roles provide, create custom roles with only the specific privileges required.
Apply permissions at the lowest possible level in the inventory hierarchy. If a team only manages VMs in a specific folder, grant them their role on that folder with propagation enabled, not at the vCenter root. Permissions propagate down the hierarchy — granting at the root means the role applies to everything, which is rarely what you want.
Use Active Directory groups for permission assignments, not individual user accounts. Adding a permission for a group and managing group membership in AD is far more maintainable than managing individual vCenter permission entries as people join and leave teams.
The SSO Administrator (administrator@vsphere.local) should be treated as a break-glass account, not a daily-use account. Create personal named accounts in the vsphere.local domain or integrate with your Active Directory for all normal administrative access. The SSO admin account cannot be easily audited at the AD level because it’s local to vCenter — any action taken with it shows up in vCenter logs as “administrator@vsphere.local” with no person attached to it.
Encryption at Rest
VCF 9.0 with vSAN ESA supports two distinct layers of encryption and it’s worth understanding both.
vSAN Data-at-Rest Encryption encrypts all data stored on vSAN at the datastore level. This is configured at the cluster level in vCenter under the vSAN settings. It requires a Key Management Server (KMS) — vCenter has a built-in KMS (called the vSphere Native Key Provider, or NKP) that works without an external KMS appliance, which makes it easy to enable even in a lab or smaller environment. Enable NKP under vCenter > Configure > Key Providers, back up the NKP key (this is important — if you lose the NKP key and the NKP configuration, you lose access to all encrypted data), then enable vSAN encryption on the cluster.
VM Encryption encrypts individual VMs at the VM level using vSphere VM Encryption policies. This is separate from vSAN encryption and uses the same KMS infrastructure. You can encrypt specific VMs even if the vSAN datastore itself isn’t encrypted. In ESA, this integrates with Storage Policy Data Services so encryption can be defined per-VM in the storage policy rather than as a global cluster setting.
You can run both layers simultaneously — vSAN encryption at the datastore level and VM encryption on top for specific sensitive workloads. There is a performance overhead for encryption, but on NVMe hardware it’s typically low enough to ignore for most workloads. Benchmark your specific environment if you’re running latency-sensitive applications.
Audit Logging
Default logging in vCenter and ESXi is good but not sufficient for a security-conscious environment. The gaps are retention (vCenter logs rotate and logs older than a few weeks may not be available locally) and centralisation (logs sitting on individual appliances aren’t useful when you need to correlate an event across components).
Configure log forwarding to a centralised syslog target for every VCF component. In vCenter, go to Administration > Syslog and add your syslog server. In ESXi, configure syslog under the host’s Advanced Configuration settings (key: Syslog.global.logHost). NSX Manager has syslog configuration under System > Fabric > Nodes. SDDC Manager has its own syslog forwarding under Administration > Syslog.
If you have Aria Operations for Logs deployed (which is part of the VCF stack), forward everything there first and use it as your central collection point. Aria Ops for Logs has vSphere and NSX content packs that parse the log formats automatically and surface the relevant events — login failures, configuration changes, privilege escalations — with minimal configuration on your part.
Set up alerts for high-value events: any use of the administrator@vsphere.local account, any lockdown mode changes, any permission grant at the vCenter root, and any host being removed from lockdown mode. These events should page someone. They’re rare in normal operations, and when they happen unexpectedly they’re usually worth investigating.
NSX Security Hardening
A few NSX-specific items that complement the ESXi and vCenter hardening above.
Restrict NSX Manager access. NSX Manager has its own role-based access system independent of vCenter. Go to System > Users and Roles in NSX Manager and ensure that only the accounts and AD groups that need NSX access have been added. The NSX admin account should be treated like the vCenter SSO admin — break-glass only. Use named accounts for regular operations.
Enable Gateway Firewall on Tier-0 and Tier-1. The NSX Distributed Firewall handles east-west traffic between VMs. The Gateway Firewall adds north-south filtering at the gateway level — traffic entering or leaving the overlay. Enable it on your Tier-0 and Tier-1 gateways and apply a default deny policy for inbound traffic from the physical network, with explicit allow rules for the services you actually need exposed. This creates a layered defence: Gateway Firewall at the perimeter, Distributed Firewall between workloads.
Enable NSX Intelligence or Security Posture Management if it’s part of your licence tier. These tools give you visibility into which NSX security group memberships are effective, which DFW rules are actually being hit, and what traffic flows exist that aren’t yet covered by policy. That visibility is what lets you confidently tighten security policy over time rather than guessing.
The VMware Security Configuration Guide
Broadcom publishes a VMware Security Configuration Guide (SCG) for vSphere that covers every configurable security setting with recommended values and the rationale behind each one. It’s maintained per-version and the VCF 9.0 version covers both ESXi and vCenter. It’s the closest thing to an official hardening benchmark that Broadcom publishes.
If you’re working toward a compliance framework — CIS, DISA STIG, PCI DSS — the SCG is a good starting point for mapping VCF controls to framework requirements. Broadcom also maintains DISA STIG documentation for vSphere separately for organisations that work in US government or DoD contexts.
The SCG is available on the Broadcom Tech Docs site. Pull it for your specific VCF version and work through it methodically. Some settings have real operational trade-offs — the guide flags these — but most of the recommendations are straightforward to implement and most environments should have them enabled.