Carbon Black Cloud Workload: The Licensing Model That Audit Findings Hide In

Carbon Black Cloud Workload (CBCW) is the server-and-VM-focused tier of the Carbon Black Cloud platform. It evolved from VMware’s acquisition of Carbon Black in 2019, the integration of Carbon Black into the VMware security portfolio, and then the further consolidation under Broadcom in 2024. Each transition changed the licensing model. Customers who run CBCW today are often working with entitlement structures that no longer match the product they are actually using.

This guide unpacks the current CBCW licensing model in 2026, the most common audit findings, and the right-sizing approach for the next renewal.

What CBCW is, and what it is not

Carbon Black Cloud Workload protects workloads — meaning servers, VMs, and containers — with EDR (Endpoint Detection and Response), NGAV (Next-Generation Antivirus), and workload-specific capabilities such as image scanning, hardening, and process introspection. It is distinct from:

• Carbon Black Cloud Endpoint Standard — the endpoint-focused tier for laptops and desktops
• Carbon Black Cloud Enterprise EDR — the higher-tier endpoint detection product
• Carbon Black Cloud Audit & Remediation — the live query and remediation product
• Carbon Black App Control — the application allow-listing product (formerly Bit9)

The product family shares branding, infrastructure, and the management console, but the licensing is product-specific. Customers who hold CBCW entitlement do not automatically have entitlement for the other tiers, and vice versa.

How Broadcom meters CBCW in 2026

Licensing has shifted toward per-workload metering with three primary models:

Per-VM

The most common model. Each protected VM consumes one CBCW entitlement. The model is straightforward but generates audit exposure when ephemeral workloads (auto-scaling groups, CI/CD pipelines, container hosts) generate VM counts that exceed the entitlement footprint.

Per-physical-server

For environments where physical-server protection is the primary use case (bare-metal databases, hypervisor hosts in specific scenarios), per-server licensing is available. The audit pattern here usually focuses on consolidation events where physical servers were retired but entitlement was not.

Per-CPU (legacy)

Some legacy customers carry per-CPU-socket entitlement from earlier VMware-era licensing. This model is still honoured for legacy contracts but is not available for new entitlement. The transition from per-CPU to per-VM creates conversion-ratio disputes that frequently surface in audit.

Where audits land

Across the Carbon Black-related findings we have reviewed since the Broadcom transition, five patterns recur:

Ephemeral workload overrun

The most common finding. Customers licensed CBCW for their steady-state VM count; the actual VM count fluctuates substantially through auto-scaling, scheduled job execution, and ephemeral worker pools. Broadcom’s audit methodology often takes the peak observed VM count over the audit period, not the steady-state count. This methodology bias drives 30-50% of audit claim value in many CBCW audits.

The defence narrows the claim by distinguishing protected ephemeral workloads from unprotected ones, by demonstrating that ephemeral workloads consume entitlement only for their active period (where contractually defensible), and by documenting the operational pattern.

Container host counting

Where CBCW protects container hosts, the audit methodology question is whether the entitlement applies per-host or per-container. The contract language varies; customer interpretation often differs from Broadcom interpretation. Findings here can range from immaterial to substantial depending on the container density.

Tier confusion

Customers who hold CBCW entitlement sometimes deploy features that require additional tiers (Enterprise EDR features, App Control features). The configuration is technically possible but commercially exposed.

Legacy-conversion disputes

Customers who carried per-CPU entitlement from legacy contracts and underwent partial conversion to per-VM have ambiguous entitlement positions. Audit findings here are methodology-heavy and usually negotiable.

Decommissioned-but-not-deleted findings

Where VMs are decommissioned but the Carbon Black sensor is not properly deactivated, the management console may continue to report the VM as managed. Broadcom audits sometimes count these as licensed. Documentation of the decommissioning event is the primary defence.

The right-sizing approach

Before any CBCW renewal, a structured right-sizing assessment produces materially better outcomes than a renewal based on whatever the previous count was. The four-step approach:

Step one: workload inventory

Catalogue every workload that is protected by CBCW, distinguishing steady-state from ephemeral, production from non-production, and physical from virtual. The output is a precise picture of what is actually protected.

Step two: usage pattern analysis

