ArcSight & Security · Track 03

ArcSight identity user definitions and consumer counts

Some ArcSight and related security products are licensed by user or by identity rather than by throughput, and that is where definitions become the whole argument. An ArcSight identity user count inflates a finding when service accounts, disabled identities, and indirect consumers are all counted as licensable users.

When a metric is named user or identity based, the audit answer turns entirely on who counts as a user. The vendor reading is expansive, sweeping in every account that appears in a directory or an event stream. The defensible reading is narrow, limited to the human consumers the agreement actually contemplates. The gap between those two readings is the finding.

What the audit treats as a user

OpenText measures identity based metrics from directory exports, authentication logs, and the product's own user tables. A raw export of that kind does not distinguish a working analyst from a service account, a disabled former employee, or a system identity created for integration. If every row becomes a counted user, the number balloons. Because the deemed acquisition remedy prices each unlicensed user at list and then adds back maintenance and audit cost, an inflated user table produces a finding inflated several times over.

The identities that should not be on the count

Service and system accounts. Non human identities created for integrations, scheduled jobs, and machine to machine communication are not the consumers a named user metric is meant to price.
Disabled and dormant accounts. Identities that are deactivated, expired, or have shown no activity across the measurement window are not live consumers and should not be counted as such.
Duplicate identities. A single person can appear under multiple accounts across merged directories. Counting each as a distinct user overstates the real population.
Indirect consumers. Indirect access is a recognized line of challenge. Whether a person who only ever sees output passed through another system counts as a direct user depends on the agreement, and it is rarely as broad as the vendor asserts.

The mechanic

A directory export of 5,000 identities can reduce to 1,900 licensable users once service accounts, disabled identities, duplicates, and indirect only consumers are removed. The finding is priced on 5,000. The defensible number is 1,900.

How we reconstruct the consumer count

We rebuild the user population from activity rather than from a static export. The reconstruction classifies every identity by type and by behavior, separating human analysts who actively use the platform from service accounts, dormant identities, and duplicates. We then test the indirect access question against the agreement, because the definition of a consumer drives the entire count. Once the population is corrected, we reconcile it to the entitlement and reprice the finding to the defensible figure.

The discipline is the same one that produced the reductions in our anonymised engagements, where correcting who actually consumed a product turned large opening findings into far smaller settlements. In the Documentum matter, case file E-01, disqualifying service and dormant accounts moved a $7.2M seat count finding to a $1.6M settlement, a 78 percent reduction. Identity based ArcSight metrics respond to the same argument.

Holding the definition line

The most important move is to refuse a raw export as the basis of a count. During the seven day notice window, take over the channel and insist that the definition of a user be established against the agreement before any directory data is measured. The evidence that wins this argument is your own activity and identity data, classified deliberately, and it is far stronger when you control how it is gathered and presented.

The indirect access question, and why it is rarely as broad as claimed

Indirect access is the part of an identity dispute that produces the largest swings, and it is also the part where vendor positions are most aggressive. The claim is that anyone who benefits from a product, even at a distance, is a licensable user. Applied to a security platform, that reasoning could sweep in people who never log in and only ever see a dashboard tile populated by data the platform produced. Whether such a person counts depends entirely on how the agreement defines a user, and most definitions are narrower than the expansive reading the audit advances. We test the indirect claim against the actual contract language rather than against the vendor assertion, and where the definition does not reach an indirect only consumer, that consumer comes off the count.

The reason this matters so much is leverage. Indirect populations can be large, sometimes far larger than the direct user base, so an expansive indirect reading can dwarf the rest of the finding. Holding the definition line on indirect access is therefore often the single most valuable move in an identity based ArcSight defense.

Classifying identities the way a rebuttal requires

A defensible consumer count is built from a classification that an auditor can follow. We sort every identity into categories and document the basis for each placement.

Active human users. Real people who authenticated and used the platform during the measurement window. These are the consumers the metric is meant to price.
Service and system accounts. Non human identities for integrations and scheduled work, removed because they are not users in the contractual sense.
Dormant and disabled identities. Accounts with no activity or that are deactivated, removed because they consume nothing.
Duplicates. Multiple accounts resolving to one person, collapsed to a single user.
Indirect only consumers. Tested against the agreement and counted only where the definition genuinely reaches them.

The corrected population that emerges is the defensible base, and it is typically a fraction of the raw export the audit started from. Each placement is documented against evidence the vendor can verify, so the reconstruction reads as a reconciliation rather than an assertion, and that is what allows it to hold under pressure during the rebuttal.

One further point is worth making about timing. The classification is far easier to defend when it is built from activity captured close to the measurement window rather than reconstructed long after the fact. If you preserve authentication and usage data early, the question of who was an active user on a given date answers itself. If you wait, you are left arguing about identities whose activity records have already aged out, which weakens an otherwise strong position. Preserving the right data during the first week of the audit is therefore part of the defense, not a separate administrative task.

Have an ArcSight finding on the table?

When the metric is named user, the definition is the defense, and the definition is almost always narrower than the audit claims. We reconstruct the effective license position before any vendor script runs, then challenge the finding line by line. To put a defense team between you and the vendor, open a case or download the ArcSight EPS defense briefing.

Get The Number Down →

Related field notes

These notes from the ArcSight and Security audit defense cluster go deeper on the mechanics referenced above, and 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.