NetIQ identity and access license counting traps

When an OpenText audit reaches the NetIQ identity and access portfolio, the dispute is rarely about whether you run identity governance. It is about how the vendor counts the people, accounts, and identities that flow through it. NetIQ identity and access license counting is one of the quietest places a finding inflates, because the numbers come from directories that were never designed to feed a licensing meter.

NetIQ Identity Manager, NetIQ Access Manager, and the surrounding identity and access management products are typically licensed against a unit that sounds simple and behaves anything but: the managed user, the named identity, or the connected system. The trouble is that an identity store is a living thing. It accumulates service accounts, test identities, contractor records that were never deactivated, duplicate entries from migrations, and system principals that no human ever logs in as. An audit that counts every object in the directory as a licensable identity will produce a number far larger than the population the agreement was meant to cover, and that gap, priced at list and grossed up with back maintenance, is where a NetIQ finding overreaches.

What NetIQ actually meters, and where the definition slips

The first task in any NetIQ engagement is to pin the contractual unit. Across the NetIQ line the metric may be a managed user, an active user, a named user, or a connected application or system. Each of those definitions excludes things the audit script tends to include. A managed user is generally a real person whose identity is provisioned and governed, not a service account that exists only so a process can authenticate. A named user is a specific individual, not every row in an identity vault. Where the agreement is silent or ambiguous, the vendor measurement defaults to the broadest possible reading, and the broadest reading is always the most expensive one.

This is the same pattern we see across the security estate, and it is why we treat identity counting the same way we treat ArcSight identity user definitions and consumer counts: the word in the contract governs, not the row count in the directory.

The accounts that should never count

When we reconstruct a NetIQ position, several categories come out of the number almost every time. Service and system accounts authenticate processes, not people, and are not managed human identities. Disabled or deprovisioned records are residue from staff who have left and should not be billed as active. Duplicate identities created during directory consolidations inflate the raw count without adding a real user. Non production and test identities used to validate workflows are not production governed users. And generic or shared accounts represent a function, not a person under the named user definition.

Each of these is defensible on the language of the agreement, but only if someone separates them before the vendor fixes its number. That separation is the substance of the rebuttal.

How the four operations apply to a NetIQ finding

Our method runs the same four operations here as everywhere. We respond first, taking over first contact during the seven day notice window so no directory export reaches the vendor unmanaged. We reconstruct the effective identity position from your own directory and provisioning data, classifying every object against the contractual unit rather than accepting a raw count. We rebut by disqualifying service accounts, dormant records, duplicates, and non production identities line by line. We resolve on a number that reflects governed human identities, then convert forward with the metric defined cleanly so the next audit cannot reopen the same argument.

Why the directory export is the riskiest moment

The single most consequential decision in a NetIQ audit is what you hand over and when. A raw LDAP or identity vault export, delivered without classification, lets the vendor count on its own terms. Once a number is in the report it is much harder to dislodge than it would have been to scope correctly at the outset. This is why we insist on a single controlled channel and on reconstructing the position before any export leaves the building. The grounding principle of an OpenText audit is that compliance is treated as the licensee's responsibility, which cuts both ways: it is also the licensee's right to present the data in the form the contract describes.

A representative pattern

In a recent engagement across a security and identity estate, the opening finding leaned heavily on a directory object count that bundled tens of thousands of non human and dormant records into the managed user figure. Reconstructing the governed population against the contractual definition removed the overcount well before any settlement discussion, and the conversation shifted from a headline number to a defensible one. The pattern mirrors our anonymised banking matter, case file E-03, where an ArcSight finding of $6.0M settled at $1.8M, a 70 percent reduction, once the measurement basis was corrected rather than negotiated.

The questions that decide a NetIQ counting dispute

Four questions usually settle a NetIQ identity and access finding, and they are worth asking the moment the report arrives.

• What is the licensed unit? Managed user, active user, named user, or connected system, and how does the agreement define it.
• What is in the count that is not a person? Service accounts, system principals, and shared accounts are the first to come out.
• What is in the count that is no longer active? Disabled and deprovisioned records should not be billed as governed identities.
• What is duplicated? Migrations and consolidations leave residue that inflates the raw number without adding a user.

Answering those with your own provisioning data, not the vendor's export, is how a NetIQ number comes down to the population the contract actually covers.

How the remedy stacks on a NetIQ overcount

The reason a NetIQ counting error is worth the work to correct is that the remedy does not stop at the licence price. Under the OpenText approach, a shortfall is deemed to have been acquired at the then current list price, the licensee owes back maintenance and support on those licences, a first year of maintenance is added on the newly deemed licences, and the costs OpenText incurs performing the audit are reimbursed. A single inflated identity count therefore becomes several stacked charges, and every phantom identity removed from the base reduces all of them at once. This is why we treat the count itself as the centre of gravity in a NetIQ defense: correcting the population is far more valuable than negotiating a discount on a population that was never licensable.

It also explains why the vendor measurement tends toward the broadest reading. A larger base is not a rounding error in the vendor's favour; it is a multiplier across list price, back support, and forward maintenance. The discipline of classifying every object before any export leaves the building is the single most effective lever a buyer has, because it attacks the base that every other charge is built on.

Related field notes

These notes from the ArcSight and Security cluster go deeper on the identity and metric questions above. Each links back to the complete OpenText audit defense playbook for 2026.

• NetIQ Identity Manager metric definitions
• ArcSight identity user definitions and consumer counts
• NetIQ and Sentinel collector and connector counting
• 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.