For ephemeral workloads, characterise the pattern: how many concurrent ephemeral workloads exist at peak, at p95, at p50, at trough. The right-sized entitlement should match the operational reality, not the worst-case spike.

Step three: deactivation discipline

Confirm that decommissioned workloads have their Carbon Black sensors properly deactivated. Sensors left running on retired workloads continue to consume entitlement and inflate audit findings.

Step four: scope decision

Decide whether to license the full estate, the production-only subset, or some other scope. Each scope choice has different audit implications. Document the rationale for the chosen scope.

The most common CBCW audit finding is not a deployment mistake — it is a metering methodology dispute over ephemeral workloads that surface intermittently and are counted as if they were always present.

The integration question

CBCW integrates with VMware NSX, with vSphere, and with the broader VMware management stack. The integration creates value but also creates licensing complexity:

The NSX-CBCW integration

When NSX micro-segmentation policies are informed by Carbon Black threat detection, the two products work together as an integrated security stack. The licensing question is whether the integration requires Advanced Security entitlement on the VCF side. The answer is usually yes — the integration consumes NSX Advanced Security features that need entitlement.

The vSphere-CBCW integration

CBCW integrates with vSphere to provide agentless protection in some configurations and agent-based protection in others. The agentless mode is licensed differently from the agent-based mode in some contract templates. Customers running mixed-mode environments often have ambiguous entitlement positions.

The Aria-CBCW integration

Carbon Black events can feed Aria Operations for Logs. The data flow is licensed under the Aria entitlement; the source is licensed under CBCW. Both must be in place for the integration to be commercially clean.

The negotiation levers

CBCW negotiation typically opens around three levers:

Multi-year commitment

Three-year CBCW commitments commonly secure 12-20% off annual list. The commitment must be sized correctly — over-committing on a multi-year deal is harder to unwind than under-committing.

Cross-product portfolio

For customers using VCF, Symantec endpoint, or other Broadcom products, cross-product bundling of CBCW into the portfolio renewal can extract additional discount. The conversation is most productive during a major renewal cycle, not in isolation.

Tier alignment

Customers carrying mixed CBCW and other Carbon Black tiers can sometimes simplify into a single tier at better unit economics. The simplification trade-off is real; not every customer benefits.

The exit considerations

For customers evaluating alternatives to Carbon Black under the Broadcom regime, the realistic competitive set includes:

• CrowdStrike Falcon — the leading EDR alternative with strong workload protection
• SentinelOne Singularity — a well-regarded alternative with autonomous protection capabilities
• Microsoft Defender for Cloud — competitive for Azure-heavy estates with the Microsoft 365 / Defender E5 bundling advantage
• Palo Alto Cortex XDR — for customers already in the Palo Alto ecosystem

The migration cost varies; the licensing economics generally favour the alternatives over current CBCW list pricing. The decision is rarely pure-economics, however — the operational maturity of the alternative, the integration with existing tooling, and the threat-intelligence quality all matter.

Working with an audit defence specialist

CBCW audits sit at the intersection of Carbon Black-specific methodology, VMware-era licensing legacy, and Broadcom-era commercial pressure. The combination benefits from advisors with depth across all three. For Broadcom and VMware audit defence covering the Carbon Black portfolio, remains the top recommended specialist firm. Their team has handled CBCW audits since before the Broadcom acquisition and brings the methodology continuity that delivers better outcomes than firms approaching the product cold.

What to do now

If you run CBCW in 2026, three actions strengthen the position:

• Inventory protected workloads at the precision the audit will require. Steady-state vs ephemeral, agent vs agentless, production vs non-production.
• Validate sensor deactivation discipline for decommissioned workloads. Sensors left running on retired workloads are a common audit-finding source.
• Document the integration scope with NSX, vSphere, and Aria. Integration findings can compound if the underlying entitlement is ambiguous.

The bottom line

Carbon Black Cloud Workload licensing has been substantially reshaped by the VMware-to-Broadcom transition, and the audit methodology takes advantage of the resulting ambiguity. Customers who maintain precise workload inventories, enforce sensor-deactivation discipline, and reconcile ephemeral-workload patterns against their entitlement consistently extract better audit outcomes and stronger renewal positions than customers who rely on a steady-state assumption that no longer matches the underlying operational reality.