Fortify named user versus concurrent user definitions

Two entitlements can authorize the same number of people to use Fortify and produce very different audit findings, because the unit each one counts is not the same. A named user license counts the distinct individuals authorized to use the software; a concurrent user license counts how many people use it at the same time. When a finding applies the wrong definition, or quietly counts a concurrent entitlement as though every distinct login were a named seat, the number inflates without any change in actual usage. Getting Fortify named user versus concurrent user definitions right is a prerequisite to any defensible seat count.

This article explains the difference between the two metrics, why it matters to a Fortify finding, and how a buyer confirms which definition the entitlement actually uses. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

What each definition counts

A named user metric assigns the license to specific individuals. The count is the number of distinct people authorized, regardless of when or whether they all use the tool simultaneously. A concurrent user metric, by contrast, governs simultaneous use: the count is the maximum number of people using the software at the same moment, and the total population of people who might use it can be much larger than the concurrent limit. The same workforce, measured under the two definitions, yields a named figure equal to the headcount and a concurrent figure equal to the peak simultaneous load, which is typically far lower. A finding that reports a concurrent entitlement at a named user count overstates exposure substantially.

Why the distinction drives the finding

The gap between the two metrics is largest exactly where Fortify is used the way most organizations use it: a broad pool of developers who each interact with the analysis tools occasionally, with only a fraction active at any one time. Under a concurrent definition, that pattern produces a small peak count. Under a named definition applied to the same pool, every developer who ever logged in is a seat. A finding that measures a concurrent entitlement by counting distinct logins is not measuring concurrency at all; it is importing named user logic into a metric that does not use it. This is closely related to the access versus consumption problem we develop in Fortify Software Security Center user counting traps, because both turn on what the entitlement actually charges for.

Confirming which definition applies

The controlling question is what the entitlement says, and the answer lives in the order documents and the Additional License Authorizations rather than in the audit's measurement. The buyer reads the entitlement to establish whether each Fortify license is named or concurrent, then measures usage under that definition and no other. Where the entitlement is concurrent, the buyer measures peak simultaneous use from session and authentication records; where it is named, the buyer counts distinct authorized individuals and removes everything that is not a person, such as the service accounts described in CI pipeline service accounts counted as Fortify seats. Reading the entitlement correctly is part of reconciling Fortify entitlements before an audit.

Measuring concurrency from the records

When the entitlement is concurrent, the defensible figure comes from the timeline rather than the directory. Session logs and authentication records show how many users were active simultaneously across the measured window, and the peak of that curve is the number the metric governs. A flat count of everyone who logged in at some point during the window measures something the concurrent metric never asks about. Reconstructing the concurrency curve from the records, and presenting the genuine peak, replaces an inflated distinct count with the figure the entitlement specifies. This is the same evidentiary discipline described in defending a Fortify developer seat finding line by line.

A representative outcome

In a recent engagement, a finding measured a Fortify entitlement that was concurrent in its terms as though it were named, counting every distinct login across the window as a seat. By reading the entitlement to confirm the concurrent definition and reconstructing the concurrency curve from session records, the buyer showed that peak simultaneous use was a small fraction of the distinct login total. The corrected figure reflected the metric the contract actually used, and the finding settled well below its opening number, consistent with the reductions we see across Fortify matters and with the path our E-02 case file followed, where a developer seat overclaim of $4.5M settled at $0.9M.

Holding the metric the contract specifies

The discipline is to measure each Fortify license under its own definition. A concurrent entitlement is measured by peak simultaneous use, a named entitlement by distinct authorized individuals, and neither is measured by the definition that happens to produce the larger figure. The entitlement decides the metric, and the buyer is entitled to be measured by it. For the broader measurement context, see how OpenText measures Fortify usage in an audit.

For the seat counting methodology in full, read the Fortify seat counting white paper.