VCF 9.1 Design Topology Field Guide Part 4: Identity, Security, Operations, and Recovery Topology Patterns

This is Part 17 of an architect’s read of VCF 9.1, and the fourth and final Design Topology Field Guide article. Parts 14, 15, and 16 covered foundational, network, and workload topology. This one closes the field guide with the operating-model topology layers identity, security, operations, lifecycle, AI, and cyber recovery.

Six patterns: federated identity via Identity Broker as the new SSO foundation, the Kubernetes-hosted Security Services Platform that runs vDefend, the Build/Manage/Operate/Protect console structure that reorganises Day-2 operations around intent, Fleet Update Service that makes large-fleet upgrades viable, Private AI Foundation as the end-to-end AI architecture, and Advanced Cyber Compliance with the on-prem Isolated Recovery Environment for cyber resilience as a platform service.

These six patterns aren’t bolted onto VCF 9.1 they’re structural. Together with the foundational, network, and workload patterns from Parts 14, 15, and 16, they define what a modern VCF 9.1 design looks like.

Pattern 1: Identity Broker federated SSO as the new foundation

VCF 9.x introduces Identity Broker as the federated identity architecture for the platform. It replaces the per-product LDAP/AD integration pattern that’s been the norm for years each VMware product binding to AD or LDAP independently, with users managing identity in multiple places.

The new model:

• Identity Broker is the single SSO entry point for the VCF Fleet

• External Identity Provider (IDP) integration via OIDC Azure AD / Entra ID, Okta, Ping Identity, ADFS, generic OIDC providers

• All VCF components consume identity from the Broker vCenter, NSX, SDDC Manager, VCF Operations, VCF Automation, VKS, the Management Services Cluster

• Single SSO experience for users across the platform one login, all services

Architectural significance:

• Identity becomes federated, not duplicated one IDP, one identity authority

• MFA enforcement at the IDP layer covers the entire platform automatically

• Joiner/mover/leaver workflows work properly deactivate in the IDP, immediate effect across VCF

• Audit and compliance identity events in one place, not scattered across vCenter, NSX, Aria, etc.

• Conditional access policies at the IDP layer apply to the entire platform

Identity Broker deployment patterns:

Pattern A: Embedded Identity Broker per Instance. Each VCF Instance has its own embedded Identity Broker. Simplest pattern. Aligns to one broker per Instance. Used for single-Instance deployments and multi-Instance designs where instance-level SSO isolation is acceptable.

Pattern B: Centralised Identity Broker shared across the Fleet. One Identity Broker serves the entire Fleet. Used for multi-Instance deployments where unified SSO is required. The Broker becomes a fleet-level service.

Pattern C: Per-Fleet Identity Broker with hard isolation. Multi-Fleet designs where regulatory isolation requires separate SSO boundaries. Each Fleet has its own Identity Broker, federated separately at the IDP layer.

HLD considerations:

• Decide the IDP first: Azure AD / Entra ID for Microsoft-centric shops, Okta or Ping for multi-cloud federation, ADFS for legacy on-prem AD-only environments

• Plan group mapping: VCF roles need to map to IDP groups. Document the mapping in the HLD

• Conditional access policies: define at the IDP layer for MFA, device compliance, location restrictions

• Migration from per-product LDAP/AD: do it during VCF 9.x deployment, not after. Per-product LDAP becomes technical debt that grows harder to remove over time

• Recovery path: document the break-glass procedure for IDP unavailability

Anti-patterns:

• Keeping per-product LDAP “for now” there’s no “later” when this gets done. Migrate during deployment

• Mixing Identity Broker patterns across Instances in the same Fleet keep it consistent

• Forgetting service accounts service-to-service authentication still needs accounts; plan how they’re managed in the new model

• No break-glass procedure for IDP outage every deployment needs one

Diagram to use: the Identity Broker federated SSO architecture diagram. Source:

