Big Changes for VCF Security & Compliance: What’s Included—and What’s Not
Broadcom’s November 2026 updates bring important changes to VMware Cloud Foundation security, compliance and recovery. Here’s what is included, what is planned and what remains a separate Advanced Service.
What changed in VCF—and which capabilities might your organization already be entitled to use? The distinction starts with what you’re managing: VCF infrastructure configuration and compliance are included in supported platform releases, with expanded native enforcement planned next. Enterprise VMware Salt compliance for guest operating systems and workloads, however, remains a separately licensed Advanced Service.
The most immediate change is Site Recovery Manager (SRM): eligible active VCF and VMware vSphere Foundation (VVF) subscribers can now obtain SRM entitlement through an interim license. Our step-by-step SRM licensing guide covers the process. Isolated cyber recovery is a different capability and retains its own Advanced Service offering.
These developments didn’t appear overnight. VMware began integrating Salt Minion deployment and management with VMware Tools back in 2022. The technology has evolved over several years; Broadcom’s November 4, 2026 announcement makes the resulting product and entitlement boundaries more explicit. We’ll trace that history below.
VCF capability map: What’s included, what’s changed, and what’s separate?
The table distinguishes included VCF infrastructure features from new entitlements, planned native enhancements, and separately licensed workload and cyber-recovery services. Each row shows the previous position beside the current or announced change.
| Capability / entitlement | Previously | Now / next |
|---|---|---|
| VCF Operations security visibility
Included in VCF
|
Operations, Logs, Networks, security posture and alerts were already available in supported VCF releases. | These platform capabilities remain included. Separately licensed products, such as advanced workload security tools, have their own entitlements. |
| Salt for VCF Components
Included in VCF
|
VCF 9.1 introduced component-focused configuration and compliance through the VCF Operations UI. | VCF 9.1.1 adds the Salt for VCF Components API with 300+ settings. This manages VCF infrastructure—not guest workloads. |
| SRM disaster recovery
New entitlement now
|
SRM was separately licensed or part of earlier optional recovery packaging. | Eligible active VCF/VVF subscribers now have SRM rights. The interim key supports up to 10,000 protected VMs and expires May 2, 2027; integrated 9.1.3 licensing is planned. Get the key and transition steps. |
| Expanded VCF infrastructure compliance
Planned within VCF
|
VCF already offered infrastructure security posture and component configuration controls. | Broader native benchmark checks, configuration enforcement, drift detection and remediation are planned for the next VCF release; not yet GA. |
| VPC policy-based connectivity
Planned within VCF
|
VCF already supported VPC networking and its existing native networking controls. | Expanded policy-driven connectivity and workload isolation are planned for the next VCF release. |
| Enterprise Salt workload compliance
Separate Advanced Service
|
Guest-OS and workload management with enterprise VMware Salt was offered through optional ACC. | VMware Compliance and Configuration Management is now a standalone, separately licensed service for VM/OS and container workload enforcement. |
| Isolated cyber recovery
Separate Advanced Service
|
Cyber-recovery and clean-room capabilities were associated with ACC and optional recovery solutions. | VMware Live Recovery is offered separately for cyber recovery; the new SRM entitlement does not include this service. |
| HyperArmor ESX protection
Separate Advanced Service
|
Not part of the base VCF entitlement. | Announced as a separate ESX protection offering. Confirm availability, release compatibility and licensing. |
Reading note: Infrastructure means the VCF platform components (such as vCenter, ESX, NSX, and SDDC Manager); workload means the guest operating systems, applications, VMs, and containers you run on that platform. Included platform compliance is not an enterprise Salt workload license. Future native features are not GA until released. Sources: November portfolio announcement, VCF component Salt API, workload Advanced Service, and SRM KB 461219.
A real example: SRM disaster recovery moves into VCF and VVF
The connection is documented, not just editorial speculation. When Broadcom introduced Advanced Cyber Compliance in November 2025, it explicitly presented fully orchestrated disaster recovery across on-premises VCF sites alongside VMware Salt-driven compliance and other cyber-resilience capabilities. It also described an evolving isolated cyber-recovery approach. That historical ACC positioning helps explain why customers may have considered recovery and compliance parts of the same purchase conversation.
The November 4 portfolio update makes the distinction clearer. VCF infrastructure compliance is a core-platform capability, with further native enforcement enhancements planned. Customer workload compliance is a separately licensed add-on through VMware Compliance and Configuration Management. SRM site disaster recovery is now entitled for eligible active VCF and VVF subscribers, while isolated cyber recovery remains a separate VMware Live Recovery Advanced Service. The old ACC-era discussion brought several of these outcomes together; the current portfolio assigns them distinct licensing paths. SRM disaster recovery is not the same thing as clean-room cyber recovery.
For a customer who did not buy ACC, the SRM change is particularly concrete: eligible active VCF/VVF subscriptions can obtain a temporary SRM license today under Broadcom KB 461219, ahead of integrated Protection and Recovery licensing in the next release. See our hands-on SRM entitlement guide for Support Portal navigation, license activation, version prerequisites, and the interim-key transition.
For existing ACC subscribers, this is a reason to audit and preserve current contract rights, not to remove a working component or assume that a new bundle automatically replaces an old one. And for readers of our cyber-defense-in-depth blueprint, it is a helpful reminder that recovering from a site outage and recovering from a compromised environment are related but different operational objectives.
Already own ACC? Here’s what changes for you
If you currently have an ACC entitlement, do not assume the November announcement automatically changes the rights under your existing agreement. Broadcom’s November 4 portfolio announcement presents VMware Live Recovery for cyber recovery and VMware Compliance and Configuration Management for workload functionality as distinct Advanced Services. The announcements do not establish a universal, automatic conversion or renewal procedure for existing ACC subscriptions. Confirm your actual contractual term, covered features, renewal choices and migration requirements with Broadcom before changing production licensing or deployments.
Before making a purchasing or technical change, inventory what you actually use under ACC:
- Workload configuration: Are enterprise Salt masters, minions, states, benchmark policies, reporting, and workload remediation in service?
- VCF platform enforcement: Which VCF Operations component-compliance checks, desired states, drift assessments, or remediation tasks depend on current ACC rights?
- Cyber recovery: Do you operate an on-premises isolated recovery environment, restore-point validation, EDR integration, or cyber-recovery orchestration?
- Disaster recovery: Are SRM/Live Site Recovery capabilities deployed, and if so, under which subscriptions and license assignments?
- Subscription lifecycle: When does the current entitlement end, which workloads/sites does it cover, and what support/download rights apply?
Then compare that inventory with three distinct paths: the current ACC term you already own, the new workload Compliance and Configuration Management Advanced Service, and VMware Live Recovery for cyber recovery. Verify any migration, renewal, entitlement conversion, or expansion details with your account team and the current product terms. Broadcom has not established in the linked announcement that a single new service reproduces every historic ACC capability or that every account follows an identical migration procedure.
VCF 9.1.1 versus the next release: What’s available and what’s planned?
Infrastructure compliance is already part of VCF. VCF 9.1 provides component-focused configuration and security-posture controls through VCF Operations; VCF 9.1.1 added the VMware Salt for VCF Components API, exposing more than 300 settings across components such as vCenter, NSX, SDDC Manager and ESX. That included infrastructure implementation is not the same as enterprise Salt for customer workloads. The latter remains a separate Advanced Service.
Separately, the November 4 portfolio announcement calls out VCF infrastructure configuration management and compliance as a new native feature planned for the next release, currently estimated for Q1 FY27. It describes proactive enforcement, drift detection and remediation, and checks aligned to standards such as PCI and the VCF Security Baseline. That planned scope should not be silently upgraded into a claim that everything announced is shipping in 9.1.1 or included in every currently deployed license.
The actionable distinction is software presence, capability availability, and license entitlement are not synonymous. As you audit your environment, record the running release, the licensed functions actually exposed in VCF Operations, what the API can perform for your components, and which planned controls are not yet released. The earlier ACC-era documents remain helpful for architectural background but are not the current word on November’s packaging.
What VMware Compliance and Configuration Management does for workloads
Workload compliance is the add-on, not the included VCF infrastructure capability. The separately licensed VMware Compliance and Configuration Management service builds on enterprise VMware Salt to manage settings inside customer operating systems and workloads. Its architecture includes a VMware Salt Server for centralized management, reporting and role-based access control; Salt masters; minions on managed endpoints; and an event bus. Broadcom’s November 4 announcement describes support for Linux distributions, Windows and macOS, with workload and integration support subject to the product’s current matrices.
For a security team, the value is not merely showing that a benchmark failed. It’s being able to define an approved state, detect drift, and execute a reviewed remediation that restores it. Typical examples include:
- Identifying an unapproved firewall opening or service setting and restoring the approved value.
- Detecting a changed package, file permission, service state, or policy setting across a managed workload fleet.
- Using CIS, supported security benchmark content, or a customer-defined standard to assess compliance and produce evidence of the corrective action.
- Ingesting third-party vulnerability information to prioritize appropriate remediation jobs, with application-specific validation before closing the incident.
Security outcomes require actual policies, connected agents, appropriate privileges, supported content, and operator-approved change procedures. “Event driven” does not mean every security finding is automatically safe to repair. Some changes need maintenance windows, service restarts, canaries, exceptions, or human approval. The ability to report on a benchmark is also not a guarantee of regulatory certification.
Four years in the making: Salt integration began with VMware Tools 12
The November 2026 workload-compliance announcement is not the beginning of VMware’s Salt integration. VMware Tools 12.0.0 shipped March 1, 2022. That release added optional support for setting up and managing Salt Minions, including a Component Manager plugin. VMware’s open-vm-tools project documents those early components, and a 2022 SUSE update independently records the new guest-variable integration and optional Linux packaging.
What did that enable? VMware Tools could help deploy, remove and monitor Salt Minions inside supported VMs. A vSphere administrator could pass settings through VM guest variables, while the guest-side integration used an installation script to manage the minion. For Linux, the project recommended a separate optional open-vm-tools-salt-minion package where the distribution provides it. On Windows, Broadcom’s VMware Tools component inventory KB documents the SaltMinion installer feature. The Salt/VMware Tools integration repository explains the guest-variable, tools.conf and command-line control options.
Importantly, VMware Tools does not automatically mean a Salt Minion is running, registered to a Salt master, or entitled to enterprise workload compliance. This integration is a way to simplify onboarding and lifecycle management of the agent; actual desired-state enforcement requires the supported minion, an operational Salt control plane, policies, permissions and the appropriate service rights.
It has also been exercised in real operating environments for years. Broadcom’s August 2025 support KB 405985 documents a practical limitation: automatic deployment can fail when the VM cannot reach the Salt package repository, with alternate local-source approaches available. By November 2026, the announcement of standalone VMware Compliance and Configuration Management built on an established Salt agent and management architecture rather than introducing it from scratch.
For a starting inventory, identify your current VMware Tools/open-vm-tools version, whether its optional Salt integration is installed, how minions would reach their package source and master, and whether your subscription includes the enterprise service. Our earlier VMware Tools and virtual hardware lifecycle article is useful background on why keeping guest integration components current matters.
From alerts to enforcement: Connecting our VCF cyber-defense blueprint
On November 2, we published Cybersecurity Awareness Month Is Over. Your Exposure Isn’t. That guide laid out an operational pattern: Observe → Understand → Decide → Automate → Enforce → Verify. It connected VCF Operations, logs, flow visibility, Orchestrator, and licensed protection tools to actual response workflows. The ACC/Salt entitlement boundary was important then. After November 4, it deserves its own follow-up.
Consider a routine but consequential finding: a guest operating system’s security configuration changes outside an approved process. VCF telemetry might help an organization observe the condition; an alert or change record can provide context; an authorized workflow can decide whether a change should be made. But the enforcement against the guest workload, and the evidence that the guest returned to its intended state, require the right automation technology and permissions. That is where the separately licensed, workload-focused VMware Salt service fits. VCF’s included infrastructure compliance manages the VCF components; it does not automatically enforce desired state inside the guest operating systems and applications running on them.
For the workflow engine itself, see our VCF Operations Orchestrator standalone deployment guide. It explains how to create and verify operational actions without deploying VCF Automation. Orchestrator and Salt can be complementary, but they are not interchangeable: one coordinates workflows and integrations, while the other can execute and reconcile declared state on managed targets. Any integration between them still has to be explicitly built, secured, and tested.
Another example arrived in Broadcom’s November 3 PHP2Shell-to-Salt technical walkthrough. It illustrates the distinction between finding vulnerable application runtimes, preparing approved fixes, applying changes to supported workloads, and verifying the outcome. It also explains where WAF or network protections can buy time while the underlying workload is repaired. An alert is not a patch. A Salt job is not a substitute for application testing. Together, with explicit integrations and change controls, they can form a far more complete response.
Disaster recovery isn’t cyber recovery: A critical VCF licensing distinction
Disaster recovery and cyber recovery answer different failure scenarios. SRM orchestrates the recovery of applications and workloads when a site fails or a planned migration is necessary. Cyber recovery adds challenges such as finding a clean restore point, validating it in isolation, and preventing compromised workloads from reconnecting prematurely. The expanded on-premises clean-room and cyber recovery story is associated with the separately offered VMware Live Recovery Advanced Service in the November 4 announcement.
For the newly included SRM entitlement available to active VCF/VVF subscribers, we’ve already published a step-by-step SRM licensing and disaster recovery guide. That article covers the interim license path and the planned integrated release. It does not suggest that new SRM rights automatically include isolated cyber recovery, workload Salt licensing, or the complete former ACC package.
The November portfolio announcement also names other future native VCF capabilities and optional Advanced Services, including VPC policy-based connectivity and HyperArmor. Their status and licensing should be checked independently. This article deliberately focuses on the ACC-related lines that affect compliance enforcement and cyber-resilience decisions now, rather than treating every announced capability as a currently included feature.
Where to start: A practical plan for VCF customers
| Your situation | Best first move | What not to assume |
|---|---|---|
| We run VCF and want to understand our new options. | Inventory the VCF 9.1/9.1.1 component-facing capabilities you can use now; determine whether workload enforcement needs the new Advanced Service; monitor the next native VCF release. | That the embedded VCF Salt component API provides full enterprise guest-workload compliance at no additional entitlement. |
| We already own ACC. | Inventory current licensed use cases, entitlement end date, current Salt/cyber-recovery architecture and migration needs; compare the new services against the rights you actually exercise. | That rights end immediately, or that every former ACC component migrates automatically to one new license. |
| We need a full cyber-resilience response. | Separate infrastructure hardening, guest-workload compliance, DR orchestration and isolated cyber recovery into clear requirements; evaluate the appropriate combination of VCF and Advanced Services. | That a site failover plan, vulnerability scan, or automatic remediation job by itself proves recoverability from ransomware. |
Five practical checks before changing anything
- Document your license and release baseline. Capture your active VCF and ACC entitlements, contract term, VCF Operations release, Salt components, protected workloads and supported software versions.
- Separate infrastructure from workloads. Identify which controls target vCenter/ESX/NSX/VCF itself and which require a minion or other mechanism inside Windows, Linux or containerized workloads.
- Choose one high-value use case. Start with a known configuration control or risk finding; define what compliant state looks like and who can approve a change.
- Test remediation as a lifecycle. Assess → approve → canary → remediate → validate → record evidence → recheck for drift. Plan exceptions and rollback before expanding fleet-wide.
- Verify future packaging with official sources. Before renewal or upgrade decisions, check the November 4 announcements, the latest VCF FAQ, current support documentation, and your actual product terms. Ask the account team for the precise licensing, download, and transition procedure applicable to your subscription.
One historical troubleshooting wrinkle is worth remembering. Broadcom KB 455684 documents that ACC trial licenses for enterprise Salt were not synchronized through the Business Service Console in affected 2026 configurations and separately distinguishes the internal Salt RaaS service used by VCF from the independently deployed workload Salt platform. That older KB is useful as a caution against conflating products, not as a guaranteed November 2026 licensing procedure for the newly announced service.
Architect’s Edge: Put the VCF changes to work
There’s a security difference between knowing a system is out of compliance, having an approved method to fix it, and proving it was fixed. That is what the November changes should prompt infrastructure and security leaders to revisit.
For a VCF customer, the next questions are clearer: Which infrastructure protections are already included? Which new entitlements can we activate now? Which native controls are planned? And where do workload-level enforcement and isolated cyber recovery require separately licensed services?
Our defense-in-depth blueprint, the Orchestrator implementation guide, and the SRM entitlement walkthrough cover the operational pieces. Together, these guides explain how the new VCF entitlement boundaries translate into practical security operations and recovery planning.
Official sources and technical follow-up
- Broadcom — November 4, 2026 VCF portfolio announcement (native versus separate Advanced Services and next-release outlook)
- Broadcom — Advanced Cyber Compliance is Now Available to VCF Customers (November 3, 2025) (original ACC scope including orchestrated on-premises disaster recovery)
- Broadcom — Announcing VMware Compliance and Configuration Management (workload architecture and service scope)
- Broadcom — From Open Source to Enterprise: VMware Salt API Evolution (distinguishes open-source Salt, enterprise VMware Salt, and VCF component API)
- Broadcom — PHP2Shell Alert to Action Using VMware Salt (practical vulnerability remediation use case)
- VMware — Compliance and Configuration Management product page
- VMware Hands-on Lab — VMware Salt in VCF 9.1: Configuration, Compliance & Vulnerability Management
- Broadcom KB 455684 — Historical ACC/Salt licensing and Business Service Console distinction
- Broadcom KB 304809 — VMware Tools release history (Tools 12.0.0, March 1, 2022)
- VMware open-vm-tools — Salt Minion Setup and Component Manager (original optional guest integration)
- VMware Salt/VMware Tools integration scripts (guest variables, install and status operations)
- Broadcom KB 313772 — Windows VMware Tools installer features (SaltMinion feature)
- Broadcom KB 405985 — Salt Minion deployment in isolated environments (repository requirements and alternatives)
Draft reviewed against public Broadcom materials on November 9, 2026. Product entitlements, documentation and future release targets may change. Customer-specific contracts and current Broadcom terms govern licensing; planned features are not represented here as generally available.
