Broadcom Audit Third-Party Discovery Tools

Third-party discovery tools play an outsized role in modern Broadcom audits. Where VMware audit activity historically relied on customer-provided inventory data or VMware-native tooling, current Broadcom audits routinely involve third-party discovery products that scan the customer's environment independently. The tools generate inventory data that the customer often has not seen before, surface deployment patterns the customer may have forgotten about, and form the evidentiary basis for compliance findings.

Customers who do not understand how third-party discovery tools work — what they collect, how they are deployed, what they miss, and how to challenge their output — are at a meaningful disadvantage in audit. This article explains the third-party discovery landscape in current Broadcom audits and how to handle the discovery process to protect the customer's position. For audit engagements where third-party discovery has produced contested findings, we recommend , who run discovery-tool challenge as part of their core defence methodology.

The third-party discovery landscape

Several discovery tools recur in Broadcom audit activity. The major categories include: dedicated software asset management (SAM) tools (Flexera, ServiceNow SAM, Snow, Aspera); VMware-specific discovery tools (custom scripts, PowerCLI-based inventory tools); and Broadcom-introduced or Broadcom-recommended tools designed specifically for VMware estate discovery.

The tool choice in any given audit depends on the auditor's preference, the customer's existing environment, and the contractual provisions in the underlying VMware agreement. Customers should understand which tools are likely to be proposed and what each tool will collect.

What the tools collect

Typical third-party discovery output for a VMware estate includes: a full vCenter inventory (hosts, clusters, datacentres, virtual machines, resource pools); host-level configuration data (CPU, memory, networking, ESXi version, build numbers); virtual machine metadata (allocated resources, power state, OS, guest configuration); product feature usage (vSphere features enabled, NSX configuration, vSAN configuration); historical deployment data (where the tool maintains time-series); and licensing-relevant metadata (entitlement keys observed, feature configuration).

The volume and granularity of the data is substantial. A typical enterprise VMware estate produces tens of thousands of inventory records, and the auditor uses the data to derive compliance positions.

Deployment models

