VIDM vs. VIDB: Understanding the VCF Identity Shift
The identity component that confuses everyone
If you've been working with VMware Cloud Foundation for a few years, you know VMware Identity Manager (VIDM). It was the SSO backbone for the Aria Suite: required for Aria Automation, wired into Aria Operations and a familiar fixture in every VCF deployment. Then VCF 9.0 arrived and introduced something new: VCF Identity Broker (VIDB). Now customers upgrading to VCF 9.1 are asking: what happened to VIDM, what exactly is VIDB and what do I actually need to do?
This post gives you a straight comparison based on official Broadcom documentation: no guesswork, no community speculation.
1. The component lineage: where VIDB came from
Broadcom's official VCF 9.1 documentation describes the identity component evolution as a direct lineage:
| Official lineage: Workspace ONE Access (VCF 5.2) → VCF Identity Broker (VCF 9.0) → Identity Broker in VCF Management Services (VCF 9.1) |
VIDM, which most people knew as "VMware Identity Manager," was built on Workspace ONE Access, a Broadcom product separate from VCF itself. In the VCF 4.x and 5.x era, if you wanted SSO across the Aria Suite (Aria Automation, Aria Operations, Aria Log Insight), you needed VIDM deployed and integrated. It was an optional but practically required component for any customer running the full Aria stack.
VCF 9.0 replaced that with VCF Identity Broker (VIDB), a purpose-built identity broker native to the VCF platform. VCF 9.1 then went further by consolidating Identity Broker into VCF Management Services, eliminating the need for it to run as a separate standalone appliance in most deployments.
2. What VIDM actually was
VMware Identity Manager (VIDM), marketed as Workspace ONE Access in later versions, was a separate enterprise product that provided:
- SAML 2.0-based SSO federation across Aria Suite products
- Active Directory and LDAP integration for user directory services
- OAuth 2.0 authorization for Aria Automation API consumers
- Multi-tenancy support for Aria Suite in large enterprise deployments
In terms of deployment, VIDM ran as a separate appliance cluster: you deployed Workspace ONE Access VMs, configured them, then wired each Aria product into VIDM for authentication. It was its own lifecycle: patches, certificates and backups managed independently of the VCF SDDC Manager lifecycle.
In VCF 5.x, VIDM was listed in the Aria Suite Lifecycle Manager and Broadcom's IAM validated solutions documentation as the identity source for NSX (as of Jan 2024, NSX moved to direct LDAP/AD rather than VIDM), and for Aria Automation. The validated solution for Identity and Access Management for VCF 5.x (last updated Oct 2024) specifically covered VIDM-based authentication.
| Key point: VIDM was a Workspace ONE product deployed alongside VCF, not a native VCF component. It had its own release cadence and was managed separately from SDDC Manager. |
3. What VCF Identity Broker (VIDB) is
VCF Identity Broker is VCF's native identity brokering service introduced in VCF 9.0. Unlike VIDM, it is not a separate product; it is a service built into the VCF platform itself. Its job is to act as the central SSO and identity federation point for the entire VCF platform, replacing the role that Workspace ONE Access played in the 5.x era.
VIDB connects to your corporate identity provider (Active Directory, LDAP or an external IdP) and brokers authentication for all VCF components: vCenter, SDDC Manager, VCF Automation and VCF Operations. It introduces native OIDC and OAuth 2.0 support, enabling API token-based authentication in addition to traditional SSO.
Broadcom's official documentation notes that VIDB supports centralized VCF-level role assignments, meaning that instead of managing roles inside each individual component, you can assign platform-level roles through the Identity Broker.
VIDB in VCF 9.1: consolidated into VCF Management Services
VCF 9.1 consolidates Identity Broker into VCF Management Services. Rather than deploying it as a separate set of appliance VMs, it is now one of the services running within the VCF Management Services runtime. This means:
- Identity Broker is VCF-only: it is not available for VMware vSphere Foundation (VVF) deployments
- It is deployed automatically on the first VCF instance
- On additional VCF instances, it is an optional Day-N deployment
| VCF 9.1 note: If you have critical uptime requirements or a multi-site environment, the Appliance VIDB model (standalone 3-node cluster) is still supported in 9.0/9.1 as an alternative to the embedded model within VCF Management Services. |
For a deeper look at how VCF 9.1 consolidates the entire management plane, not just Identity Broker, see my earlier post: How VCF 9.1 Consolidates the Management Plane into a Single Unified Platform
4. Side-by-side comparison
Here is the full comparison based on official Broadcom documentation:
| Attribute | VIDM | VIDB |
|---|---|---|
| Full Name | VMware Identity Manager (Workspace ONE Access) | VCF Identity Broker (VIDB) |
| VCF Versions | VCF 4.x – 5.2 | VCF 9.0 onwards |
| Product Type | Separate Broadcom product (Workspace ONE Access) | Native VCF platform service |
| Deployment (9.0) | N/A (legacy) | Embedded (in vCenter) or Appliance (3-node cluster) |
| Deployment (9.1) | N/A (deprecated) | Part of VCF Management Services (no standalone VMs) |
| VCF vs VVF | Both VCF and VVF scenarios | VCF only (not VVF) |
| HA Model | Separate WS1 Access cluster | vSphere HA (embedded) or 3-node cluster (appliance) |
| Protocols | SAML, LDAP/AD, OAuth | OIDC, OAuth 2.0, SAML, LDAP/AD |
| Role Management | Per-product role assignment | Centralized VCF-level role assignments |
| SSO Scope | Aria Suite components | Entire VCF platform (SSO + API tokens) |
| Backup/Restore | Standalone WS1 Access backup | vCenter backup (embedded) or independent (appliance) |
| Migration | Continues post-upgrade (Day-2 migration) | Strategic direction for VCF 9.x |
| Status | Deprecated – End of life in VCF 9.x | Current – actively developed |
5. What happens when you upgrade from 5.2 (with VIDM) to 9.1
This is where most of the real-world confusion happens. If you are running VCF 5.2 with Workspace ONE Access (VIDM) configured for Aria Automation, and you upgrade to VCF 9.1, here is what official documentation (KB 440630 Scenario 6) tells us:
- VIDM (Workspace ONE Access) continues working after the upgrade to VCF Automation 9.1; Broadcom has not cut off VIDM in the upgrade path
- Migration to VCF Identity Broker is a Day-2 operation; it is not forced during the upgrade
- Plan the migration proactively: leaving VIDM in place long-term means maintaining a deprecated component with its own lifecycle burden
| Practical advice: Do not leave VIDM running indefinitely post-upgrade. It will continue to work in the short term, but it is deprecated. Build the migration to VIDB into your VCF 9.x adoption plan; it is a Day-2 task, not Day-0, so you have breathing room to plan it properly. |
6. Why this change matters for VCF architects
Simplified identity stack
In VCF 5.x, identity was genuinely complex. You had vCenter SSO (PSC-derived), Workspace ONE Access for the Aria Suite, NSX direct LDAP (from Jan 2024) and SDDC Manager's own authentication. These were loosely coupled, each with their own certificate management, upgrade dependencies and failure domains.
VCF 9.x collapses this. Identity Broker becomes the single SSO entry point for the VCF platform, reducing the number of moving parts and the number of things that can fail during an upgrade.
OIDC and OAuth 2.0: modern API authentication
VIDM's OAuth 2.0 support was primarily for Aria Automation API consumers. VIDB extends native OIDC support across the full VCF platform, meaning API token-based authentication is consistent regardless of which VCF component you are targeting. This matters for automation engineers building pipelines against VCF APIs.
Centralized role management
One of the persistent pain points with VIDM was that role assignments were still managed per-product. You assigned roles in Aria Automation separately from roles in vCenter or NSX. VIDB introduces centralized VCF-level role assignments, the goal being that you define access once at the platform level rather than per component. This is a material operational improvement in large environments with many operators.
VVF customers are not affected
If you are running VMware vSphere Foundation (VVF) rather than VCF, this change does not apply to you. VCF Identity Broker is a VCF-only component. VVF deployments continue to use vCenter SSO and direct LDAP/AD integration for their components; there is no VIDB in a VVF deployment.
7. Decision guide: what you should do
Use this table to identify what applies to your situation:
| Scenario | Recommendation |
|---|---|
| New VCF 9.x deployment | Use VIDB (embedded or appliance) |
| Upgrading from VCF 5.2 with VIDM | VIDM continues working; plan Day-2 migration to VIDB |
| Multi-site or critical auth HA needed | Use VIDB Appliance model (3-node cluster) |
| Single site, simpler operations | Use VIDB Embedded model (in vCenter) |
| VVF deployment (not VCF) | VIDB/Identity Broker not available; use vCenter SSO/LDAP directly |
| Still running VCF 4.x or 5.x | VIDM still applies; plan upgrade path to VCF 9.x |
Closing thoughts
The VIDM-to-VIDB transition is one of the most architecturally meaningful changes in the VCF 9.x platform. It is not just a product rename; it is a fundamental shift from an optional, externally managed SSO product to an embedded, platform-native identity brokering service. The change simplifies the identity stack, adds modern protocol support and sets VCF up for a more coherent security model going forward.
For customers on VCF 5.x with VIDM in place: you have time. Your upgrade to 9.1 does not break VIDM on Day 1. But VIDM is deprecated, and the smart move is to include VIDB migration in your 9.x adoption roadmap rather than discovering it as an afterthought when a certificate expires on an appliance you forgot you had.
For customers on VCF 9.0 or planning a greenfield 9.1 deployment: VIDM is not in the picture. You deploy VCF Identity Broker, choose embedded (simpler) or appliance (for high availability requirements), connect it to your corporate IdP and you are done. No separate Workspace ONE Access license, no separate appliance cluster to manage for SSO.
At WWT, we live in this space. Whether you're planning a greenfield VCF 9.x deployment or trying to untangle a 5.2 environment with VIDM baked in, our team has the hands-on experience to get you there cleanly. Let's talk.
Further reading: How VCF 9.1 Consolidates the Management Plane into a Single Unified Platform
Found this helpful? Hit like and share it with your team; chances are someone else is wrestling with the same questions.