Internal vs external penetration testing

An external penetration test works from the public internet against everything you expose, asking what an unauthenticated stranger can reach and break. An internal test starts from a position inside the network and asks how far that position can be extended — towards domain control, sensitive data, or the systems that matter. Most organisations now need the internal perspective more, because initial access is rarely the hard part any longer.

The two perspectives

The distinction is positional, not a difference in skill or tooling. Both use the same enumeration, exploitation and post-exploitation. What changes is where the tester stands when they begin, and therefore which questions the engagement can answer.

External testing begins with nothing but your name and your public address ranges. The work is discovery before attack: finding the hosts, services, subdomains, forgotten staging environments, management interfaces and third-party-hosted assets that are reachable from the internet — including the ones you did not know were there. Then testing each: unauthenticated flaws, weak or default credentials, exposed administrative functions, unpatched edge devices, misconfigured cloud services, and any path that leads from the public internet to something it should not.

Internal testing begins from an agreed position inside: a network port in an office, a VPN account, a virtual machine on a user subnet, or a standard domain user's workstation. From there the question is reach. What can be enumerated from this position? Which hosts are unpatched, which shares are readable, which service accounts have excessive rights, which credentials can be captured off the wire or harvested from memory, which trust relationships can be abused? The goal is usually expressed as an objective — domain administrator, a specific database, the backup system — because the finding that matters is the path, not the inventory.

External — the perimeter question

  discover public surface → identify reachable services
    → exploit unauthenticated weakness → foothold?
  answers:  can a stranger get in, and what is exposed?
  stops at: the first internal host — or nothing at all

Internal — the containment question

  start from granted foothold → enumerate
    → capture or crack credentials → escalate locally
    → move laterally → abuse trust → objective
  answers:  how bad is one compromised laptop?
  assumes:  the perimeter already failed

Side by side

The case for external testing, on its own terms

External testing answers the only question with an unambiguous, non-negotiable answer: is anything exposed right now that should not be?

Its real value is usually inventory rather than exploitation. The most useful external finding is rarely a clever exploit; it is an asset nobody knew was live — a staging environment never decommissioned, a management interface published during an outage and never withdrawn, a subdomain pointing at a released cloud resource that someone else can claim, a supplier-hosted service bearing your brand. Exposed surface is consistently larger than the records show, and a competent external test produces a verified list rather than an asserted one.

It is also the perspective that maps directly onto the most indiscriminate class of attack. Mass exploitation of internet-facing devices — the VPN concentrator, the file-transfer appliance, the edge firewall — does not select victims by sector or value; it selects them by exposure. Those campaigns begin and end at the perimeter, and an external test is the measurement that fits them.

The limitation is that external testing is, by design, blind beyond the perimeter. A clean external report means a stranger with no credentials found no direct way through on that day. It says nothing about what happens when someone opens an attachment, reuses a password that appears in a credential dump, or approves a push notification they did not expect. Since those are the routes by which most intrusions begin, a perimeter-only programme measures the entry path attackers least depend on.

The case for internal testing, on its own terms

Internal testing measures consequence. Granted a single ordinary foothold, how much of the organisation becomes reachable?

The answer is frequently much worse than expected, and for structural reasons rather than through neglect. Internal networks accumulate: a flat address space that was fine when it was small, service accounts with privileges granted for a project that ended years ago, local administrator passwords shared across a build, legacy authentication protocols left enabled for one appliance, backup systems with credentials to everything, and directory permissions that compose into escalation paths nobody designed. Each item is defensible on its own. Together they frequently form a path from a standard user to full control — which is why our Active Directory assessment work focuses on composed paths rather than on individual misconfigurations.

Internal testing is also the only way to verify segmentation. Network diagrams describe intent. Firewall rules accumulate exceptions, and a VLAN with a permissive rule added for a migration three years ago is functionally not segmented at all. The only reliable way to know whether a boundary holds is to stand on one side and attempt to cross it, which is what an internal test does. Claims about containment that have never been tested should be treated as hypotheses.

The honest limitation is that the foothold is a gift. The test begins where an attacker would have had to do real work, and some of what internal testing finds would require an adversary to first succeed at phishing or credential theft. A severe internal finding is therefore a statement about consequence, not about likelihood — which is exactly why it must be paired with an honest view of how reachable that starting position is.

