Home › Articles › ArcSight SmartConnector and collector counting
ArcSight & Security · Track 03

ArcSight SmartConnector and collector counting

After events per second, the second number that drives an ArcSight finding is how many connectors you run. The dispute is rarely whether you collect from many sources. It is whether the vendor is counting connectors that are active, distinct, and in production, or simply every entry that ever appeared in an inventory. ArcSight SmartConnector and collector counting is where a finding inflates against infrastructure that no longer exists or was never licensable in the first place.

ArcSight SmartConnectors and collectors are the components that gather events from source systems, normalise them, and forward them to ESM or Logger. Depending on the agreement, connectors may be a licensed unit in their own right, or they may be relevant because their throughput drives the EPS figure. Either way, the count matters, and the count is exactly the kind of number that an audit tends to draw from a stale inventory rather than from what is running today.

What the audit counts as a connector

The first task is to pin what the agreement treats as a licensable connector, and then to reconcile that definition against reality. A raw inventory pulled from a management console will include connectors that were decommissioned but never removed, duplicates created during upgrades or migrations, non production connectors used only in test, and standby connectors configured for high availability that never carry live load. Counting all of them as production connectors overstates the deployment, and that overstatement either becomes a direct overclaim or inflates the EPS attributed across the estate.

The mechanic

A console listing 240 connector entries may correspond to 150 active production connectors once decommissioned, duplicate, non production, and standby entries are removed. Pricing the 90 phantom connectors, or attributing their historical throughput to your EPS, builds a finding on infrastructure that is not in service.

The connectors that should come out of the count

When we reconcile a connector inventory, several categories reduce the number. Decommissioned connectors that were retired but left in the inventory are not in service and are the focus of decommissioned ArcSight connectors still on the audit. Duplicate entries from upgrades double count a single source. Non production and lab connectors are not production load, consistent with how ArcSight non production and lab data is counted. High availability standby connectors carry no live events under normal operation, which connects to ArcSight high availability nodes and licensing.

How the four operations apply to a connector finding

We respond by taking over the channel during the seven day notice window so no raw connector export reaches the vendor unmanaged. We reconstruct the active production connector inventory from the platform's own configuration and throughput data, classifying every entry. We rebut by removing decommissioned, duplicate, non production, and standby connectors, and by correcting any EPS attribution that double counted their throughput. We resolve on a connector count that reflects the live deployment and convert forward with the inventory documented.

Why the inventory drifts upward over time

Connector inventories rarely shrink on their own. Sources are added, migrations create duplicates, test connectors are spun up and forgotten, and retired connectors are disabled but not deleted. The management console accumulates this history, and unless someone reconciles it, the console count becomes the audit count. The discipline of maintaining a clean, current inventory is the same discipline that defends a finding, which is why we treat connector counting as part of the broader work of reconciling ArcSight entitlements before an audit.

A representative pattern

In our anonymised banking engagement, case file E-03, connector counts were part of a $6.0M ArcSight finding alongside the EPS overclaim. Reconciling the active production connectors against the raw inventory, and removing entries that were decommissioned or duplicated, was part of the work that brought the matter to a $1.8M settlement, a 70 percent reduction. The connector count fell because the inventory was corrected to what was actually in service.

The questions that decide a connector counting dispute

Keeping the inventory audit ready between audits

The most reliable defense against an inflated connector count is an inventory that is kept current rather than reconstructed under pressure. A connector that is retired should be removed from the management console, not merely disabled. A duplicate created during an upgrade should be cleaned up once the migration is complete. Non production and standby connectors should be tagged so they are never confused with live production load. An organisation that maintains this hygiene meets an audit with a clean, defensible count on day one, instead of spending the seven day notice window separating live infrastructure from residue.

The financial logic is the familiar one. A deemed shortfall is priced at the then current list price, then grossed up with back maintenance, a first year of maintenance on the new licences, and the vendor's audit costs. Every phantom connector removed from the count reduces all of those charges together, and if the connector figure also drives EPS attribution, the correction cascades into the throughput finding as well. A clean inventory is therefore not housekeeping for its own sake; it is the base the entire remedy is calculated from.

Maintaining that hygiene also shortens the engagement when an audit does arrive. A buyer who can hand a defense team a tagged, current inventory on day one frees the seven day notice window for the arguments that actually move the number, rather than spending it untangling which entries are live. The cheapest connector defense is the one that was prepared before the notice landed.

Have an ArcSight connector count to defend?

A connector finding drawn from a stale inventory is among the most reducible ArcSight overclaims. We reconcile the active production deployment before any vendor script runs, through our ArcSight and Security audit defense. To put a defense team between you and the vendor, open a case or download the ArcSight and security defense briefing.

Get The Number Down →

Related field notes

These notes from the ArcSight and Security cluster go deeper on connector and collector counting. Each links back to the complete OpenText audit defense playbook for 2026.

If you have received an OpenText or Micro Focus audit notice, the first seven days shape every week that follows. OpenText Audit Defense is an independent, buyer side practice founded in 2020 by former vendor compliance leadership. We have defended more than 200 audits, cut the average finding by 68 percent, and mitigated more than $90M in claims against vendor positions. We do not resell OpenText software and we are not affiliated with OpenText Corporation. To open a case, use the contact form on this site.