Harden one access boundary at a time and test both the permitted task and the prohibited task. A control is incomplete if it blocks an attacker but also removes the only working recovery path. This guide builds a staged lab procedure with explicit evidence for identity, access and recovery.
It is not a complete compliance benchmark or an automatic hardening script. No VMware configuration, identity provider or firewall was changed for this article. Production rollout needs the organisation's change review and a successful isolated rehearsal.
1. Capture the operational contract
Inventory the exact vCenter and ESXi builds, administrators, service accounts, backup/provisioning integrations, management networks, remote logging and key providers. Record ownership and a working recovery route independent of the normal administrator workstation.
For each proposed control, write four things: the threat being reduced, the required operational task, the expected rejection and the tested reversal. For example, a VM operator must be able to start a disposable VM in an assigned folder but must not be able to change host networking or administer another team's VM.
Capture the initial permissions using an approved PowerCLI release and a scoped connection:
Get-Help Connect-VIServer -Full
Get-Help Get-VIPermission -Full
Get-Help Get-VMHostService -Full
$vc = Connect-VIServer -Server 'vc01.example.invalid'
Get-VIPermission -Server $vc |
Select-Object Entity, Principal, Role, Propagate
$labHosts = @(Get-VMHost -Name 'esx-lab-01.example.invalid' -Server $vc)
if ($labHosts.Count -ne 1) { throw 'Expected exactly one lab host' }
Get-VMHostService -VMHost $labHosts[0] -Server $vc |
Select-Object Key, Label, Running, Policy
These are read-only inventory calls. The permissions cmdlet: https://developer.broadcom.com/powercli/latest/vmware.vimautomation.core/commands/get-vipermission returns assigned permissions; it is not a complete effective-access calculation including every group, inheritance relationship and external identity rule. The host-service cmdlet: https://developer.broadcom.com/powercli/latest/vmware.vimautomation.core/commands/get-vmhostservice reports service configuration and state. Protect the results because they reveal security structure.
2. Prove a scoped operator role
In a lab vCenter, create a role for a specific operational task under Administration > Roles. For the example, select the required VM power-on privilege and no host configuration privileges. Assign the role to a dedicated test group on a dedicated folder containing disposable VMs; inspect whether propagation is intended.
The role-creation workflow: https://knowledge.broadcom.com/external/article/316586/creating-and-assigning-a-role-with-privi.html describes where privileges and object assignments are configured; its broader VM-management example is not the minimal role proposed here. Confirm the operator also has the required read access on ancestor inventory objects. Missing datacentre System.Read can break the power-on workflow or its result reporting, as shown in Broadcom's permissions investigation: https://knowledge.broadcom.com/external/article/415005/users-cannot-power-on-vms-via-the-vspher.html. Add only the required visibility at the correct scope and repeat the negative tests.
Use separate test identities for role validation and administration. Start a fresh operator session after membership/permission changes. Confirm that the operator can discover the intended lab object and perform the permitted power-on task. Verify the resulting task's recorded principal and outcome.
For a negative test, use another disposable VM outside the permitted folder. Confirm that the operator cannot perform the same task there. Check that host networking changes are unavailable. If the operator can do more than expected, inspect inherited permissions, additional group membership, global permissions and the object where each role is assigned.
Keep this as a task-based authorisation test. Do not broaden the role to Administrator because a workflow needs one additional privilege. Backup, recovery and automation products have their own documented privilege requirements and need separate acceptance tests.
3. Introduce federated identity without losing recovery access
For an Entra-based design, the cited VMware procedure applies to vCenter 8.0 Update 2 and later. It combines OpenID Connect sign-in with SCIM provisioning of users and groups. Match the exact vCenter build and identity-provider configuration before attempting integration. VCF 9 has separate guidance. Entra federation reference: https://knowledge.broadcom.com/external/article/322179/configuring-microsoft-entra-id-for-vcent.html
Pilot with a small group and a limited role. Verify user provisioning, group mapping, sign-in, intended MFA/conditional-access behaviour and denied access for an unassigned user. Also test the approved recovery identity when the external provider is unavailable in the lab. Preserve auditable custody of that identity.
Federating browser login does not prove that every API client or service account receives the same authentication controls. Test each integration explicitly. Do not enable optional legacy password grant flows merely because they appear in a setup example; the authentication architecture must be reviewed for the clients actually used.
4. Restrict management traffic in stages
Create a connection matrix covering administrator jump hosts, vCenter-to-ESXi traffic, monitoring, backup, time/DNS, storage management and recovery access. Obtain required ports from the exact product/build documentation. This article intentionally does not present a universal firewall-port list.
In the lab, apply one narrow network restriction at a time. Confirm that approved administration works and an unapproved client cannot reach management interfaces. Then exercise normal integration jobs against disposable workloads. Check both allowed and denied traffic in the firewall evidence.
Keep an independently verified reversal path available during the test. A rule that breaks the active management session is not safely reversible merely because its old value was written down. Out-of-band hardware access and the authority to change the upstream firewall are separate prerequisites.
5. Evaluate host lockdown with its recovery consequences
Normal lockdown leaves the Direct Console User Interface service available to eligible recovery users. Strict lockdown stops that service and can leave a disconnected host without a practical administration path. Exception users are intended for narrowly defined service needs; adding every administrator defeats the control. Lockdown-mode behaviour: https://knowledge.broadcom.com/external/article?legacyId=1008077
Before any lab change, record current mode, DCUI access, exception users, SSH/shell state and service dependencies. Design a normal-lockdown rehearsal first: prove vCenter administration, required integrations and the documented recovery path using a disposable host.
Strict lockdown requires a separate expert-reviewed recovery design and isolated validation. This draft does not provide a one-click strict-lockdown rollout or an instruction to disable all recovery accounts. Disabling SSH alone also does not prove that all direct access is blocked.
6. Verify certificates and remote evidence
In vCenter, inspect Administration > Certificate Management and the relevant alarms. Record certificate identity, issuer, validity, owners and integration trust dependencies. Plan renewal early enough to test backup clients and automation before the old trust path expires.
Do not dismiss an absent generic certificate alarm without checking the build. Broadcom documents changed certificate alarms in vCenter 8.0 U3g and later. A dashboard copied from an older release can therefore miss the intended signals. Certificate-alarm changes: https://knowledge.broadcom.com/external/article/412316/certificate-status-alarm-is-missing-in-v.html
On an authorised lab host, inspect existing syslog configuration:
esxcli system syslog config get
For a planned logging change, use the host's advanced settings to configure the approved collector, transport and port, including certificate trust where TLS is used. Verify host firewall requirements for the exact build. Broadcom documents Syslog.global.logHost and distinguishes host log rotation from retention on the remote collector. ESXi logging reference: https://knowledge.broadcom.com/external/article/318939/configuring-syslog-on-vmware-vsphere-esx.html
Generate a controlled lab sign-in and correlate its timestamp and identity at the appropriate collector. Test vCenter audit collection separately from ESXi logging. Confirm alert routing, time synchronisation, retention and restricted collector access. A configured destination without received events is not acceptance.
7. Protect encryption recovery material
If using a Native Key Provider, record which workloads depend on it and where recovery material is kept. In vCenter's Configure > Security > Key Providers view, inspect the provider and backup status. For a newly created lab provider, perform the supported backup process before using it for encryption.
The Native Key Provider backup is a PKCS#12 file and can be password-protected. Store the protected file and its recovery password under approved, separately controlled custody. Do not embed either in the infrastructure repository or rely solely on the encrypted environment to hold its own recovery material. Native Key Provider setup and backup: https://knowledge.broadcom.com/external/article/396471
An exported file is not proof of recovery. Have the platform specialist validate provider recovery and access to a disposable encrypted workload in an isolated environment. External KMS designs have different availability and backup responsibilities. Do not remove or rotate production keys as a test of this article.
Acceptance and rollback
Maintain a result table with control, previous state, new state, permitted-task result, denied-task result, recovery result and evidence location. Reject a control whose normal task works but whose recovery path remains unknown.
Reverse only the tested change using the recorded supported method. Network isolation, federation, certificates and key-provider changes have different reversal constraints; a generic VM snapshot is not an adequate rollback plan for all of them. Retest integrations after reversal and keep temporary exceptions time-bounded with an owner.
Related topics: isolated backup verification, cloud recovery and automation credentials.
Learning notes
- Effective access needs real allowed and denied tests, not only a role export.
- Strong authentication and a recoverable management plane must work together.
- Encryption protects data only while the required keys remain recoverable.
Sources and review status
See the source ledger for dates, version scope and limits, the author self-check, and the series index. Independent review and lab validation remain pending.