• William Lam VCF 9.1: Automating VCF Single Sign-On (SSO) with OIDC-based Identity Provider

• Digital Thought Disruption VCF 9.0 Mental Model Part 4: SSO Boundaries

• Broadcom TechDocs Identity Broker Models

Pattern 2: Security Services Platform (SSP) vDefend’s control plane

Security Services Platform (SSP) is the new control plane in VCF 9.x that hosts vDefend’s services. Architecturally, it sits on a Kubernetes runtime alongside the rest of the VCF Management Services.

SSP footprint:

• 92 vCPU / 344 GB vMEM across 3 control plane + 5 worker K8s nodes

• Real infrastructure not a side-deployment. Plan it into the BoM from the design phase

• Hosted on the VCF Management Services Cluster within each Instance

What SSP enables:

IDPS Turbo Mode. 9 Gbps per host, 9 Tbps per domain throughput. Approximately 3x+ improvement over previous IDPS. Stateful inspection at scale.

Distributed Firewall on dVPGs. DFW now works on standard distributed virtual port groups, not just NSX-overlay-backed networks. Wider applicability across hybrid estates that mix NSX overlay and traditional VLAN-based networking.

Self-Service Lateral Security. Application teams can request and apply microsegmentation policies without going through the security team for every rule. Policy-as-code patterns. Faster iteration without compromising governance.

VKS CNI integration. Antrea CNI in VKS clusters consumes the same vDefend policy plane as VM workloads. Unified microsegmentation across containers and VMs. The same rule applies to a Kubernetes pod and the VM next to it.

DFW 1-2-3-4 workflow. The structured way to deploy DFW: 1) visibility and discovery, 2) test rules in monitoring mode, 3) enforce, 4) maintain. Codifies the maturity journey from “we have NSX” to “we have zero-trust microsegmentation.”

HLD considerations:

• SSP is mandatory for vDefend it’s not an optional add-on. Size the Management Services Cluster accordingly

• vDefend licensing is separate confirm the add-on is included in the customer’s VCF subscription

• Microsegmentation strategy: where does the customer want to be in 12 months? DFW 1-2-3-4 framework drives the roadmap

• Self-Service governance: who approves application team-driven security policies? Decide the workflow before enabling self-service

• Application onboarding: design how new applications get their initial microsegmentation policy. Tag-based vs identity-based vs IP-based

Anti-patterns:

• Deploying SSP without sizing the Management Services Cluster for the footprint capacity constraints affect both SSP and other management services

• Enabling Self-Service Lateral Security without governance application teams will create rules that conflict with security policy

• Skipping the DFW 1-2-3-4 workflow and going straight to enforcement application breakage is guaranteed

• Ignoring the VKS CNI integration for Kubernetes workloads VKS workloads need microsegmentation just as much as VMs

Diagram to use: the Security Services Platform architecture diagram. Source:

• Broadcom TechDocs vDefend Design Library

• Broadcom Announcing VCF 9.1 (Security section)

• Broadcom TechDocs Lateral Security with vDefend Models

Pattern 3: The Build / Manage / Operate / Protect operating model

VCF Operations 9.1 reorganises the operating surface into four segmented pillars rather than around platform components. This isn’t a UI redesign it’s a structural shift in how operations teams interact with the platform.

Build pillar. Deployment and lifecycle workflows. Adding VCF Instances, deploying components, extending the fleet, importing existing environments via Brownfield Import, running upgrades via Fleet Update Service. The Developer Center sits here API Explorer for SDDC Manager, NSX, and other APIs, with built-in templates for common automation tasks.

Manage pillar. Fleet Management, Capacity, Cost, Licensing. NVMe Memory Tiering recommendations live here. VKS cost showback per tenant. Programmatic license management VCF 9.1 eliminates the manual 180-day license-usage acknowledgment cycle entirely. Resource Efficiency views. Capacity insights for the fleet.

