38,988 FortiGate and 22,586 Palo Alto Assets: Using Perimeter Counts to Challenge Firewall Inventory

Firewalls are the infrastructure most likely to be documented and least likely to be re-verified. They appear in architecture diagrams, in change records and in network inventories, and their existence is rarely questioned.

That makes perimeter exposure counts a useful audit input, not because they identify risk, but because they identify disagreement between what an organization believes and what the internet sees.

The measurements

On 20 October 2026, between 22:33 and 22:37 UTC, ZoomEye queries with sub_type="all" and a page size of one record returned:

The firewall counts are an order of magnitude below the load-balancer and ADC counts, and two orders below the F5 total. That does not mean firewalls are less exposed; it means product fingerprinting behaves differently for them.

Why firewall counts are systematically low

A firewall's defining function is to terminate traffic it does not want. Its management interface is the part that reveals a product identity, and a well-run deployment restricts that interface to an administrative segment.

So the observed population is, roughly, firewalls whose fingerprint was captured from a reachable management plane or from an exposed user portal. Both are configuration outcomes.

An estate of 200 firewalls with management interfaces correctly restricted may contribute zero observable assets. An estate of 20 with one misconfigured device contributes one. The count measures configuration discipline in the observable population, not deployment volume.

That inverts the usual reading. A low count for a widely deployed product class is consistent with good practice at scale, and a sudden increase for a specific organization is a finding.

The comparison that matters internally

For a defender, the useful operation is not comparing FortiGate to Palo Alto. It is comparing your asset records to the observed set on your own address space.

A workable procedure:

1. Query the product fingerprints for every firewall vendor in your estate.
2. Restrict results to your allocated address space, or to the cloud providers and regions you use.
3. Diff against the firewall inventory, including devices managed by regional teams or acquired through mergers.
4. For each observed device not in the inventory, determine whether it is yours and who administers it.
5. Repeat quarterly with identical queries so that new appearances surface as changes.

The value in step four is the discovery of a management interface reachable from the internet that nobody claims. That single finding justifies the exercise.

vCenter as a contrasting case

VMware vCenter at 27,288 globally, with 5,816 in the United States, sits in a different category. A vCenter management interface is rarely deployed with the same perimeter discipline as a firewall, and it is a high-value target because it controls virtualization.

vCenter has been the subject of repeated exploitation over several years, which makes its observed population more directly relevant than a firewall count. An exposed vCenter is a management plane that was not placed behind a restricted path.

The contrast is instructive: for firewalls, exposure counts understate deployment; for virtualization management, they tend to overstate risk relative to the same number because the exposed interface is more consequential.

What to do with a number you cannot fully trust

Counts from external observation are best used as a diffing mechanism and worst used as a risk score.

For firewall estates, the practical value is validating that no management interface is reachable from the internet. That is a binary property, checkable per device, and it is the configuration decision that determines whether any firewall CVE matters.

For the CVE-2026-0322 class of management-plane code injection, that single property — whether the interface answers on a public address — is a better predictor of risk than the version number, because an unpatched device behind a restricted interface has no reachable attack path.

References

• ZoomEye, search interface, queried 20 October 2026 for the dorks listed above.
• Palo Alto Networks, advisory for CVE-2026-0322.
• CISA, Known Exploited Vulnerabilities Catalog.