Decommissioned Fortify projects still on the audit

A Fortify estate accumulates history. Applications are retired, teams disband, and projects move out of active development, but the Software Security Center keeps the record of everything that was ever scanned. When an audit reads that historical record as a snapshot of current usage, retired work gets counted as live demand. Decommissioned Fortify projects still on the audit are one of the most common sources of an inflated seat baseline, because the project list looks authoritative even when much of it describes work that no longer happens.

This article explains how dead projects survive on a finding, why they overstate the count, and how a buyer removes them with evidence rather than assertion. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

How retired projects stay on the count

The Software Security Center retains projects, scan results, and the accounts associated with them long after a project stops producing new code. Nothing in the tool forces a retired project to disappear, and most organizations never prune it, because the historical results have audit and remediation value of their own. An audit measurement that enumerates every project and every associated account treats this archive as a current inventory. The result is a count that includes applications no longer in development and developers no longer working on them.

Why dead projects overstate the seat figure

Retired work inflates the count in two distinct ways. First, the projects themselves can be counted as active deployments when they are dormant. Second, and more costly, the developer accounts attached to those projects are counted as live seats even though those people have stopped submitting scans, moved to other work, or left the organization entirely. This is the dormant account problem that runs through every Fortify finding, related to the issues we set out in how to challenge a Fortify repository access headcount and in Fortify Software Security Center user counting traps. The seat metric licenses active use, not the residue of work that has ended.

The review period is the dividing line

The clean way to separate live usage from history is to fix a review period and test every project and account against it. A project with no scan activity in the period is decommissioned for the purpose of the count. An account that submitted no scans in the period is not a current seat, whatever projects it remains attached to. This temporal test is objective, it is drawn from the tool's own records, and it does not depend on the vendor's willingness to accept a narrative. The scan history that supports it is the same evidence base we use in reducing a Fortify finding with commit and scan evidence.

Removing retired work with evidence

The buyer rebuilds the count from what the tools actually did in the review period rather than from the full project list. The work proceeds in a defined order:

• Mark projects with no recent scans as decommissioned. The scan timestamps in the Security Center establish which projects are live and which are archival.
• Remove accounts tied only to dead projects. A developer whose only association is with retired work is not a current seat.
• Remove dormant and departed accounts. People who have left or stopped scanning should not appear in a live count, a point connected to documenting Fortify active developers for a rebuttal.
• Recount the survivors under the applicable metric. What remains is the active developer population, counted as named or concurrent users per the entitlement.

Anchoring to the entitlement

The pruned count is read against the buyer's effective license position, reconstructed from purchase records before any vendor measurement script runs. That reconstruction, the subject of reconciling Fortify entitlements before an audit, ensures the corrected figure is compared to a known entitlement rather than to a vendor assumption, and it gives the removal of retired projects a defensible baseline to land against.

A representative outcome

In a recent engagement, a Fortify finding enumerated every project in the Security Center, including a long tail of applications that had not been scanned in over a year, and counted the developer accounts attached to them as live seats. By fixing a review period, marking the unscanned projects as decommissioned, and removing the accounts tied only to that retired work, the buyer rebuilt the count around current scanning activity. The corrected population was well below the claimed figure, and the finding settled far under its opening number, 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, an eighty percent reduction.

Holding the line on history

The discipline is to treat the Security Center as the archive it is and to count only what happened in the review period. A retired project is not a current deployment, and a dormant account is not a current seat. Both are correctable from the tool's own scan timestamps, and both corrections move 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 line by line discipline, see defending a Fortify developer seat finding line by line.

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