Operate pillar. Day-to-day operations, troubleshooting, alerting, health, configuration. Real-Time Metrics (new in 9.1, 2-second granularity, deployed as a VCF Service into the Management Services Cluster). Active Findings for signature-based diagnostics across vSAN/NSX/ESX. Integrated logs in the same surface. PromQL queries.

Protect pillar. Security Posture Management (SPM) with VCF security baselines and PCI DSS benchmarks, including one-click remediation (SPM requires the Advanced Cyber Compliance add-on). Security audit logs surfaced here. vSphere Protection and Recovery status. Confidential computing visibility identifying confidential VM-capable hosts and monitoring confidential workloads.

Architectural significance:

• Operations teams stop swivel-chairing between consoles. The eight-console pre-VCF-9 world collapses into a smaller, coherent set

• Mental navigation aligns to intent: “What am I trying to do” not “Which component is this in”

• RBAC can align to pillars: build engineers in Build, capacity planners in Manage, ops in Operate, security/compliance in Protect

• Cross-pillar workflows are unified an incident response touches all four pillars but stays in one console

HLD considerations for operational design:

• Map customer operational team structure to the four pillars. Where ownership crosses pillars, design RBAC and workflows explicitly

• Configuration Drift Management baseline capture during commissioning, not as Day-2 afterthought

• Plan Real-Time Metrics deployment it’s a separate service component that adds Management Services Cluster footprint

• Active Findings as primary alerting model custom alerts still have value but Active Findings is the platform-engineered direction

• Programmatic licensing via the Business Services console and VCF Operations APIs

• Marketplace and Management Pack Builder for third-party integrations inventory what packs are needed before deployment

Diagram to use: the VCF Operations 9.1 four-pillar console screenshot. Source:

• Broadcom VCF 9.1 is Available: Hands-on Labs (console screenshots)

• Gibson Virtualization VCF 9.1 What’s New: VCF Operations (detailed screenshots)

Pattern 4: Fleet Update Service lifecycle topology that scales

Lifecycle was historically the most operationally painful part of running VCF. VCF 9.1’s Fleet Update Service inverts that lifecycle becomes one of the platform’s strengths.

Headline numbers:

• 256 clusters upgraded simultaneously a 4x increase in parallel capacity

• 5,000 ESX hosts per Instance 2x the previous limit

• Sub-1-minute vCenter downtime via Quick Patch

• Approximately 80% of ESX patches applied without reboot via Live Patching (requires TPM-enabled hosts)

The architectural pieces:

vCenter Quick Patch. Sub-1-minute vCenter downtime for patch operations. Up from “wait until the maintenance window” in earlier releases. Changes the calculus of when vCenter patches can land.

ESX Live Patching. Approximately 80% of ESX patches can be applied without reboot, on TPM-enabled hosts. Patches happen during business hours rather than during overnight maintenance windows.

Fleet Update Service parallel orchestration. Up to 256 clusters upgraded simultaneously. Orchestration handled at the fleet level. Maintenance windows that used to take weeks shrink to days.

Zero Touch Provisioning. UEFI + HTTPS-based bare-metal provisioning. No separate imaging infrastructure required. New hosts join the fleet without manual provisioning steps.

HTTP Offline Depot. Air-gapped patch download for sovereign or regulated environments. Patches downloaded once, distributed within the air-gap.

vSphere Lifecycle Manager (vLCM) cluster images. Baselines are dead. Cluster images manage firmware + ESX + components as a unit. Drift detection at the cluster level.

Design topology for fleet-scale lifecycle:

• Standardise cluster image definitions per Workload Domain class prod cluster image, dev cluster image, AI cluster image

• Plan parallel upgrade waves not all 256 clusters simultaneously, but coordinated groups by workload class and risk profile

• TPM enablement on all hosts as a Day-0 requirement unlocks Live Patching