Assumed breach is now the sensible default

Internal testing has moved from optional to default because the perimeter stopped being the decisive control. Credentials are stolen and sold at scale. Phishing works, including against trained staff, and multi-factor authentication is bypassed by fatigue, relay and token theft often enough to be routine. Contractors, suppliers and unmanaged devices all hold legitimate access, and much of the network is now somebody's home router away.

Assumed breach takes this as a premise rather than a scenario. Instead of spending the engagement establishing whether access is achievable, it is granted at the outset and the whole effort goes into what follows. The practical consequence is that you learn far more per day: in a perimeter-first engagement, most of the time is consumed by discovery and attempted entry, and if entry fails the most consequential questions are never reached.

This is a framing, not a different technique. Assumed breach is internal testing with the reasoning made explicit: the foothold is granted because the question is containment, and pretending otherwise spends budget rediscovering that phishing works.

Which one do you actually need

Start external if any of these are true. You cannot produce a confident list of what you expose to the internet. You have recently migrated to cloud, changed hosting, or completed an acquisition and inherited an estate you do not fully know. You run internet-facing appliances — VPN, remote access, file transfer, email security — which are the devices mass-exploitation campaigns target first. You have never had the perimeter verified by anyone outside your own team. A customer, insurer or auditor requires evidence covering the external surface specifically.

Start internal, on an assumed-breach basis, if any of these are true. Your external surface is already small, well understood and regularly verified. You depend on Active Directory for authentication and authorisation, which means the directory is the real target. You have made segmentation claims — a cardholder environment, a production enclave, an OT boundary — that have never been tested by someone attempting to cross them. You hold concentrated sensitive data and do not know what reaches it from an ordinary user's position. You have had a security incident, a near miss, or a phishing campaign that succeeded. Your staff work remotely on devices that are only partly managed.

If you can only fund one and must choose, the deciding question is which failure would hurt more: being entered, or being unable to contain someone who is already in. For most organisations with a modest, well-maintained external surface and a large flat internal network, the second is the greater exposure — and internal testing is the better first purchase. Both perspectives are in scope for our penetration testing work precisely because the useful answer usually requires reasoning across the join.

The common buyer mistake

The mistake specific to this pairing is running external testing year after year, never testing internally, and reading the clean external reports as evidence of security.

It is an easy pattern to fall into. External testing is simpler to scope, needs no access provisioning and produces a report that reads well. Internal testing requires coordination, access, and a willingness to hear that the directory which runs the company can be taken over from a standard user account. So the external test is repeated, the perimeter genuinely improves, and the interior is never examined.

The result is an organisation with a well-maintained front door and no interior walls — one that is hard to enter and trivial to own once entered. Since the realistic entry routes are phishing and stolen credentials rather than perimeter exploitation, the programme has been optimising the control that matters least while leaving the one that determines the severity of every incident unmeasured.

The inverse mistake is rarer but does occur: commissioning assumed-breach internal work while the external surface remains uninventoried. Containment findings are valuable, but if an unauthenticated management interface is published to the internet, that should have been found first — and it is cheaper to find.

How they fit together over a programme

The two perspectives are halves of one picture, and the value is in joining them rather than in either alone.

Keep the external view current and cheap. Your exposed surface changes whenever anything is deployed, so verify it on a regular cadence and treat the inventory as the primary deliverable. Each external test should become progressively less interesting — the correct outcome, and the signal that effort should move inside.

Make internal testing the depth investment. This is where the time is best spent, because this is where the paths are. Each engagement should produce specific attack paths with named weak links, and remediation should target the links that appear in several paths at once: a service account's privileges, a legacy authentication protocol, a credential reused across a build, a segmentation rule that was never narrowed after a migration.

Then join them. The useful question is whether a weakness at the edge connects to a path inside — whether the externally reachable host is a jumping-off point into the user network rather than an isolated appliance. That needs either one engagement spanning both perspectives, or an internal test whose starting position is informed by the external findings. Procured as two unrelated exercises from two providers, the join is exactly what goes unexamined.

As the programme matures, the natural next step is covert testing. Once attack paths have been broken and containment is credible, red teaming tests whether anyone notices an adversary attempting them — a question neither an internal nor an external test is designed to answer, because both are announced. To see how we document an attack path and its weak links before committing to a scope, get the report.