Limitation One: Exploitation Against Production Is Not an Acceptable Test Action
The vulnerabilities that matter most on an edge device are unauthenticated code execution flaws in the gateway service or the management plane. Proving one of those is present means running it.
Against a production appliance, that carries real consequences. An attempt can crash the service daemon, drop every active VPN tunnel, corrupt running configuration, trigger an unplanned failover, or write artifacts to disk that are indistinguishable from a genuine compromise when somebody reviews those logs six months later. In the worst case it leaves a web shell behind, because a great many public proof of concept scripts are written to demonstrate access rather than to tidy up afterwards.
There is a second-order risk too. Public exploit code for a high-profile edge CVE appears quickly and its provenance is often unclear. Running an unvetted script of unknown authorship against the device that terminates all of your traffic is not a controlled test, whatever it happens to prove.
So a responsible tester does not do it. The rules of engagement you signed almost certainly prohibit it, and if a vendor offers to prove remote code execution on your production firewall with no agreed window, that tells you something about their risk management rather than their capability.
What you get instead is a finding worded as possibly vulnerable, version unconfirmed. Which leads directly to the second constraint.
Limitation Two: Banner Fingerprinting Does Not Resolve to a Build
If you cannot exploit, the fallback is version fingerprinting. On a modern edge appliance, it mostly fails.
Vendors have deliberately stripped version detail from their internet-facing portals, specifically so that attackers cannot assemble target lists from scan data. That hardening works as intended. It also works just as well against the tester you hired.
In practice we can usually establish that an endpoint is a particular vendor’s gateway. Sometimes we can narrow it to a major release family. We generally cannot establish the maintenance build, and the maintenance build is the whole question. The distance between a vulnerable version and a patched one is frequently a single hotfix release, and nothing visible from the outside separates them.
Version alone is sometimes not even sufficient, because exposure can depend on which features are switched on.
Limitation Three: Scanning Does Not Rescue You Here
The reasonable follow-up is that a vulnerability scanner covers this ground. If that scanner is external and unauthenticated, it does not.
An unauthenticated external scanner performs the same inference as the human tester, with less judgement. It reads the same sparse banners and returns the same potential findings, usually with the caveat buried in the detail rather than in the summary. That produces two failure modes at once: findings nobody can act on, and a silence that reads like safety.
The word that changes everything here is authenticated. A scanner handed read-only credentials to the device is an entirely different proposition, and that is the actual answer.
What Actually Closes the Gap
None of this means your exposure is unknowable. It means probing is the wrong instrument for the job. Three options, in order of cost and disruption:
- A read-only credentialed check of the device. A read-only administrative account, an API token, or an exported support bundle returns the exact build, which then cross-references cleanly against the vendor’s advisories. It takes minutes, carries no availability risk at all, and converts possibly vulnerable into a definite yes or no. For most organisations this single step buys more certainty per pound than anything else in the engagement.
- A configuration review. Version is only half of exposure. A review covers which features are enabled, whether the management interface is reachable from untrusted networks or from the internet at all, how administrative authentication and MFA are enforced, rule base hygiene, certificate handling, and whether logging and telemetry would actually have recorded an intrusion. Several of the most damaging edge CVEs of recent years were exploitable only in particular configurations, which makes your configuration part of your exposure rather than background to it.
What To Put in Your Next Scope
- ✅ Name your edge and infrastructure appliances individually, rather than letting them sit anonymously inside an IP range.
- ✅ Provide read-only credentials, API tokens or support bundles for each one, and have that written into the scope rather than agreed informally.
- ✅ Add a configuration review for anything that terminates untrusted traffic.
Closing Thoughts
An external penetration test answers one real question well: what can somebody reach and break from the internet right now, without touching anything they should not. It does not answer whether your perimeter is current, and it was never structured to.
That gap closes with a read-only credential configuration review. It is a small addition to most engagements.
This is one of two limits worth understanding when you scope infrastructure testing. The other is about coverage rather than depth, and we covered it separately in Internal Infrastructure IP Penetration Testing vs External Only.