• Maintenance windows: redefine. The old four-hour overnight window is now too long. The new pattern is shorter, more frequent, during business hours

• Air-gap design: HTTP Offline Depot infrastructure on the air-gap side

HLD considerations:

• Cluster image definition governance who owns which image, who approves changes

• Patch testing topology dev/staging clusters first, then prod waves

• Rollback procedures documented per patch class

• Change communication if patches happen during business hours, application teams need predictable notification

Diagram to use: the Fleet Update Service architecture diagram. Source:

• Broadcom Scale, Simplify, and Secure VCF 9.1 (Fleet Update Service section)

• Broadcom Announcing VCF 9.1 (lifecycle improvements)

Pattern 5: Private AI Foundation end-to-end AI topology

Private AI Foundation in VCF 9.1 is the architecture that makes on-prem AI competitive with cloud AI services. It composes the hardware (NVIDIA + AMD GPUs, ConnectX-7/BlueField-3 NICs), the platform (VCF + VKS at 500-cluster scale + Enhanced DirectPath I/O), the frameworks (PyTorch, vLLM, Hugging Face, OPEA), and the observability (Private AI Model and GPU Metrics, AI Metrics Observability Dashboard) into a coherent end-to-end stack.

The layered architecture:

Hardware layer. NVIDIA GPUs (H100, H200, B100 / Blackwell) via NVIDIA AI Enterprise. AMD Instinct MI350 support added in 9.1. NVIDIA ConnectX-7 or BlueField-3 NICs for GPU-to-GPU RDMA. RoCE-capable network fabric.

Platform layer. VCF 9.1 with VKS at 500-cluster scale. GPU-aware scheduling. vGPU support for multi-tenant GPU sharing. NVIDIA Multi-Instance GPU (MIG) partitioning for fine-grain GPU allocation. Enhanced DirectPath I/O for bare-metal-equivalent GPU RDMA performance.

Framework layer. PyTorch, vLLM, Hugging Face integration. OPEA (Open Platform for Enterprise AI) framework support. Live Application Stack Blueprints reusable, version-controlled AI application stacks deployable as units.

Storage layer. 25,000 RWO persistent volumes per Supervisor for production model artifacts, datasets, and inference caches. Typically FlashBlade NFS or NetApp NFS for training data; vSAN ESA for general AI workloads; high-performance NVMe-oF for latency-sensitive inference.

Observability layer. Private AI Model and GPU Metrics in VCF Operations 9.1 time-to-first-token, token throughput, GPU utilisation, model performance metrics. AI Metrics Observability Dashboard (Grafana-based) for deep inspection. AI-ready APIs for RAG and MCP frameworks.

Design topology for Private AI:

• Dedicated Workload Domain for AI different host types, different network fabric, different operational profile from general-purpose VCF

• AI cluster sizing: 4–8 GPUs per host typical, heavy on PCIe lanes, dual ConnectX-7 NICs

• RoCE network fabric dedicated, lossless, PFC/ECN tuned, separate from general data centre traffic

• Storage path: high-bandwidth NFS for training data, persistent volumes for model artifacts, NVMe-oF for inference

• VKS or VM-based AI workloads both supported. VKS for cloud-native MLOps patterns, VMs for traditional model serving

• Observability integration: Grafana dashboards alongside VCF Operations native metrics. Both have a role

Why on-prem AI matters now: data sovereignty, cost predictability, IP control, latency to local data. VCF 9.1 + Private AI Foundation is the architecture that delivers it without bespoke-build overhead.

Diagram to use: the end-to-end Private AI Foundation stack diagram. Source:

• Broadcom Announcing VCF 9.1 (Private AI section)

• Broadcom TechDocs Private AI Foundation Platform Models

• NVIDIA NVIDIA AI Enterprise + VMware reference architecture

Pattern 6: Advanced Cyber Compliance + Isolated Recovery Environment

