ArcSight identity views and named user definitions

Who counts as a user is one of the most consequential definitions in an ArcSight finding. ArcSight identity views and named user definitions decide whether service accounts, dormant logins, and shared roles are priced as licensed consumers, and a finding inflates when every identity in a directory view is treated as a billable user.

Where an ArcSight component is licensed by named user or by identity, the count depends on a definition, and the definition is rarely as broad as the audit reads it. Identity views assembled from directory data capture every account that exists, including service accounts, automation identities, disabled logins, and shared functional roles. Treating all of them as licensed users produces a figure that reflects the directory, not the licensed consumption the metric was meant to measure.

What a named user actually is under the agreement

The threshold question is the definition itself. A named user metric is governed by the entitlement and the Additional License Authorizations, and the definition there determines what counts. A human individual who uses the product is one thing. A service account that exists to run an integration is another. A disabled or dormant login that has not authenticated in the measurement window is a third. A finding that collapses these into a single headcount is applying the broadest possible reading rather than the authorized one, and the gap between the two is the argument.

The identity categories that inflate the count

• Service and automation accounts. Non human identities that exist to run integrations and scheduled tasks, not to consume the product as a user.
• Dormant and disabled logins. Accounts that have not authenticated in the measurement window and represent no active consumption.
• Shared and functional roles. A single role used by a team can be read as one licensed user or as many, depending on the definition.
• Duplicates across views. The same individual appearing in multiple identity views or directories, counted more than once.

Resolve the view into a licensed set

The correction is to resolve the raw identity view into the set the metric actually licenses. That means tagging each identity as human or service, active or dormant, distinct or duplicate, and mapping shared roles to the definition the agreement uses. The evidence for this lives in authentication logs and directory metadata that the buyer controls, which is why the buyer is the right party to build the resolved set rather than accept the view at face value. This mirrors the consumer counting discipline applied across the ArcSight platform, where the question is always who or what is actually consuming, not who or what merely exists in a record.

Reconstruct before the count is taken

During the seven day notice window, take over the channel and avoid handing over a raw directory export as the basis for a user count. A reconstruction that has already resolved service accounts, dormant logins, and shared roles means the licensed set is the figure on the table, and the inflated directory view never becomes the baseline. The four Rs apply: respond, reconstruct the effective position, rebut the definition line by line, resolve on terms that convert forward with a defined user metric.

A recent engagement

In a recent engagement an identity based line had been priced from a directory view that included thousands of service accounts and disabled logins alongside active human users. Resolving the view, removing non human and dormant identities, and collapsing duplicates brought the count to the licensed set the metric defined. The reduction came not from negotiation but from holding the finding to its own definition, the same way the consumer count was corrected in the broader ArcSight matters this practice has defended.

Settle the definition first

Read the named user definition in the entitlement and the ALAs, resolve the identity view into human, active, distinct users, and remove everything the definition excludes. A user count handled in that order stops being a directory total and becomes a defensible figure tied to authenticated consumption.

Why directory views overstate so reliably

A directory is built to remember, not to meter. It retains accounts long after the people behind them have left, keeps service identities created for projects that ended, and accumulates functional roles that were stood up for a single integration and never removed. When an audit assembles an identity view from that directory, it inherits all of that history and presents it as a current user population. The overstatement is not occasional, it is structural, because the directory and the license metric are measuring different things. The directory measures everything that has ever needed a record. The metric measures who actually consumes the product. The work of the defense is to translate from the first into the second, and the translation almost always shrinks the number.

Authentication evidence carries the argument

The most persuasive evidence in a named user dispute is authentication activity, because it speaks directly to consumption. An account that has not authenticated across the measurement window is not using the product in any meaningful sense, whatever its status in the directory. Authentication logs let the buyer separate the genuinely active population from the dormant remainder, and they do it with the buyer own data, which the vendor cannot easily contradict. Combined with metadata that flags service and automation accounts and maps shared roles to the metric definition, authentication evidence turns a contested headcount into a documented set. As with throughput evidence on the volume side, the buyer holds the record that settles the question, and bringing it to the table early keeps the inflated directory view from ever becoming the baseline. The resolved set is also worth preserving for the forward agreement, so the named user metric is defined once and the next measurement starts from a settled population rather than from a fresh, unfiltered directory export that would reintroduce every service account and dormant login the defense already removed.

Related field notes

These notes from the ArcSight and Security audit defense cluster cover user and identity counting. Each links back to the complete OpenText audit defense playbook for 2026.

• ArcSight identity user definitions and consumer counts
• NetIQ identity and access license counting traps
• NetIQ Identity Manager metric definitions
• how OpenText measures ArcSight in a self assessment
• reconciling ArcSight entitlements before an audit

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.