Your vCenter Server system and associated services are protected by authentication through vCenter Single Sign-On and by authorization through the vCenter Server permissions model. You can modify the default behavior, and you can take additional steps to limit access to your environment.

As you protect your vSphere environment, consider that all services that are associated with the vCenter Server instances must be protected. In some environments, you might protect several vCenter Server instances.

Harden all vCenter host machines
The first step in protecting your vCenter environment is hardening each machine on which vCenter Server or an associated service runs. Similar considerations apply to a physical machine or a virtual machine. Always install the latest security patches for your operating system and follow industry standard best practices to protect the host machine.
Learn about the vCenter certificate model
By default, the VMware Certificate Authority provisions each ESXi host and each machine in the environment with a certificate signed by VMCA. If your company policy requires it, you can change the default behavior. See the vSphere Authentication documentation for details.
For additional protection, explicitly remove expired or revoked certificates and failed installations.
Configure vCenter Single Sign-On
vCenter Server and associated services are protected by the vCenter Single Sign-On authentication framework. When you first install the software, you specify a password for the administrator of the vCenter Single Sign-On domain, administrator@vsphere.local by default. Only that domain is initially available as an identity source. You can add an identity provider such as Microsoft Active Directory Federation Services (AD FS). You can add other identity sources, either Active Directory or LDAP, and set a default identity source. Users who can authenticate to one of those identity sources can view objects and perform tasks if they are authorized to do so. See the vSphere Authentication documentation for details.
Assign roles to named users or groups
For better logging, associate each permission that you give on an object with a named user or group and a predefined role or custom role. The vSphere permissions model allows great flexibility through multiple ways of authorizing users or groups. See Understanding Authorization in vSphere and Required Privileges for Common Tasks.
Restrict administrator privileges and the use of the administrator role. If possible, do not use the anonymous Administrator user.
Set up PTP or NTP
Set up PTP or NTP for each node in your environment. The certificate infrastructure requires an accurate time stamp and does not work correctly if the nodes are out of sync.
See Synchronizing Clocks on the vSphere Network.