Advanced Cyber Compliance (ACC) plus the on-prem Isolated Recovery Environment (IRE) make cyber resilience a first-class platform capability in VCF 9.1. As Sanchit Vir Gogia of Greyhound Research observed in Network World, “the security architecture is the quiet centre of the 9.1 story.”

The architectural pieces:

Isolated Recovery Environment (IRE). A logically isolated recovery zone within VCF. Immutable backups. Controlled data ingress and egress. Air-gap capability when configured for it. Designed for ransomware recovery and cyber-incident response.

Cyber Recovery ReadyNodes. Validated hardware with QLC NVMe storage optimised for long-term immutable retention. Capacity-dense, energy-efficient, suited to the recovery use case rather than primary workload performance.

vSAN for Recovery. vSAN ESA tuned for recovery workloads with deduplication, encryption, and immutability. Long-retention storage on familiar VMware infrastructure.

Security Posture Management (SPM). Continuous compliance scoring against VCF security guidelines, PCI DSS benchmarks, and other industry standards. One-click remediation for many findings. Audit-ready reporting. Requires the ACC add-on.

Confidential Computing. Visibility into confidential VM-capable hosts. Workload protection for sensitive data in use. Integrates with platform-native attestation.

vDefend layered on top. Lateral security from the SSP-hosted control plane (Pattern 2 above). Microsegmentation, IDPS Turbo Mode, DFW the active defence layer that prevents ransomware spread.

Design topology for cyber resilience:

• IRE placement: typically a separate Workload Domain or even a separate VCF Instance within the Fleet, with limited network reachability to the primary infrastructure

• Immutability tiers: SnapLock or equivalent on the storage layer, vSAN Protection point-in-time recovery, ACC-managed retention policies

• Network isolation: the IRE should be reachable only through controlled paths for backup ingress and recovery egress

• Recovery testing topology: regular table-top and live recovery exercises against the IRE

• Backup software integration: Veeam, Commvault, Cohesity, Rubrik all can integrate with the IRE pattern. Vendor-specific configurations matter

• SPM enforcement: continuously running from Day 0, not retrofitted

Why this matters for regulated and high-stakes customers:

• Finance: regulatory requirements for cyber-resilient recovery (e.g. DORA in EU, APRA CPS 230 in Australia)

• Government: classified-data sovereignty + ransomware resilience

• Healthcare: HIPAA compliance + critical service availability

• Critical infrastructure: NIS2, NIST CSF, IEC 62443 compliance requirements

HLD considerations:

• ACC licensing separate add-on, confirm scope and tier with the customer

• IRE architecture separate WLD, separate Instance, or separate Fleet? Each option has trade-offs around isolation strength and operational overhead

• Recovery RPO and RTO targets drive the backup frequency, immutability retention, and replication topology

• Compliance benchmark selection PCI DSS, HIPAA, FedRAMP, ISO 27001, CIS, NIST CSF. SPM supports multiple frameworks

• Integration with broader cyber posture SIEM forwarding, SOAR runbooks, threat intelligence feeds

Anti-patterns:

• Treating IRE as “just backup” it’s an isolated recovery posture with specific architectural requirements

• Co-locating IRE with primary infrastructure on shared network the isolation must be enforced

• SPM as a Day-2 add-on deploy it from Day 0 so compliance posture starts compliant rather than catching up

• Skipping recovery testing untested recovery procedures fail when needed

Diagram to use: the Cyber Recovery architecture diagram showing ACC + IRE + vSAN for Recovery + SPM as an integrated platform capability. Source:

• Broadcom Scale, Simplify, and Secure VCF 9.1 (Security Posture Management)

• Broadcom Announcing VCF 9.1 (cyber recovery section)

• Network World Broadcom bets big on VCF 9.1 (Sanchit Vir Gogia analysis)

Decision framework: composing the operating-model topology

A simplified sequence for the operating-model topology decisions in this article:

