Fortify token based and floating license models

Not every Fortify entitlement is a fixed list of named people. Many estates run on shared models, where a pool of licenses floats across a larger user base, or where consumption is metered through tokens drawn down as work is performed. These models exist precisely because scanning is bursty and shared, but they create a measurement problem in an audit: the vendor count may treat every account that ever touched the pool as a permanent seat, ignoring the shared and metered nature of the entitlement. Understanding Fortify token based and floating license models is essential to defending a finding that was built as though every license were a fixed named seat.

This article explains how floating and token models work, how an audit can misread them, and how a buyer reconstructs the position to match the model it actually bought. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

What floating and token models are

A floating model licenses a number of simultaneous users rather than a list of individuals. A pool of licenses is shared across a larger population, and only the people scanning at the same moment draw on it. The unit is concurrency, not headcount, which is the same distinction we set out in Fortify named user versus concurrent user definitions. A token model meters consumption: each scan or unit of work draws down tokens from a balance, and the entitlement is the volume of tokens, not the number of people who might spend them. Both models decouple the license count from the size of the user base, which is exactly why estates choose them.

How an audit misreads a shared model

The recurring error is to apply a named user logic to a model that was never sold that way. Under a floating entitlement, an audit may enumerate every account that ever connected and propose that total as the seat figure, when the entitlement licensed only peak concurrency. Under a token model, an audit may count users or scans as seats rather than reconciling token consumption against the purchased balance. In both cases the vendor count inflates by treating potential access as fixed entitlement, the same root error we describe in can OpenText count repository readers as Fortify users.

Counting against the right unit

The defensible figure depends entirely on what the entitlement licenses. For a floating model, the measure is peak simultaneous use during the review period, which the license server and the Software Security Center session records establish. The total population that connected over a year is irrelevant; what matters is the maximum number scanning at once. For a token model, the measure is total token consumption against the purchased balance, again drawn from the consumption records. Reading the model first prevents the buyer from accepting a headcount that the contract never required, and it is the reason the entitlement reconstruction comes before any measurement, as we set out in reconciling Fortify entitlements before an audit.

Reconstructing a floating or token position

The buyer rebuilds the position from its own records before any vendor measurement script runs. For a floating entitlement, the session and connection logs are analyzed to find peak concurrency, not cumulative access. For a token entitlement, the consumption records are totaled and compared to the balance purchased. In both cases the automation and service identities that drive scanning are isolated rather than counted as users, the same discipline we apply in CI pipeline service accounts counted as Fortify seats, and the scan record is attributed to real contributors using the method in reducing a Fortify finding with commit and scan evidence.

A representative outcome

In a recent engagement, a Fortify finding applied a named user count to an estate licensed on a floating model, enumerating every account that had ever connected to the pool and proposing that cumulative total as the seat figure. By establishing peak concurrency from the session records rather than cumulative access, and by isolating the automation identities that drove much of the connection volume, the buyer rebuilt the count against the unit the entitlement actually licensed. The defensible figure was a fraction of the cumulative headcount, and the finding settled well below its opening position, consistent with the reductions we see across Fortify matters and with our E-02 case file, where a developer seat overclaim of $4.5M settled at $0.9M.

Holding the model distinction

The discipline on a shared entitlement is to insist that the count match the model. A floating license measures concurrency, a token license measures consumption, and neither measures the size of the population with access. Each misreading is correctable from the license server and consumption records the estate already keeps, and each correction moves the finding toward the figure the entitlement supports. For the broader measurement context, see how OpenText measures Fortify usage in an audit, and for the perpetual and term framing that often sits alongside these models, see Fortify perpetual versus term license positions.

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