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 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.

vCenter and encrypted communication
By default ("out of the box"), all data communication between vCenter Server and other vSphere components is encrypted. In some cases, depending on how you configure your environment, some traffic might be unencrypted. For example, you can configure unencrypted SMTP for email alerts and unencrypted SNMP for monitoring. DNS traffic is also unencrypted. vCenter Server listens on port 80 (TCP) and port 443 (TCP). Port 443 (TCP) is the industry-standard HTTPS (secure HTTP) port and uses TLS 1.2 encryption for protection. Port 80 (TCP) is the industry-standard HTTP port and does not use encryption. The purpose of port 80 is to redirect requests from port 80 to port 443, where they are secure.
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, [email protected] by default. Only that domain is initially available as an identity source. You can add an external identity provider, such as Microsoft Active Directory Federation Services (AD FS), for federated authentication. 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.