• Step 1: Identity choose the IDP (Azure AD, Okta, Ping, ADFS, generic OIDC), choose the Identity Broker deployment pattern (per-Instance, centralised, per-Fleet)

• Step 2: Security plan SSP footprint into the Management Services Cluster sizing. Decide DFW 1-2-3-4 maturity target. Plan microsegmentation strategy (tag-based, identity-based, hybrid)

• Step 3: Operations map operational teams to Build/Manage/Operate/Protect pillars. Configure Active Findings as primary alerting. Plan Real-Time Metrics deployment. Adopt programmatic licensing

• Step 4: Lifecycle standardise cluster image definitions per Workload Domain class. Plan parallel upgrade waves. TPM enable hosts for Live Patching. Define maintenance window pattern

• Step 5: AI (if applicable) dedicated AI Workload Domain, RoCE fabric, GPU+NIC topology, VKS Project, observability integration

• Step 6: Cyber resilience IRE topology decision, immutability tiers, network isolation, recovery testing schedule, SPM benchmark selection, ACC licensing

Closing the field guide

This closes Part 17 of the VCF 9.1 series, and with it the Design Topology Field Guide mini-series (Parts 14–17). Together with Parts 1–13, this is the 17-part read of VCF 9.1: platform architecture (Parts 1–7), generic and vendor-specific migration (Parts 8 + 10–13), day-2 operations (Part 9), and now the four-part topology field guide that pairs with the design topology social campaign.

The patterns in this article Identity Broker, Security Services Platform, Build/Manage/Operate/Protect, Fleet Update Service, Private AI Foundation, Advanced Cyber Compliance with IRE are the operating-model layers that turn a VCF 9.1 deployment from “running workloads” into “running a modern private cloud.”

In my design reviews, the operating-model questions I work through every time:

• What’s the IDP? Identity Broker deployment pattern per-Instance, centralised, or per-Fleet?

• Is vDefend in scope? Has SSP footprint been planned into Management Services Cluster sizing?

• DFW maturity target where on the 1-2-3-4 journey is the customer today, and where do they want to be in 12 months?

• How does the operations team map to Build/Manage/Operate/Protect pillars?

• Is Real-Time Metrics deployed? What’s the policy scope?

• Active Findings as primary alerting model or are custom alerts still dominant?

• Cluster image governance who owns which image, who approves changes?

• AI in scope dedicated Workload Domain, dedicated fabric, dedicated cluster strategy?

• IRE architecture separate WLD, Instance, or Fleet? Immutability tiers? Recovery testing schedule?

• SPM benchmarks VCF, PCI, HIPAA, FedRAMP, ISO 27001? ACC licensing confirmed?

Get those answered and the operating-model topology HLD writes itself.

And that closes the field guide. Across Parts 14–17, this Design Topology mini-series covers the architectural patterns architects need to know for VCF 9.1 from the foundational hierarchy through networking, workload topology, and the operating-model layers. Paired with the 20-post social campaign and the broader Parts 1–13 platform deep-dives and migration guides, this is the practical architect’s read of VCF 9.1 in 2026.

Sources

• Broadcom Announcing VCF 9.1

• Broadcom Scale, Simplify, and Secure VCF 9.1

• Broadcom VCF 9.1 is Available: Hands-on Labs

• Broadcom VCF 9.1 Licensing: Programmatic, Centralized, and Built to Scale

• Broadcom TechDocs Architectural Options in VCF (Identity Broker, vDefend, Private AI)

• Broadcom TechDocs vDefend Design Library

• William Lam VCF 9.1: Automating VCF Single Sign-On (SSO) with OIDC

• Digital Thought Disruption VCF 9.0 Mental Model Part 4: SSO Boundaries

• Gibson Virtualization VCF 9.1 What’s New: VCF Operations

• Network World Broadcom bets big on VMware Cloud Foundation 9.1

• NVIDIA NVIDIA AI Enterprise + VMware reference architecture