Verizon's 2026 Data Breach Investigations Report states that 31 percent of breaches now start with software vulnerabilities, beating stolen passwords as the top way attackers get in. The systems carrying most of that exposure are the ones anyone can reach without a credential: your VPN gateway, your mail edge, your load balancers, the marketing host nobody has logged into since 2023.
An external network penetration test answers one question about those systems. From the public internet, with no credentials and no insider help, how far can a competent attacker get. It is not a scan; it is a human working through your perimeter the way an adversary would, validating what is real, chaining what connects, and stopping short of damage.
This post is for the person buying one this quarter, usually because of an annual requirement, an insurer or customer questionnaire, or a perimeter reshaped by a cloud migration. Read it and you should be able to draft your own scope document. Stingrai delivers this work with senior human testers under its internal and external network penetration testing service.
What the external perimeter actually is in 2026
Most organizations underestimate their perimeter because they picture the firewall. The perimeter is everything reachable from the internet that resolves back to your organization, and it spans seven layers. The last two are where the interesting findings live.
Perimeter layer | Typical assets | Common scoping mistake |
|---|---|---|
Registered address space | Owned or ISP-allocated IPv4 and IPv6 blocks, colocation ranges | Handing over full CIDRs without noting which are populated |
Edge appliances | Firewalls, VPN concentrators, SSL VPN portals, load balancers, WAFs, file transfer appliances, mail gateways | Assuming the vendor patches them automatically |
Remote access | VPN portals, remote desktop gateways, published virtual desktops, SSH bastions | Treating MFA as present because it exists somewhere |
Mail and DNS | MX hosts, webmail, SPF, DKIM and DMARC records, registrar and nameserver config | Nobody owning records created for campaigns |
Cloud assets you own | Public load balancers, storage endpoints, managed database listeners, orchestration control planes | Excluding cloud because the provider "handles security" |
Management planes | Out-of-band server controllers, hypervisor consoles, device admin interfaces, CI and monitoring dashboards | Believing an obscure port is a control |
Forgotten and inherited hosts | Decommissioned staging sites, legacy portals, acquired ranges, dangling subdomain records | Not in any inventory, so never in any scope |
The management-plane layer has an authoritative reference point. CISA's Binding Operational Directive 23-02, issued June 2023, requires federal civilian agencies to remove specified networked management interfaces from the public internet, or place them behind a zero-trust policy enforcement point, within 14 days of discovery. The device classes it names make a usable checklist for anyone: routers, switches, firewalls, VPN concentrators, proxies, load balancers, and out-of-band server management interfaces such as iLO and iDRAC.
The edge layer has a second one. CISA's Binding Operational Directive 26-02, issued February 5, 2026, requires agencies to continuously discover edge devices, inventory those that are end-of-support or will be within twelve months, and decommission them on or before that date. The reasoning generalizes: edge devices sit at the boundary, integrate with identity systems, and stop receiving fixes at a date most asset registers do not track.
Attack-surface discovery, and why your inventory is the first real finding
On a well-run engagement, discovery is a deliverable, not a warm-up. The tester builds an independent picture of your perimeter from public data, then reconciles it against the list you provided.
That picture draws on registration and routing data for your address space, certificate transparency logs that reveal hostnames issued certificates, current and historical DNS records, cloud provider address attribution, and public artifacts such as code repositories and job postings that name internal systems. Active enumeration follows: which addresses respond, what they run, which hostnames share infrastructure. Reconciliation is where value appears, and four delta categories recur.
Live but decommissioned. Retired in the ticketing system, never powered off or pulled from the load balancer.
Shadow and marketing assets. Campaign microsites, event portals and vendor-hosted subdomains that never went through IT.
Inherited estate. Ranges, domains and appliances that arrived with an acquisition and were never folded into the inventory.
Dangling DNS. A record still pointing at a deprovisioned cloud resource, creating a subdomain takeover condition where someone else can claim it and serve content under your name.
If your provider cannot show you a discovery delta, they tested the list you gave them, which is a scan of a spreadsheet rather than an assessment of a perimeter. How to scope a penetration test covers the discipline in depth.
What is in scope, and what is explicitly out
A scope document that says only "our external IP ranges" will produce arguments later. Write it as three columns.
In scope by default | In scope only if agreed in writing | Explicitly out of scope |
|---|---|---|
Live host, service and version enumeration across authorized ranges | Authenticated testing of VPN, webmail and remote access with supplied accounts | Denial of service, stress testing, resource exhaustion |
TLS, DNS, SPF, DKIM and DMARC configuration review | Password spraying and credential-stuffing simulation | Destructive exploitation, data deletion, config changes |
Identification of exposed management and admin interfaces | Exploitation carrying plausible availability risk | Assets you do not own or cannot authorize, including partner systems |
Verification of known vulnerabilities, false positives removed | Pivoting internally after an external foothold | The cloud provider's infrastructure, as distinct from your config |
Information disclosure: exposed files, debug endpoints, metadata | Deep application-layer testing of discovered web apps | Phishing, pretexting and physical entry, separate engagements |
Safe, evidence-backed exploitation sufficient to prove impact | Testing outside agreed windows or from undeclared addresses | Bulk exfiltration beyond proof-of-access samples |
Two boundaries cause most disputes.
Web applications on the perimeter are identified, not fully tested. An external test finds the login portal, checks its transport security, probes authentication controls and flags obvious exposure. It does not spend days on business logic or broken object-level authorization. That is web application penetration testing, where Stingrai's Snipe agent runs autonomous and hybrid coverage. Snipe is a web-application agent only; network, Active Directory, Wi-Fi, physical and social engineering work is delivered by senior human testers.
Detection testing is a different product. An external pentest is normally announced, and the goal is coverage rather than stealth. If your real question is whether your security operations team would notice, that is a red team or purple team engagement (red team vs penetration test vs continuous validation).
What the tester actually does, day by day
Below is the shape of a mid-sized engagement. Calendar time runs longer than tester days because of coordination and report review.
Phase | What happens | What you receive |
|---|---|---|
Day 0 | Rules of engagement signed, authorization executed, escalation path agreed, source addresses declared, allowlist decision made | Signed rules of engagement, tester source IPs |
Day 1 | Passive discovery, then reconciliation against your asset list | Draft discovery delta |
Day 2 | Active enumeration, version fingerprinting, TLS, DNS and mail record review | Confirmed live-host and service inventory |
Day 3 | Manual validation, false-positive removal, exposed management interface identification | Interim status, criticals escalated immediately |
Day 4 | Authentication surface: MFA coverage, agreed spraying or stuffing, credential-exposure correlation | Notice of any authentication bypass |
Day 5 | Safe exploitation to prove impact, chaining into attack paths, evidence capture | Evidence package per finding |
Day 6 to 7 | Report drafting, severity with business context, remediation guidance, QA | Draft report |
Debrief | Technical walkthrough, executive summary, remediation sequencing | Final report and readout |
Two behaviours separate a serious provider from a report factory. Critical findings reach your escalation contact within hours of validation, not in the report three weeks later. And every finding is manually confirmed by a human with request and response evidence, rather than carried over from a scanner plugin.
The finding classes that dominate external reports
Real reports cluster tightly. Six classes account for most of the severity, across industries and estate sizes.
Finding class | What it looks like | Why it matters |
|---|---|---|
Exposed management planes | Out-of-band server controllers, hypervisor consoles, device admin interfaces, unauthenticated caches, CI dashboards | Built to grant full administrative control, so exposure turns one credential or unpatched flaw into estate-level compromise |
Unpatched or end-of-support edge devices | VPN gateways, firewalls and file transfer appliances on versions with known exploited vulnerabilities, or past support | They sit outside endpoint tooling and terminate authenticated sessions, and exploitation is now the leading breach entry route |
Weak or absent MFA on remote access | Portals accepting single-factor authentication, or MFA bypassable through a legacy protocol or alternate endpoint | An attacker with a valid username and password walks in, and partial coverage reads as full coverage on a questionnaire |
Credential exposure and stuffing viability | Corporate credentials in public breach corpora, plus portals lacking lockout, rate limiting or anomalous-login detection | Proves whether reused credentials plus an exposed portal equals access, and whether anyone notices the attempts |
Information disclosure | Verbose errors, exposed version control or backup files, directory listings, debug endpoints, internal hostnames in headers | Individually low severity, collectively the map an attacker uses to pick targets, and chaining raises the whole path |
Misconfigured DNS and mail | Missing or permissive SPF, DMARC left in monitor-only mode, dangling CNAMEs enabling subdomain takeover, zone transfers | Enable convincing spoofing of your domain, and they are cheap to fix, which makes them a fast credibility win |
Two technique names appear in proposals and deserve precision. Password spraying is trying one or a few common passwords across many accounts specifically to stay under per-account lockout thresholds. Credential stuffing is replaying username and password pairs harvested from unrelated breaches. Both need written agreement in the rules of engagement and a monitored account list so nobody is locked out of production.
Note what is absent. Kerberoasting, AS-REP roasting, LLMNR and NBT-NS poisoning, NTLM relay, Active Directory Certificate Services misconfigurations such as ESC1, and unconstrained delegation are internal-side findings from an internal or Active Directory assessment, not an external one. If your questionnaire asks about domain compromise paths you need both halves, usually bought together through the network security practice.
External pentest, vulnerability scan and attack-surface monitoring
These three are often sold as substitutes. They are not, and a buyer who knows the difference writes a better scope.
Dimension | Vulnerability scan | Attack-surface monitoring | External penetration test |
|---|---|---|---|
Core question | What looks vulnerable now | What changed on my perimeter | What can an attacker actually do |
Runs | On a schedule, automated | Continuously, automated | In a defined window, human-led |
Asset source | The list you configured | Independent continuous discovery | Independent discovery reconciled with your list |
Validation | Signature and version inference | Little to none | Manual confirmation of every reported issue |
Proves impact | No | No | Yes, with evidence |
Chains findings | No | No | Yes, that is the point |
Output | Plugin-ID list with scores | Inventory and change alerts | Attack narrative, validated findings, remediation plan |
False positives | Common, unfiltered | Not applicable | Removed before the report |
Useful cadence | Weekly or monthly | Continuous | Annually plus after significant change |
They compose well: monitoring keeps the inventory honest between tests, scanning catches newly published vulnerabilities on known hosts, and the pentest establishes what is genuinely exploitable.
Telling a real engagement from a scan with a report template. Ask for a redacted sample and check six things. Is there an asset-discovery delta section, or only the assets you supplied? Does each finding carry manual evidence, or a scanner plugin identifier? Is there a chained finding where two mediums combine into something worse? Are removed false positives noted? Does the narrative reference your business context, or could it apply to any client? Are testers named with certifications, and is retesting in the fee. A vendor who scopes on raw IP count, without asking how many hosts are live or how many portals exist, is quoting a scan. How to evaluate a penetration test report works through this.
What the deliverable contains
A report an auditor, an insurer and an engineer can all use has eight components.
Executive summary. Business risk in plain language, the two or three attack paths that matter, overall perimeter posture. No score tables here.
Attack narrative. The engagement in sequence, showing how discovery led to a foothold and what the foothold enabled.
Asset inventory and discovery delta. Everything found, marked against what you provided, unknowns highlighted. Often the most acted-upon page.
Findings register. Per finding: identifier, affected assets, a standard score plus a business-context rating, evidence, reproduction detail, remediation.
Remediation plan. Sequenced by risk reduction per unit of effort, not by score alone.
Methodology and coverage statement. What was tested, when, from which source addresses, what was excluded and why. Auditors read this section.
Retest appendix. Updated status per finding once fixes are verified.
Machine-readable export. CSV or JSON, so findings reach your ticketing system without retyping.
You will usually also want a completion letter, a short attestation-style summary shareable with customers and underwriters without exploit detail (completion letter vs full report).
External network testing supports your PCI DSS, SOC 2, ISO 27001 and NIS2 programs by producing the technical evidence those programs reference, but be precise about what is actually mandated. PCI DSS v4.0.1 Requirement 11.4.3 calls for external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change, and CMMC requires penetration testing at Level 3 only. ISO 27001, SOC 2 and NIST SP 800-171 do not mandate it across a general population, and ISO 27001 and SOC 2 set no frequency.
Duration, cost drivers and how the work is quoted
External engagements are scoped individually, so there is no list price. What you can do is understand the variables well enough to compare two quotes fairly and spot one built on the wrong unit.
Cost driver | Why it moves the price | What to give the vendor |
|---|---|---|
Live host count | The real unit of work. A /24 with nine responsive hosts is nine hosts, not 256 | Responsive host count, or CIDRs plus permission to discover |
Distinct exposed services | Ten hosts running one service each is far faster than ten running eight | A port and service summary if you have one |
Exposed applications and portals | Each login portal adds authentication-surface work | Count of internet-facing apps and depth wanted |
Authenticated testing | Valid accounts on VPN and portals increase coverage and time | Whether you supply test accounts, and how many roles |
Discovery ownership | Independent discovery across address blocks, domains and cloud accounts adds days | Whether discovery is included, which it should be |
Entities and regions | Subsidiaries and separate tenancies each need an authorization chain | Legal entity list and who signs for each |
Window constraints | Out-of-hours work and change freezes extend elapsed time | Blackout dates and preferred windows |
Evidence requirements | Auditor-grade packs and questionnaire mapping add reporting effort | The frameworks and questionnaires you must satisfy |
Retest scope | Retesting everything differs from criticals and highs only | Your expected remediation timeline |
As a planning shape rather than a price list: roughly 25 live hosts with one or two portals is typically a few tester days over one to two weeks elapsed; 25 to 100 live hosts with several portals is one to two tester weeks over two to three weeks; multi-entity estates run longer. Use those as sanity checks, and expect a vendor to justify their day count against the drivers above.
On Stingrai pricing, the published web-application packages, Autonomous at US$3,000 one-time or US$450 per month and Hybrid at US$6,800 one-time or US$1,275 per month, are scoped to web applications, and the no-high-or-critical-finding guarantee applies to those Autonomous and Hybrid tiers. Network, Active Directory, Wi-Fi, physical and social engineering engagements are scoped individually, so request a quote rather than mapping a web application price onto a network perimeter. Current packages sit on the Stingrai pricing page, and network scoping runs through the internal and external network penetration testing service. If you are comparing proposals, how to compare penetration testing quotes sets out a normalizing method.
What to prepare, and how retesting works
Preparation is the difference between a test that starts on day one and one that starts on day four. Everything below should exist before kickoff.
Item | What to have ready | Why it matters |
|---|---|---|
Authorization letter | Signed by someone with authority over the assets, naming ranges, domains and the window | Testing cannot start without it, and hosting providers may need notice |
Asset list | CIDR blocks, autonomous system numbers, domains and subdomains, cloud accounts with public assets | Becomes the baseline for the discovery delta |
Exclusions | Every excluded asset, with the reason recorded | Stops it reappearing as an argument during reporting |
Contacts | Technical contact, escalation path, out-of-hours number, security operations lead | Critical findings need a human within hours |
Source address decision | Whether tester addresses are allowlisted through the WAF and edge filtering | Changes what the test proves, see below |
Test accounts | Credentials, roles and MFA enrolment for authenticated testing | Provisioning delay is the top cause of lost days |
Blue-team notification | Whether your security operations team is told in advance | A pentest is normally announced; to measure detection, buy a red team |
Change calendar | Freezes, migrations and maintenance windows during the test | A perimeter that shifts mid-test yields findings nobody can reproduce |
The allowlist decision deserves deliberate thought. Testing without an allowlist reflects reality and shows whether edge filtering and rate limiting genuinely interfere with an attacker. Testing with one guarantees coverage, because blocking will not silently hide vulnerable services behind a filtered response. The strongest pattern is to run the first portion unfiltered, record whether and how quickly the tester was blocked or detected, then allowlist for the remainder. Put both outcomes in the report.
Retesting verifies fixes to findings already reported, on the same assets, within an agreed window after the report, typically 30 to 90 days. It does not add assets and does not restart discovery, and the output is an updated status per finding plus a revised completion letter you can send onward.
A fresh test is right when the perimeter itself changed: a cloud migration onto new addresses, an acquisition adding address space, a new edge appliance or VPN platform, or a significant architecture change. That is the standard PCI DSS v4.0.1 trigger language, and insurers ask the same question at renewal; underwriter questions are collected in pentest questions in cyber insurance underwriting.
Stingrai has run offensive security engagements since 2021 from Toronto and London, is a CREST-accredited penetration testing service provider at firm level with individual testers holding CREST CRT, has published 18 CVEs, and holds 5.0 out of 5.0 across 19 Clutch reviews. Team certifications include OSCE3, OSCP, OSWE, OSED, OSEP, CISSP and CRTO.
Frequently Asked Questions
What is included in an external network penetration test?
An external network penetration test covers everything an unauthenticated attacker can reach from the internet across your authorized IP ranges, domains and cloud assets. That means host and service enumeration, edge appliance and remote access review, TLS, DNS and mail configuration review, exposed management interface identification, information disclosure review, and manually validated exploitation sufficient to prove impact. Denial of service, destructive exploitation, phishing, physical entry and assets you cannot authorize are normally excluded and belong in the scope document.
How much does an external network penetration test cost?
External network engagements are scoped individually rather than sold at a list price, because the work is driven by live host count, the diversity of exposed services, how many internet-facing applications exist, and whether authenticated testing is included. Ask each vendor to show their day count against those drivers so quotes compare on the same basis. Stingrai's published Autonomous and Hybrid packages are scoped to web applications, so network, Active Directory, Wi-Fi, physical and social engineering work is quoted to scope.
How long does an external network penetration test take?
Elapsed time runs longer than tester days because of authorization, coordination and report review. As a planning shape, roughly 25 live hosts with one or two portals is a few tester days across one to two weeks elapsed, 25 to 100 live hosts is one to two tester weeks across two to three weeks, and multi-entity estates run longer. Slipped timelines usually trace to late authorization letters or unprovisioned test accounts rather than the testing itself.
What is the difference between an external penetration test and a vulnerability scan?
A vulnerability scan is automated, runs against the asset list you configured, infers issues from versions and signatures, and reports them without validation, so false positives reach you unfiltered. An external penetration test is human-led, performs independent discovery, manually confirms every reported issue with evidence, and chains findings into attack paths that show real business impact. The scan tells you what looks vulnerable; the test tells you what an attacker can actually do.
How often should you run an external network penetration test?
PCI DSS v4.0.1 Requirement 11.4.3 calls for external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change, and CMMC requires penetration testing at Level 3 only. ISO 27001, SOC 2 and NIST SP 800-171 do not mandate it across a general population, and ISO 27001 and SOC 2 set no frequency, so annual cadence there is driven by auditors, customers and insurers. Most organizations settle on annually plus after any change that reshapes the perimeter.
Do you need to provide IP addresses for an external network penetration test?
Provide your CIDR blocks, autonomous system numbers, domains and the cloud accounts holding public assets, but a good engagement does not stop at that list. The tester performs independent discovery from public registration, certificate transparency and DNS sources, then reconciles it against what you supplied, and the gap is often the most valuable output of the test. If a provider only tests the list you hand them, you are buying a scan of a spreadsheet.
Does an external network penetration test include web application testing?
An external network test identifies web applications on the perimeter and assesses them at the network and authentication layer: transport security, exposed administrative endpoints and obvious information disclosure. It does not cover business logic, authorization flaws such as broken object-level authorization, or complex chained application vulnerabilities, which need a dedicated web application penetration test. If your internet-facing applications carry sensitive data, scope both, because the two find genuinely different classes of issue.
Is retesting included after an external network penetration test?
Retesting should be included in the fee, and if a vendor charges separately you should ask why. A retest verifies fixes to previously reported findings on the same assets within an agreed window, typically 30 to 90 days after the report, and produces an updated status per finding plus a revised completion letter. It is not a fresh test, so new assets, a cloud migration, an acquisition or a new edge appliance means scoping a new engagement.
