Most infrastructure penetration test quotes begin with one question: how many IP addresses are in scope? The answer usually comes back as a short list of public addresses. The firewall edge, the mail gateway, the VPN portal, a web server or two, and whatever else the business deliberately chose to publish. That is a legitimate scope, and for some organisations it is the right place to start.
But that answer quietly decides something larger than price. It decides whether your report describes your attack surface, or only the first few metres of it.
This article compares two common infrastructure scopes. The first is external IP testing on its own. The second is external testing combined with internal infrastructure IP testing, where the tester has network reachability from inside but holds no credentials to the target systems. The second option is not simply more of the same work at a higher price. It answers a different set of questions.
What an External-Only Test Actually Proves
External testing is the right opening move because it mirrors the opening move of a real intrusion. Done properly, it gives you solid answers on:
- Exposure inventory. What is genuinely reachable from the internet today, including hosts in cloud ranges that nobody remembers standing up.
- Edge device condition. Patch level and configuration of the appliances that terminate your traffic, which remain one of the most heavily targeted classes of asset in real breaches.
- Authentication exposure. Portals and remote access endpoints, their resistance to credential stuffing, and whether multi-factor enforcement is actually applied rather than merely configured.
- Accidental publication. Management interfaces, staging environments and administrative panels that were never meant to be world-reachable.
That answers a specific and important question: if somebody with no access and no inside knowledge targets us from the internet today, what can they reach and what can they break? No internal test replaces that.
There is a catch, though. The perimeter is also the part of your estate that already receives the most attention. Edge devices get patched first, monitored closely and reviewed often. So a mature organisation’s external report tends to get thinner each year. A thin report then gets read as “we are secure”, which is a misreading of a narrow scope. We covered that failure mode in more depth in Why Penetration Testing Alone Isn’t Enough.
What Stops at the Firewall
An external scope, by definition, cannot evaluate anything it cannot route to. In practice that excludes most of what you own:
- Every host behind NAT. Workstations, file servers, domain controllers, hypervisors, databases, backup systems.
- East-west reachability. Which internal zones can talk to which, and over what ports.
- Segmentation enforcement. Whether the boundaries on your diagram exist in the rule sets.
- Legacy protocol behaviour. Name resolution and broadcast protocols, message signing settings, and IPv6 behaviour on networks that were only ever designed for IPv4.
- Management planes. Hypervisor consoles, out-of-band server controllers, switch and firewall administration, power distribution units, building and facility systems.
- Unauthenticated data services. Caches, search clusters, document stores, file shares and backup repositories that were deployed with no authentication because they were “internal only”.
- Directory and certificate services. Anonymous directory queries, pre-authentication behaviour, and certificate issuance misconfigurations that hand out far more than intended.
- Build and update infrastructure. CI runners, artifact repositories and patch distribution servers, which are a direct route into everything they deploy to.
None of this is exotic. It is the ordinary interior of a working network, and an external test is silent on all of it.
The “No Credentials” Objection, Answered
The most common pushback on internal scope is that an unauthenticated internal test is unrealistic, because nobody starts inside. Two things are worth saying plainly here.
First, attackers do start inside, routinely. A phished user, a contractor laptop, a stolen session on a remote access portal, a vulnerable edge appliance, a compromised managed service provider. The unauthenticated internal position is precisely the position an intruder occupies in the first hour, before they have escalated anything. Testing from there is not a hypothetical, it is the most frequently occupied foothold in modern incidents.
Second, unauthenticated internal is not a weak position. Without a single credential issued to the targets, this scope regularly surfaces anonymous share and directory enumeration, vendor default credentials still live on management interfaces, data services with authentication disabled, relay and name resolution abuse paths, multifunction devices that give up stored directory credentials, and monitoring agents with secrets sitting in readable configuration. Those are the first links in most real chains.
Keeping the targets unauthenticated also keeps scoping clean. There is no account provisioning delay, no access review paperwork, and no argument about which role the tester should have been given. You get reachability and nothing else, which is exactly what an attacker gets at the start.
Worth noting that this is a different axis from the one we discussed in Black Box vs Grey Box Penetration Testing. That comparison is about how much the tester knows. This one is about where the tester stands.
Three Things Only Internal Coverage Can Validate
1. Segmentation As Built, Not As Drawn
Network diagrams age badly. Firewall rule sets accumulate temporary exceptions that long outlive the project that needed them, and the person who added them. Internal testing turns that uncertainty into a factual reachability matrix. From the guest network, what can be reached in the server estate? From a standard user subnet, can the backup network be touched? Is the cardholder, clinical or operational technology environment genuinely isolated, or merely labelled as isolated?
Either the rules hold or they do not. This is cheap to prove from inside and impossible to prove from outside.
2. Lateral Movement and Blast Radius
External testing answers “can they get in”. Internal testing answers “what happens next”, and that second answer is what determines whether an incident is a bad week or an existential event. How many steps separate one compromised laptop from administrative control of the directory? How many hops from a general user segment to the system holding your backups? Does one flat subnet put workstations alongside hypervisor management?
Blast radius is the number that actually drives your recovery cost, your notification obligations and your insurance conversation. You cannot measure it from the outside.
3. Internally Exposed Services Nobody Meant to Publish
Every estate carries things that were built for a sprint and never retired. An internal dashboard with authentication switched off. A staging database holding a copy of production data. A file share opened up “temporarily” two years ago. A build server with anonymous read access. A monitoring stack with plaintext credentials in its configuration.
None of these appear in an external report, because none of them were ever meant to face the internet. They face everybody who is already inside, which after the first phishing success includes the attacker.
Side by Side
| External IP Only | External + Internal IP (Unauthenticated) | |
|---|---|---|
| Attacker modelled | Opportunistic internet-based actor with no access | The same, plus an actor who has just gained a foothold |
| Core question answered | Can they get in? | Can they get in, and how far do they get? |
| Estate covered | Published services only, typically a small fraction of hosts | Published services plus the internal ranges where most assets live |
| Segmentation evidence | None | Tested reachability matrix between defined zones |
| Blast radius insight | None | Demonstrated paths and reachable high-value systems |
| Client effort | Provide an IP list | Provide an IP list and internal network reachability, no target accounts needed |
| Best used for | First engagement, perimeter assurance, smallest footprint | Risk-driven programmes, segmentation assurance, incident readiness |
The Compliance Layer
Risk should drive this decision, but compliance increasingly makes it for you. PCI DSS version 4 expects internal penetration testing and external penetration testing as separate annual requirements, and adds explicit testing of segmentation controls where segmentation is used to reduce scope, at a higher frequency for service providers. We broke that down in What Should Be in Scope for Your PCI DSS Penetration Test.
SOC 2 and ISO 27001 do not prescribe a scope, so an external-only test is often accepted at first. That tends to hold until an auditor, or an enterprise customer’s security questionnaire, asks which internal ranges were covered and what the segmentation evidence was. The proposed 2025 updates to the HIPAA Security Rule would also move annual penetration testing from good practice to an explicit obligation, which we covered in NPRM (HIPAA) 2025.
Scoping Internal Coverage
A few practical rules:
- ✅ Start with breadth over depth. Reachability and unauthenticated exposure across the estate beats exhaustive depth on a handful of hosts.
- ✅ Define internal starting positions that mirror plausible footholds, such as a standard user segment, the guest network, and one server segment.
- ✅ Supply an honest internal range inventory, including the ranges that get forgotten: out-of-band management, disaster recovery sites, lab and test networks.
If your longer-term direction is a Zero Trust architecture, internal testing is also the measurement tool for it. Reducing implicit trust between internal zones is only meaningful if somebody verifies that the trust is actually gone.
Closing Thoughts
External-only testing is not wrong. It is partial. It describes the door in detail and says nothing about the building. If your current report tells you the perimeter held and tells you nothing about what sits behind it, you are not measuring your exposure, you are measuring your front wall.