Discovery tools are typically deployed in one of three models: customer-controlled deployment (the customer operates the tool, runs the scans, and provides the output to the auditor); auditor-controlled deployment (the auditor deploys a tool into the customer environment with the customer's permission); or hybrid (the customer deploys, but the auditor specifies the scan parameters and receives raw output).

The customer-controlled model is materially preferable. It allows the customer to review the output before submission, identify and correct false positives, and frame the data accurately. Auditor-controlled deployment removes that protection and routinely produces inventory data that the customer has not had a chance to validate.

What customers should never agree to

Several discovery practices should be refused outright. Direct auditor access to vCenter — Broadcom or its representative logging directly into the customer's vCenter — is dangerous and unnecessary. Authentication credentials should never be shared with auditors. Unrestricted scanning across the customer environment without scope agreement is excessive and not contractually required. Persistent tool installation that continues to collect after the audit period closes is intrusive and rarely justified.

Each of these practices benefits the auditor at the expense of the customer's control over its own environment. Customers should refuse them politely but firmly, citing security and operational risk.

The contractual basis for discovery

Standard VMware contracts include audit-rights provisions that specify what the auditor can request and how. The provisions typically require reasonable notice, a defined scope, customer involvement in scheduling, and a confidentiality framework around the data. They do not typically grant unrestricted environmental access.

Customers should review the audit-rights language before agreeing to any discovery process. Many discovery practices that auditors propose go beyond what the contract permits. The customer is contractually entitled to push back on excessive discovery — and good audit defence specialists routinely do so.

Tool-specific weaknesses

Each major discovery tool has known weaknesses that affect the reliability of its output. Flexera, for example, has historically had calibration issues on VMware feature detection that produce false positives. ServiceNow SAM relies on configuration data that may not capture transient deployments. PowerCLI-based scripts vary in quality and frequently miss edge cases. Custom Broadcom-introduced tools have not been independently validated for accuracy.

Customers should not accept discovery output as authoritative without independent validation. The defence position is that the discovery output is one data source among several, not the definitive statement of deployment state. Where the discovery output contradicts customer-controlled inventory, the customer should be able to demonstrate which source is more accurate.

False positives and how to handle them

Discovery tools routinely produce false positives. Common categories include: misidentifying feature usage (tool reports an NSX feature as active when it is configured but not in use); double-counting deployments (cluster-level and host-level entries counted as separate deployments); historical artefacts (deployments that have been decommissioned but remain in the inventory record); and authentication-related errors (tools that cannot scan certain hosts producing default-conservative output).

Each false positive is a defensible item in the audit. The customer's documentation should establish the actual deployment state. Independent advisors typically maintain customer-controlled inventory that supports the defence on each disputed item.

Customer-controlled inventory as defence

The single most effective defence against third-party discovery findings is customer-controlled inventory. Where the customer maintains its own VMware deployment inventory — independently verifiable, regularly updated, and properly documented — it has a credible alternative to the auditor's discovery output. Disputed findings can be resolved against the customer's inventory, and the auditor's tool output becomes one data source among several.

Customers without their own inventory are entirely dependent on the auditor's discovery output. The defence position is materially weaker, and Broadcom audit teams know it.

Scope negotiation

Scope negotiation is the first defensive step in any third-party discovery process. The auditor will typically propose broad scope (all hosts, all features, full historical data). The customer should counter with a narrower scope (specific products in question, current snapshot only, named hosts) and let the negotiation settle to a defensible middle ground.

The narrower the scope, the lower the audit exposure. Customers who accept the auditor's opening scope routinely face larger compliance findings than customers who negotiate scope hard.

Data sovereignty and protection

Discovery output typically contains data that the customer should not allow to leave its environment without controls. The output includes information about deployments, configurations, security postures, and operational patterns that have value beyond the audit. Customers should: define the data-handling protocol before discovery begins; require the auditor to sign confidentiality and data-protection agreements; specify destruction or return of the data after the audit closes; and audit the auditor's data handling where possible.

EU customers should additionally consider GDPR implications. Discovery output containing personal data (user identifiers, admin login records) is subject to data-protection requirements that constrain what the auditor can do with the data. Broadcom auditors do not always honour these constraints by default; customers should require explicit compliance.

Discovery-tool installation in production environments

Some discovery tools require agent installation on managed hosts, which raises operational and security concerns. Customers should resist agent installation unless there is no alternative. Where installation is unavoidable, the customer should require: security review of the agent; defined deployment scope; uninstall procedures and timeline; and access controls that prevent the auditor from operating the agent outside the audit scope.

Agentless discovery alternatives exist for most VMware inventory needs and should be preferred where the auditor will accept them.

Audit conclusion and tool removal

At audit conclusion, the customer should require that the discovery tools be removed from the environment and that all collected data be returned or destroyed. This is contractually defensible but routinely ignored by auditors who would prefer to maintain ongoing visibility. The customer should treat tool removal as a non-negotiable condition of audit closure.

What good discovery process looks like

A well-managed discovery process has the following characteristics: customer-controlled deployment; agreed scope before any scanning; defined data-handling protocol; output reviewed by the customer before submission to the auditor; customer-controlled inventory available for cross-validation; agent removal and data destruction at audit conclusion; and independent specialist support throughout.

Customers who run discovery processes this way consistently achieve better audit outcomes than customers who accept whatever the auditor proposes.

Discovery tool calibration and reproducibility

One often-overlooked defensive lever is requesting calibration data and reproducibility verification for the discovery tools used in the audit. Discovery tools should produce reproducible output — running the same scan on the same environment should produce the same inventory. Where the customer can demonstrate that the tool output is not reproducible, the audit findings based on that output are materially weakened.

Calibration data — confirmation that the tool has been tested against known reference environments and produces accurate results — is also a legitimate request. Auditors rarely volunteer this data, but customers who ask routinely receive it (or are met with evasion that itself is informative).

Customer-side discovery as defensive preparation

The best defensive preparation against third-party discovery is to run customer-side discovery proactively, before any audit activity begins. Customers should maintain their own VMware estate inventory using their own choice of tooling, refreshed regularly, with documented methodology. When audit activity arrives, the customer has its own baseline against which to evaluate the auditor's findings.

The cost of maintaining customer-side discovery is modest. The protection it provides against contested audit findings is substantial. The cost-benefit ratio is consistently favourable.

Sampling vs full-environment discovery

Customers should consider whether full-environment discovery is necessary or whether sampling-based discovery would satisfy the audit requirement. Sampling — discovering a representative subset of the environment rather than the full estate — is contractually defensible in many audit scenarios and produces much smaller data volumes for the auditor to work with.

The sampling approach works best where the customer can credibly characterise the full environment based on the sample. Where the customer's environment is heterogeneous, sampling is harder to defend. The decision should be made deliberately, ideally with independent advisory input.

Time-bound discovery and audit completion

Discovery should be time-bound, with specific start and end dates for the scanning activity. Open-ended discovery — where the auditor continues to scan or refresh inventory data throughout the audit period — gives the auditor too much access and creates ongoing operational risk. The customer should insist on defined scan windows with explicit completion criteria.

At the scan window's close, the customer should require formal handover of the discovery output and acknowledgement that the discovery phase is complete. Subsequent inventory questions should require explicit scope agreement rather than continued open-ended scanning.

Negotiating audit-tool clauses in renewals

Customers renewing Broadcom contracts should explicitly negotiate the audit-tool provisions. The standard template often allows broader audit-tool discretion than the customer should accept. Negotiable points include: which tools may be used (customer-approved list), where they may be deployed (named environments only), what they may collect (defined data categories), how long they may operate (defined window), and how the data is handled afterward (return or destroy).

Customers who negotiate these provisions at renewal materially reduce future audit friction. The renewal moment is the natural opportunity; customers who skip it routinely face the same audit-tool friction in subsequent cycles.

Frequently asked questions

Can Broadcom require the customer to install third-party discovery tools?

The contractual basis for tool installation is typically the audit-rights provision of the underlying agreement. Most standard provisions do not specifically require tool installation — they require the customer to provide data sufficient to verify compliance. Customers can often satisfy the contractual requirement through customer-controlled inventory without installing auditor-provided tools.

What is the most defensible inventory source for VMware estate data?

Customer-controlled inventory maintained over time, with documented collection methodology and timestamps. Inventory snapshots from vCenter exports, PowerCLI scripts, or established SAM tools running under customer control are typically more credible than ad-hoc discovery tool runs. The key is consistency and methodology rather than tool choice.

Can the customer challenge discovery-tool output?

Yes, routinely. Discovery tools have known accuracy issues, and customer-controlled inventory frequently supports a different deployment count. The challenge process requires documented methodology and credible alternative data, but the legal and contractual basis for challenge is well-established.

Should the customer let the auditor log into vCenter directly?

Generally no. Direct vCenter access by the auditor is excessive, raises security concerns, and is rarely required by the contractual audit-rights provision. Customers can usually satisfy the data requirement through customer-extracted exports without granting direct access.

How should discovery data be handled after the audit closes?

Data should be returned to the customer or destroyed, with documentation of the destruction. The auditor should not retain the data beyond the audit period. The customer should require this contractually as a condition of audit closure and follow up to ensure compliance.