Fortify ScanCentral controller and sensor licensing

ScanCentral is the component that lets a Fortify estate offload analysis from developer machines onto dedicated infrastructure. A controller coordinates the work and a pool of sensors performs the scans. The architecture is built for scale, but it introduces a question that an audit measurement tends to answer in the vendor's favor: are the controller and the sensors licensed seats, or are they shared machinery serving a defined developer population? Getting Fortify ScanCentral controller and sensor licensing right is central to keeping a finding anchored to people rather than to nodes.

This article explains what the controller and sensors do, how an audit can misread them as seats, and how a buyer licenses and defends a ScanCentral deployment. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

What the controller and sensors actually do

The controller is a coordination point. It receives scan requests, queues them, and dispatches them to available sensors. The sensors are worker machines that carry out the static analysis and return results. Neither component is a person. A developer who submits a scan never logs into a sensor; the sensor simply executes work on that developer's behalf and hands the output back through the controller. The population that matters for the seat metric is the developers whose code passes through this pipeline, not the machines that process it.

How an audit misreads the deployment

Because ScanCentral concentrates a great deal of scanning activity into a small number of machines and service identities, an audit measurement that expects usage to map to people gets confused. Three misreadings recur. The first treats each sensor as a seat, multiplying the count by the size of the worker pool. The second reads the very high scan volume that a sensor pool produces as evidence of a large user base, a problem we develop in Fortify burst scanning and capacity definitions. The third counts the service accounts that the controller and sensors use to communicate as though they were named users, the same conflation set out in CI pipeline service accounts counted as Fortify seats.

Licensing the pipeline correctly

The defensible position separates three things the audit tends to merge. The infrastructure, meaning the controller and the sensor pool, is licensed according to its own terms where applicable, not as a seat per machine. The automation identities that move work through the pipeline are set aside, because they act for many people rather than as individuals. The developer population, the people whose code the pipeline analyzes, is counted under the applicable metric. This is the broader scan farm question applied to ScanCentral specifically, treated in Fortify scan farm and build server license questions.

The metric itself matters here. Whether the entitlement is expressed in named users, concurrent users, or another unit determines how the served population is counted, a distinction we set out in Fortify named user versus concurrent user definitions. Reading the entitlement first prevents the buyer from accepting a per sensor count that the contract never required.

Reconstructing the ScanCentral topology

As with every Fortify line, the buyer rebuilds the position from its own records before any vendor measurement script runs. The deployment topology is documented so that the controller and sensors are identified as infrastructure, the service identities they use are isolated, and the scan history is attributed back to the contributors whose commits triggered the work. The Software Security Center holds the record of which accounts submitted scans, and the build systems record what set them off, so the served population can be established from evidence rather than from a machine inventory. This attribution is the method described in reducing a Fortify finding with commit and scan evidence, and it is part of reconciling Fortify entitlements before an audit.

A representative outcome

In a recent engagement, a finding counted every sensor in a ScanCentral pool as a developer seat and added the controller as a further seat, then cited the pool's aggregate scan volume as confirmation of a large user community. By documenting the topology, identifying the controller and sensors as shared infrastructure, isolating the service identities that drove the pipeline, and attributing scans to the contributors who triggered them, the buyer rebuilt the count around the developers the pipeline actually served. The corrected figure was far below the claimed seat number, and the finding settled well under 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 infrastructure distinction

The discipline on a ScanCentral deployment is to refuse the equation of machine to seat. A sensor performs work; it is not a user. A controller dispatches work; it is not a user. Scan volume measures throughput, not headcount. Each of these conflations is correctable from records the deployment already produces, and each correction moves the finding 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 full seat counting methodology, read the Fortify seat counting white paper.