Network penetration testing is an authorized, simulated attack on the hosts, services and network controls an organization runs. It proves which weaknesses give an attacker access and how far that access spreads.
External tests start from the internet and target what is exposed. Internal tests start inside the network and show what an attacker or a compromised account could reach next.
What CodeAnt AI solves here: CodeAnt AI tests the domains and assets you agree on from the outside, out of the box. Internal, cloud or code access is added only for the assessments you authorize.
The table compares the two halves of a network test before the detail.
Dimension | External network pentest | Internal network pentest |
|---|---|---|
Starting point | The public internet, no credentials | A foothold inside the network, often a standard user or device |
Attacker it models | An outsider looking for a way in | A compromised laptop, a malicious insider, or an attacker who already got through |
Typical targets | Internet-facing hosts, VPN and remote access gateways, exposed admin panels, mail and DNS | Directory services, file shares, databases, internal web apps, management interfaces |
Business question | Can someone get in? | Once in, how far can they go? |
What you provide | Agreed domains, IP ranges and assets | Network access, such as a VPN account or a test device, plus a test user |
PCI DSS v4.0 requirement | 11.4.3 | 11.4.2 |
A complete program needs both. Per NIST SP 800-115, when both are performed, “the external testing usually takes place first.”
Is this true for your network? A free CodeAnt external scan shows what an attacker reaches from outside, with evidence.
What Is Network Penetration Testing
NIST defines penetration testing as “security testing in which assessors mimic real-world attacks to identify methods for circumventing the security features of an application, system, or network.”
Network penetration testing applies that definition to infrastructure. The targets are hosts, ports, services, protocols, identity systems and the controls between network segments.
Network security and penetration testing answer different questions. Firewalls, segmentation and monitoring are the controls, and the pentest checks whether those controls hold when someone pushes on them.
A vulnerability scan is a narrower thing. It lists services with known weaknesses, while a pentest tries to use them and reports what the attacker gained.
External vs Internal Network Pentest
The two scopes look similar on a statement of work and produce very different reports. The split below is about what each finding means for the business, which is what leadership will ask about.
What an external test finds
An external test looks at your perimeter the way an outsider would. MITRE ATT&CK lists both exploiting public-facing applications and abusing external remote services such as VPNs as initial access techniques.
The table maps common external findings to their business meaning.
External finding | What it looks like | What it means for the business |
|---|---|---|
Exposed remote access | VPN, remote desktop or Citrix gateway reachable with weak authentication or a known flaw | A direct path into the internal network with no phishing required |
Forgotten host | A staging server, old marketing site or test API still running outdated software | An asset nobody patches because nobody remembers it exists |
Exposed management interface | Database, admin console, monitoring dashboard or router UI reachable from the internet | Configuration or data access that was never meant to be public |
Weak service configuration | Outdated TLS, permissive DNS, open mail relay, verbose banners | Lower-severity issues that help an attacker plan and impersonate |
Dangling DNS | A subdomain pointing at a deprovisioned cloud resource | Someone else can host content on your domain |
The forgotten host deserves the most attention. Asset inventories age quickly, and the attacker’s inventory is always more current than yours.
What an internal test finds
An internal test assumes the perimeter already failed. That assumption is realistic, since one phished laptop or one reused password is enough to start.
The table maps common internal findings to their business meaning.
Internal finding | What it looks like | What it means for the business |
|---|---|---|
Flat network | A standard workstation can reach databases, servers and management ports directly | One compromised device puts everything in range |
Credential weaknesses | Reused local admin passwords, weak service account passwords, credentials in scripts or shares | One set of credentials unlocks many systems |
Overprivileged identity | Users or service accounts with far more directory rights than their role needs | A short path from any user to domain or cloud admin |
Legacy protocols | Older authentication and name resolution protocols still enabled | Credentials can be captured or relayed on the local network |
Unpatched internal services | Internal apps and servers patched slower than external ones | Known flaws that are trivial to exploit once inside |
Weak segmentation | Cardholder, production or admin networks reachable from user networks | Compliance scope expands and blast radius grows |
Internal findings tend to chain. A single credential weakness rarely ends a test, so judge the report by the attack paths it shows.
Segmentation testing as its own line item
Segmentation is a control that only exists on diagrams until someone tests it. A segmentation test tries to reach each protected zone from each zone that should not reach it.
For a SaaS company, the zones that matter are production, corporate IT, CI/CD and anything that stores customer data. A laptop on the office network should have no route to a production database.
Ask for segmentation results as a separate section of the report. When a boundary fails, the finding should name the source zone, the destination, the port and the rule that allowed it.
Credentialed and uncredentialed internal testing
An uncredentialed internal test models a device plugged into the network with no account. A credentialed test starts with a normal user account, which is closer to what happens after a successful phish.
The credentialed version usually finds more, because identity is where internal networks are weakest. Overprivileged groups, stale service accounts and readable shares only show up once the tester can log in.
How to Pentest a Network, Step by Step
NIST SP 800-115 describes a four-stage penetration testing methodology with phases for planning, discovery, attack and reporting. The guide dates from September 2008, and the phase model still matches how professional network tests run.
The table maps each NIST phase to what happens in a network test. Descriptions in the second column are quoted or paraphrased from NIST SP 800-115 section 5.2.
NIST phase | What NIST says | What the tester does on a network | What you should see |
|---|---|---|---|
Planning | Rules are identified, management approval is documented and goals are set. “No actual testing occurs in this phase.” | Agree IP ranges, exclusions, testing windows, access method and emergency contacts | A signed scope and rules of engagement |
Discovery, part one | Information gathering and scanning | Map live hosts, open ports and running services, the activity MITRE calls network service discovery | An asset and service inventory, often with surprises |
Discovery, part two | Vulnerability analysis against vulnerability databases | Match services and versions to known flaws and misconfigurations | A candidate list, not yet proven |
Attack | Verify “previously identified potential vulnerabilities by attempting to exploit them” | Exploit, escalate privileges, and loop back to discovery from each new foothold | Proven access with evidence and the path that led there |
Reporting | “Occurs simultaneously with the other three phases” | Log actions and findings as they happen, escalate criticals immediately | A report with evidence, severity, business impact and fixes |
The loop from attack back to discovery is the part worth paying for. NIST draws it explicitly, and it is how a single foothold turns into a path across the network. Ask any provider to show where that loop happens in their process. A test that stops at the candidate list is a vulnerability assessment wearing a pentest invoice.
What a tester should not do
A professional network test is controlled. The tester avoids denial of service unless it is explicitly in scope, stays inside agreed ranges and stops to call you when something looks fragile.
Production databases, payment systems and medical devices usually get special handling. Agree those exclusions and test methods during planning, because the attack phase is a bad time to discover them.
How Network Findings Chain Into Application and Cloud Exposure
Network, application and cloud findings often land in separate reports. An attacker follows whichever path works, across all three.
Three example chains show how the boundaries blur:
External web app to cloud credentials: a server-side request flaw on an internet-facing app lets the attacker query the cloud instance metadata API, which can return credentials
Remote access to internal network: a weak VPN login or an exposed remote desktop gateway gives a foothold, then flat networking does the rest
Internal app to production data: an unpatched internal tool trusts anyone on the network, and its service account can read production databases
Each chain crosses a boundary that one-team testing misses. The initial access explainer covers how attackers get the first foothold, and lateral movement explained covers how they spread.
Attack path analysis is the discipline of drawing those chains before an attacker does. For the application side of the same picture, see the web application penetration testing guide.
Frequency and Compliance
PCI DSS is the standard that spells out network pentesting most directly. Requirement 11.4.1 defines a methodology that covers testing from inside the network (internal) and from outside it (external).
Requirement 11.4.2 covers internal testing and 11.4.3 covers external testing. Both run on a recurring schedule and again after significant changes to infrastructure or applications. The exact wording, including segmentation testing, sits in the standard itself in the PCI SSC document library. The PCI DSS penetration testing requirements guide walks through each one.
SaaS providers should note one addition. PCI DSS v4.0 added requirement 11.4.7, under which multi-tenant service providers support their customers’ external penetration testing.
Outside PCI DSS, cadence is usually driven by SOC 2 auditors, ISO 27001 risk treatment and customer security questionnaires. A sensible baseline is a full test on that cadence, plus targeted tests after major network changes.
Change frequency should set the rhythm more than the calendar does. An environment that ships new infrastructure weekly drifts away from its last report quickly, which is the case for continuous external testing between full engagements.
Network Penetration Testing Cost Drivers
Pricing varies widely and depends on a handful of scope variables. The penetration testing cost guide covers ranges, so this section sticks to what moves the number.
The table lists the drivers and how each one changes effort.
Cost driver | Why it changes effort |
|---|---|
Number of external IPs and hosts | More live services to enumerate, analyze and attempt |
Number of internal subnets and hosts | More discovery, more credential paths and more lateral movement to follow |
Segmentation testing | Each segment boundary needs its own verification |
Credentialed vs uncredentialed testing | Credentials add depth and add review time per host |
Access method | Remote access through a VPN or test device is simpler to schedule than on-site work |
Testing windows | Night or weekend windows for fragile systems stretch the calendar |
Retest scope | A retest of every finding costs more than a retest of criticals and highs |
Reporting requirements | Compliance mapping and executive reporting add writing time |
The biggest hidden driver is a stale asset list. If discovery finds far more hosts than the scope listed, the budget conversation happens mid-test.
How to Choose a Network Pentest Provider
Provider choice comes down to method, evidence and how well they connect network findings to the rest of your stack. The table lists what to ask.
Criterion | What to ask | Red flag |
|---|---|---|
Methodology | Which framework do you follow, and where does the attack loop back to discovery? | A process that ends at scanning |
Evidence | Does each finding show proof of access and the path to it? | Findings copied from scanner output with no validation |
Scope handling | What happens when discovery finds assets not on the list? | Out-of-list assets tested without asking, or ignored without telling you |
Safety | How do you protect fragile systems and handle production windows? | No rules of engagement template |
Chaining | Do you connect network findings to application and cloud exposure? | Separate reports that never reference each other |
Retest | Is a retest included and what does it cover? | Retest priced as a new engagement |
Continuity | What covers the gap between annual tests? | Nothing until next year |
Treat any proposal that cannot answer the chaining question as half a test. The other half is where the expensive findings live.
What CodeAnt AI Does That Fits The Bill…
CodeAnt AI starts external pentesting from the domains and assets you agree on. It monitors the attack surface 365 days a year and tests exposed apps and APIs from the outside with evidence.
Repository, cloud or internal access is added only for the assessments you authorize. That keeps the default engagement inside an external scope and makes deeper access a deliberate choice. The value is in the link between views. An exposed service found from outside can be traced to the code, cloud configuration or internal system behind it, so the fix lands on the root cause.
CodeAnt scans 60K+ companies externally on an ongoing basis, and reports from its pentests are mapped to SOC 2 and ISO 27001.
Where This Leaves You
A network penetration test answers two questions, whether someone can get in and how far they get once inside. Scope both, insist on the attack loop and proof, and connect network findings to the apps and cloud they touch.
Try it on your app: Run a free scan and get a pentest report in 48 hours, or book a pentest. Want to see the output first? Open the sample report.
