TL;DR · Key Takeaways
- Zero trust in VCF 9 is an architecture you design, not a checkbox. It rests on four enforcement planes: identity, network microsegmentation, platform integrity, and encryption, all stitched together by continuous verification in VCF Operations.
- Identity is the real perimeter. Stand up the VCF Identity Broker as a three-node cluster wired to your external IdP, and plan around the fact that the SDDC Manager UI still logs in with local accounts.
- FIPS 140-3 and TLS 1.3 are on by default in 9.0+, ULM and File Integrity Monitoring are default in 9.1, and certificate authority config moved to fleet level. Most of the platform-integrity controls are already enabled, your job is to not turn them off.
- The controls that bite teams later are the ones bolted on after deployment: microsegmentation policy, key management with a wrapping key, and break-glass account handling.
Most “zero trust” conversations about VMware Cloud Foundation start in the wrong place: a feature list. Confidential Computing, distributed firewall, FIPS, vTPM. All real, all useful, and none of it adds up to zero trust on its own. Zero trust is an architecture decision about where you place trust boundaries and how you verify across them continuously. The features are just the enforcement points. If you wire them together without a model, you end up with a hardened stack that still trusts the wrong things, usually flat management networks and over-privileged service accounts.
This post lays out a reference architecture for zero trust on VCF 9.0 and 9.1: the four enforcement planes, how they map to real VCF components, what the defaults give you for free, and the design decisions that actually determine whether the result holds up. I will be opinionated about what to enable, what to skip, and what teams consistently get wrong.
What zero trust actually means on VCF (and what it does not)
Broadcom frames VCF security around continuous verification rather than implicit trust, and that framing is correct. The practical translation: every request between components is authenticated and authorised, the platform’s own integrity is measured and attested, and you assume the network is already hostile. The advantage VCF has over a stitched-together stack is visibility. One platform sees from server firmware through the hypervisor into the workloads, so you can verify state instead of trusting it.
Here is the part the marketing skips. Zero trust is not a product you buy and switch on, and VCF does not make your environment zero trust by being installed. The platform gives you strong primitives with sane defaults. The architecture, the trust boundaries, the segmentation policy, the identity model, is yours to design. VCF 9.1 organises its platform security capabilities into five categories (Threat Detection and Prevention, Workload Resilience, Data Encryption, Auditing and Monitoring, Identity and Access). That is a useful catalogue, but it is a catalogue, not a design. The four enforcement planes below are how I actually reason about it on engagements.
The reference architecture: four planes, one control loop
Think of the design as four enforcement planes stacked under a single verification control loop. Identity decides who and what can talk. The network plane decides which flows are allowed once identity is established. The platform-integrity plane proves the hardware and hypervisor underneath are trustworthy. The encryption plane protects data in every state. VCF Operations sits to the side as the control loop: it monitors posture, detects drift, and gives you the audit trail that makes the whole thing verifiable rather than assumed.
Plane 1: Identity is the perimeter now
In a zero trust design, identity is the first and most important boundary, and VCF 9 reorganises this around the VCF Identity Broker (VIDB). The Identity Broker is the intermediary between an externally managed identity provider, Entra ID, Okta, PingFederate, or any SAML or OIDC source, and the VCF components that consume identity: vCenter, NSX, VCF Operations, and VCF Automation. The broker has been built into vCenter since vSphere 8, and in VCF 9 it can run embedded or as a dedicated appliance. From 9.1 it is installed automatically at deploy or upgrade time, so you no longer download it as a separate prerequisite.
Design decision: run the Identity Broker as a three-node cluster for any production fleet. The single-appliance mode is fine for a lab, but identity is now on the critical path for every console and API login across the fleet, so it needs the availability. In 9.1 the broker nodes can also live outside the management cluster, which matters if your security policy isolates identity infrastructure. Push MFA and conditional access to the external IdP where it belongs; do not try to reinvent it inside VCF.
SDDC Manager UI does not participate in VCF SSO for interactive logins. It still uses local domain accounts, even though the SDDC Manager APIs accept VCF SSO tokens. If your zero trust policy says “no local accounts, federated identity only,” you have an exception to document and tightly control on day one. Pair it with the enterprise password vault integration (CyberArk and similar via the 9.1 API plugin) so those local credentials are not sitting in a spreadsheet.VCF 9 also removed several weak authentication paths outright: Smart Card and RSA SecurID support was dropped from ESX, and Integrated Windows Authentication was removed from vCenter. That is a good thing for your attack surface, but if you relied on any of them, federated identity through the broker is the migration target. Role-based access control is now fully exposed through the OpenAPI 3.0 interfaces, so you can codify least-privilege roles as automation rather than clicking through the UI. For the failure modes around identity and certificates specifically, see VCF 9 certificate, identity and backup failures and how to fix them.
Plane 2: Microsegmentation, where the design effort actually goes
Identity establishes who is talking. The network plane decides which flows are permitted, and this is where most of the real architecture work lives. The NSX Distributed Firewall enforces policy at the vNIC of every workload, so east-west traffic is filtered without hairpinning through a perimeter appliance. VMware vDefend layers lateral security on top, extending distributed IDS/IPS inspection, and in VCF 9.1 that inspection reaches Kubernetes and AI workloads with very high aggregate throughput for distributed inference traffic. That last point matters as private AI moves from pilot to production; your GPU workloads should not be a microsegmentation blind spot.
The hard part is not the technology, it is the policy. A real default-deny posture means you have mapped application dependencies and written allow rules per workload group, which is weeks of work on a brownfield estate, not an afternoon. Start in a monitoring or “discover” mode, build rules from observed flows, then flip to default-deny per segment once you trust the rule set. The VPC constructs now integrated into vCenter and ESX help you give application teams self-service network boundaries without handing them the whole DFW. For the NSX building blocks behind this, see NSX in VCF 9 explained: transit gateways, VPCs and the distributed firewall.
Plane 3: Platform integrity, mostly on by default
Zero trust assumes the layer below you might be compromised, so you need to prove the platform is intact rather than assume it. VCF 9 gives you most of this for free if you do not disable it. Install and enable TPM 2.0 in every host; with Secure Boot and host attestation it is the anchor for measured boot and lets vCenter verify a host has not been tampered with. The vTPM is updated to TPM specification revision 1.59, and you can now use custom VM Secure Boot certificates for guest-level integrity.
The bigger architectural change in 9.1 is the User-Level Monitor (ULM), now the default VM monitor. It reimplements the hypervisor’s virtual machine monitor, which had run at the highest privilege level since 1998, and moves it into lower-privilege user mode. The address space excludes host secrets and other VMs’ memory, and the kernel interface treats all inputs as untrusted. In zero trust terms, that shrinks the blast radius of a hypothetical VM-escape exploit. Alongside it, ESX now applies mandatory access control (sandboxing) to its own services, File Integrity Monitoring runs every four hours by default to catch tampering with vCenter binaries (aligned to NIST and PCI DSS), and 9.1 lets you run partner EDR agents in an isolated container directly on the hypervisor.
My take
Do not over-engineer this plane. The defaults are strong. The two decisions that actually need a workshop are whether to run Confidential Computing (Intel TDX or AMD SEV-SNP, now generally available in 9.1, delivered through the VMware Advanced Cyber Compliance solution) for genuinely sensitive data-in-use, and whether the operational cost of execInstalledOnly and EDR fits your team. Confidential Computing has real overhead and hardware dependencies, so reserve it for workloads with a regulatory or multi-tenant isolation requirement, not as a blanket setting.
Plane 4: Encryption everywhere, with one design trap
VCF 9 uses TLS 1.3 by default across the whole product, internally and for client connections, with TLS 1.2 available as a fallback you can disable through the NIST_2024_TLS_13_ONLY profile. FIPS 140-3 is enabled by default for new SDDC Manager deployments starting in 9.0. Data-in-motion for vMotion can be hardware-accelerated with Intel QAT, which is enabled by default on supported hardware so encrypted migrations stop being a resource tax.
Data-at-rest is where the design trap lives. Traditional vSAN encryption uses a data encryption key wrapped by a key encryption key stored in your KMS. The problem is operational: VCF never deletes keys from the KMS, so they accumulate, they are hard to identify, and auditing rotation is painful. VCF 9 adds a standard key provider option with a wrapping key, a third key that protects the KEK. Only the wrapping key lives in the KMS, it can be given a readable identifier, and it auto-rotates on an interval you set. If you are designing key management for a new fleet, use the wrapping-key model from the start; retrofitting it onto an estate that has already sprayed thousands of keys into a KMS is exactly the kind of cleanup nobody budgets for.
Control plane: continuous verification in VCF Operations
None of the four planes is zero trust without the loop that verifies them. VCF Operations is that loop. Its security operations dashboard gives continuous monitoring of security controls and compliance posture, and crucially it lets you drill into an alert to see exactly what changed and who changed it, so you can tell a careless change apart from a real breach. The 9.1 Audit Trail gives a centralized, time-sliced view of user activity across every component, including VKS, so when a firewall rule changes or a login fails you can trace the whole event chain across the stack instead of grepping seven log sources.
Operations is also where certificate and password governance now live at fleet scale, which directly serves zero trust. Certificate authority configuration moved to the fleet level in 9.1, with bulk signing, renewal and import operations, and expanded Microsoft CA and OpenSSL support. That is no longer optional housekeeping: the CA/Browser Forum is driving public certificate lifespans down toward 47 days, and you cannot hand-rotate certificates across a fleet at that cadence. Password policy is likewise fleet-level now, with vault integration and break-glass account passwords no longer stored at all, which removes a recurring remediation headache.
| Enforcement plane | Primary VCF mechanism | Default state | Design decision you still own |
|---|---|---|---|
| Identity & access | VCF Identity Broker, fleet SSO, OpenAPI RBAC | Broker installed at deploy; embedded mode | 3-node cluster, IdP choice, MFA, SDDC Manager local-account exception |
| Network segmentation | NSX DFW, vDefend, distributed IDS/IPS | Available, not pre-segmented | Default-deny policy per workload group, VPC boundaries |
| Platform integrity | TPM 2.0, Secure Boot, ULM, FIM, sandboxing | ULM and FIM default in 9.1; TPM if installed | Confidential Computing scope, EDR, execInstalledOnly |
| Encryption | TLS 1.3, FIPS 140-3, vSAN DARE, wrapping key | TLS 1.3 and FIPS on by default | Wrapping-key KMS model, TLS-1.3-only profile, QAT |
| Verification loop | VCF Operations dashboard, Audit Trail, fleet CA | Monitoring on; policies unconfigured | Compliance baseline, alert tuning, cert/password policy |
execInstalledOnly can break legacy integrations and older clients. Validate against your interoperability matrix, stage changes in a non-production fleet, snapshot or back up management components, and run VCF Operations prechecks before flipping any of these in production.What I would do
If I were standing up zero trust on a new VCF 9 fleet, I would treat the four planes as a sequence, not a simultaneous big-bang. Get identity right first: three-node Identity Broker, federated to your IdP, MFA enforced at the IdP, and the SDDC Manager local-account exception documented and vaulted. Then design the data-at-rest key model with the wrapping key before any production data lands, because that one is genuinely painful to retrofit. Platform integrity and transport encryption are mostly default, so verify they are still on and resist the urge to fiddle. Save the largest block of time for microsegmentation policy, because that is the plane that determines whether “zero trust” is real or just a slide. And wire VCF Operations in from day one so you are verifying continuously, not auditing after the fact.
The verdict: VCF 9 gives you a genuinely strong zero trust foundation with unusually sane defaults, but the platform does the easy 70 percent and leaves you the hard 30 that actually matters, identity model and segmentation policy. Budget your design effort accordingly. What is the first plane you are hardening on your VCF 9 estate, and where is the policy work biting hardest?
For the broader design context this security architecture plugs into, start with the VCF 9 reference architecture: sizing, topology and design trade-offs.
References
- Security in VMware Cloud Foundation 9.0 (VMware Cloud Foundation Blog)
- Strengthen Zero Trust Security and Resilience with VCF 9.1 (VMware Cloud Foundation Blog)
- Identity Security for VMware Cloud Foundation: IAM, PAM and Zero Trust Access (VMware Cloud Foundation Blog)
About The Author
