Fortify Software Security Center user counting traps

Fortify Software Security Center, the management hub that aggregates scan results and tracks findings across an application portfolio, sits at the center of most Fortify audit findings. It is where the vendor goes to count users, and it is also where the count most often inflates. The platform records every account that has ever touched the console, and a measurement that reads that record as a list of licensed seats produces a figure far larger than the population the entitlement actually governs. The Fortify Software Security Center user counting traps are predictable, and once a buyer understands them the corrected figure follows from the records the buyer already holds.

This article walks through how user counts inside Software Security Center inflate a finding, which account types should never enter the licensed total, and how to reconstruct a defensible number. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

Why the console record overstates the seat count

Software Security Center is built to give an organization visibility into its application security posture. That goal pushes administrators to create accounts liberally: auditors, managers, compliance reviewers, and read only stakeholders all receive console access so they can see dashboards and reports. None of that is a problem operationally, but it becomes a problem when an audit treats every account in the directory as a chargeable seat. The licensed unit for Fortify is tied to the people who actually consume the analysis capability, not to everyone who can log in and look at a chart. A finding that counts the full account directory is counting access, and access is not the metric.

The account types that should not be counted

A defensible reconstruction begins by classifying every account in the console rather than accepting a flat total. Several categories routinely appear in the vendor figure that should not survive examination:

• Service and integration accounts. Accounts created for automation, build integration, or system to system connection are not human seats. They appear in the directory but represent machinery, not consumers, a distinction we develop in CI pipeline service accounts counted as Fortify seats.
• Dormant and disabled accounts. Accounts that have not authenticated within the measured window, or that were disabled but never deleted, are not active users. A directory that retains historical accounts inflates the count unless the dormant entries are removed.
• Read only viewers. Stakeholders who only view dashboards and reports may fall outside the licensed unit depending on the entitlement, a question of role that we treat in Fortify SSC role based access and consumer counts.
• Duplicate accounts. The same person frequently holds more than one account across directory changes, reorganizations, or migrations. Each duplicate adds to a raw headcount that double counts a single user.

How role based access changes the count

Software Security Center assigns roles, and roles matter to the metric. An administrator, a developer who reviews and remediates findings, and a stakeholder who only reads a summary are not equivalent consumers of the licensed capability. The entitlement governs a specific kind of use, and a defensible count maps each account to its role and then includes only those roles the license actually charges for. A finding that flattens every role into a single chargeable category ignores the structure the platform itself records, and that structure is the buyer's strongest evidence. The console knows who scans, who remediates, and who only views, and the buyer is entitled to be measured against that distinction rather than against a flat directory export.

Reconstructing the defensible figure

The reconstruction follows the same discipline as every Fortify line: build the position from the buyer's own records before any vendor measurement script runs. From Software Security Center the buyer exports the account directory with role assignments and last authentication dates, then classifies each account, removes service accounts, dormant entries, and duplicates, and maps the remainder to the roles the entitlement covers. The result is a count of active, licensed consumers rather than a count of everyone who has ever held a login. This work sits inside the broader exercise of reconciling Fortify entitlements before an audit, and it converts a directory total into a metric based figure the buyer can defend line by line.

A representative outcome

In a recent engagement, a finding read the full Software Security Center account directory as the licensed seat count and priced every login as a developer seat. By exporting the directory with roles and authentication dates, the buyer separated service accounts and dormant logins from active users, removed duplicates created across a directory migration, and mapped the remainder to the roles the entitlement actually covered. The active consumer population was a fraction of the raw account total, and the seat portion of the finding settled well below its opening figure. The path mirrored our E-02 case file, where a Fortify developer seat overclaim of $4.5M settled at $0.9M, an 80 percent reduction, once actual usage replaced an access based count.

Holding the line on the metric

The defense of a Software Security Center user count comes down to refusing to equate access with entitlement. An account is not a seat, a viewer is not a scanner, and a dormant login is not an active consumer. Each of these conflations is correctable from records the platform itself maintains, and each correction brings the number down toward the figure the entitlement supports. For the wider measurement context, see how OpenText measures Fortify usage in an audit, and for the line by line method, see defending a Fortify developer seat finding line by line.

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