PERIMETER SECURITY
External Penetration Testing Services
Manual testing of everything you expose to the internet, from the position of an attacker with no access and no credentials, with proof for every finding.
What an external test covers
- Full inventory of internet-facing assets
- Authentication weaknesses on exposed portals
- Unpatched and misconfigured edge services
- Controlled exploitation with evidence
- Retest available after you fix the findings
Fixed scope, fixed tester-days, fixed price, agreed before testing starts.
Scoped and quoted per engagement. Priced in tester-days, no hidden fees. How the test works · See a sample report
External penetration testing is a manual security assessment that starts where an attacker starts: on the public internet, with no accounts, no VPN and no access you did not already hand to the world. Testers work through everything your organization exposes to the internet and try to answer one question with evidence: can someone get inside from out there?
That starting point is the whole difference from an internal penetration test. An internal test assumes the attacker is already on the network, through a stolen laptop, a phishing click or a contractor’s connection, and measures how far that foothold spreads. An external test refuses that assumption. It asks whether the foothold can be earned at all, using only what is reachable from a coffee shop on the other side of the world.
Key takeaways
- An external penetration test starts from the public internet with zero access and tries to prove a way in, while an internal test starts from a foothold and measures spread.
- The first deliverable is an inventory. The list of systems you actually expose is almost always longer than the list you put in the scope document.
- Most perimeter breaches come from authentication weaknesses and forgotten assets, not from exotic exploits.
- Automated scanning misses the findings that matter here: password spraying, credential reuse, MFA gaps on secondary protocols, subdomain takeovers and chained low-severity issues.
- PCI DSS v4.0.1 requirement 11.4 asks for external and internal testing at least every 12 months and after significant changes. DORA, NIS2 and GDPR push in the same direction.
- External network testing is quoted per engagement, with effort typically running 3 to 8 tester-days depending on address ranges, applications and compliance scope.
Attacker's starting point
No credentials, no network access, no map. Exactly what someone scanning your range starts with.
Inventory first
The asset list is a deliverable in itself. It is often longer than the one you handed us.
Proof, not guesses
Every finding ships with reproduction steps and evidence of what an attacker reaches.
Re-test after fixes
A retest is available once your team ships the fixes: we verify them and update the report.
What Is External Penetration Testing?
External penetration testing is an authorized attack simulation against your internet-facing systems, performed from outside your network with no credentials and no privileged knowledge. The tester sees what an opportunistic attacker sees: a set of IP addresses, hostnames, certificates, login pages and open ports. Everything else has to be discovered, guessed or earned.
The goal is not a list of open ports. The goal is proof: whether an outsider can authenticate to a system they should not reach, extract data that should not be public, or gain a position on your network that lets the next stage of an attack begin. Findings arrive with the request, the response and the reproduction steps, so your team can verify each one. A scan, by contrast, reports that a service exists and that its banner suggests an old version. Our explainer on penetration testing versus vulnerability scanning covers the gap in full.
Know what you want tested?
Send us your scope and get the test type, tester-days, timeline and a fixed price in writing. Prefer to compare first? See our prices.
What counts as your external attack surface
Seven categories, plus the assets nobody remembers owning.
Your external attack surface is every system that answers a request from the public internet, whether or not anyone in your organization remembers it exists. That last part is where external penetration testing services usually earn their fee.
The expected assets are easy to name:
Web servers and applications
Marketing sites, customer portals, partner platforms, public APIs and anything behind a load balancer.
Login portals
Webmail, single sign-on, remote desktop gateways, HR and payroll systems, ticketing platforms.
VPN and remote access gateways
Concentrators, SSL VPN portals, jump hosts and remote management interfaces.
Mail and DNS
Mail servers and their relaying rules, SPF, DKIM and DMARC records, zone transfer settings, DNS entries pointing at resources nobody owns anymore.
Cloud edge
Public storage buckets, managed databases with open network rules, serverless endpoints, container registries and misconfigured security groups.
Edge devices
Firewalls, routers, file transfer appliances, cameras, building systems and printers that ended up with a public address.
How reconnaissance works before any attack
Reconnaissance builds the attacker’s map of your organization from public sources, before a single intrusive request is sent. It is passive, invisible to you, and exactly what a real attacker does first. Four activities carry most of the value.
OSINT on the organization and its people
We collect what is publicly published about your company: employee names and roles, the email format they imply, technologies named in job postings, supplier relationships, document metadata and code repositories. For an attacker, that converts into a username list and a shortlist of systems worth attacking.
Address range and certificate mapping
We map the netblocks registered to your organization, the hosting and cloud ranges you use, and the certificates issued for your domains. Certificate transparency logs matter here, because every certificate ever issued for a hostname is a permanent public record. Names that were never meant to be advertised show up in them.
Credential leak discovery
We search public breach data and paste sources for addresses in your domains. Every match is a candidate for the login portals we found, since people reuse passwords between a retail account and a corporate one. This is the most productive path onto a well-patched perimeter.
Subdomain enumeration
We enumerate subdomains from DNS records, certificate logs, archived pages and search indexes, then resolve each one and check what answers. Staging systems, legacy applications and dangling records surface here. A subdomain pointing at a deleted cloud service can often be claimed by anyone, which hands an attacker a hostname on your own domain.
The output of all four is a target list ranked by how likely each item is to give access, and that ranking drives the rest of the engagement.
What we test in external infrastructure penetration testing
We test the weaknesses that actually get organizations breached from outside, in the order an attacker would try them. External network penetration testing rarely turns on a dramatic exploit. It turns on an account, a forgotten host or a rule nobody reviewed. Wi-Fi, internal segmentation and Active Directory sit outside an external scope; network and infrastructure penetration testing covers them together with the perimeter in one engagement.
Authentication weaknesses on exposed portals
We use password spraying rather than brute force: a few likely passwords tried across many accounts, paced to stay under lockout thresholds. Brute force locks accounts and announces itself, spraying does neither, and that is why attackers prefer it. We also test password reuse against leaked credentials, accounts still on a default, and portals with no multi-factor authentication at all.
Multi-factor gaps behind the front door
A portal can enforce MFA on the web login while a legacy protocol, an API endpoint or a mobile sync interface on the same platform accepts a password alone. We check the secondary paths, not just the page users see.
Unpatched edge services
VPN appliances, file transfer products, mail gateways and management interfaces are the most attacked software in this category, because one vulnerability gives network access directly. We confirm real exploitability instead of trusting a version banner, which often lies after a backported fix.
TLS and header misconfiguration
Deprecated protocol versions and cipher suites, expired or mismatched certificates, missing transport security enforcement, and response headers that expose stack and version details.
Information disclosure
Directory listings, exposed version control folders, backup archives left in web roots, verbose error pages naming internal hostnames and paths, debug endpoints and status pages that were never meant to be public.
Vulnerable administrative panels
Database managers, application consoles, monitoring dashboards, content management back ends and device web interfaces reachable without a network restriction.
Services that should never be public
Databases, caching layers, file shares, remote desktop, backup agents and orchestration ports answering on a public address, usually because a cloud firewall rule was widened during a deployment and never narrowed again.
What an automated scan will not find here
An automated scan will not find the issues that actually let someone in, because each one requires a decision a tool cannot make. We use scanners for coverage, so this is not a complaint about tooling. The gap is specific.
- A valid login is not a vulnerability to a scanner. When a spray succeeds, the portal returns a normal successful authentication. No signature fires, no CVE applies, nothing is flagged. A person decides which usernames to build, which passwords are plausible for your organization, and how slowly to try them.
- Leaked credentials matched to your portals. Connecting a password from a third-party breach to an employee account on your SSO gateway is research plus judgment, not a network check.
- Subdomain takeover. A scanner sees a hostname that does not resolve to a live service and reports it as down. A tester recognizes a dangling record pointing at a released cloud resource and demonstrates that the name can be claimed.
- Chains of low-severity issues. A verbose error page leaks an internal hostname. That hostname appears in certificate logs beside a second public host. That host runs an old console with a default account. Each rates as informational or low on its own. Together they are a route in, and no scan report puts those three lines next to each other.
- Context that changes severity. A staging portal holding real customer data with no MFA looks identical to a harmless test page from the outside.
- False positives and false comfort. Backported patches make version banners unreliable in both directions. Confirming exploitability by hand separates a finding your team must fix this week from noise that wastes a sprint.
Our black box engagement for a retail platform ahead of Black Friday is a worked example of this difference under a hard deadline.
How an external penetration test runs
Scoping and rules of engagement
We agree the IP ranges and domains in scope, what is explicitly excluded, the testing window, permitted techniques, escalation contacts and the conditions under which we stop. It is written down and signed before the first packet.
Inventory and reconnaissance
We reconcile your scope against what is publicly discoverable, run passive OSINT, map ranges and certificates, enumerate subdomains and search for leaked credentials. Anything found outside the agreed scope goes back to you and is tested only once you confirm ownership and authorize it.
Vulnerability analysis
We identify services, versions and configurations across the confirmed inventory, combine automated coverage with manual review, and rank candidate weaknesses by realistic impact rather than by a generic score.
Controlled exploitation with evidence
We attempt the ranked attack paths, exploiting far enough to prove impact and no further: nothing destructive, no denial of service, no data extraction beyond a minimal proof sample. Critical findings are reported the moment we confirm them.
Reporting and retest
We deliver the report, walk your team through the findings, answer implementation questions, and a retest of the fixes is available once they are deployed.
What you receive
You receive two documents and proof for every finding, and a retest is available after your fixes ship. The Executive Summary is written for management and boards: what an outsider could reach, what it would mean for the business, and what to prioritize. The Technical Report is written for the people doing the work.
Each technical finding includes the affected host and service, a severity rating with the reasoning behind it, reproduction steps, the captured evidence proving exploitation, the business impact, and step-by-step remediation naming the specific control or configuration change to apply. Once your team deploys the fixes, we re-run the original attack paths and confirm in writing whether each issue is closed, partially closed or still exploitable.
You also receive an inventory of everything we confirmed is exposed to the internet under your name, including assets that were not in the original scope. For organizations grown through acquisitions or running decentralized infrastructure, that list is often the most useful page in the document.
How long does it take and what does it cost?
External network testing is quoted individually for each engagement. It appears on our price list as “Ask for a quote” because the work is driven by what you expose rather than by a package size, with effort typically running 3 to 8 tester-days plus a few days to produce the report. We price in tester-days with no hidden fees, so the estimate tracks the amount of work rather than the size of your company.
Four factors move the number:
| What moves the quote | Why it matters |
|---|---|
| Number of IP addresses and live hosts | Discovery scales with the range, but real effort scales with how many addresses actually answer and how many distinct services run on them. |
| Number of applications on the edge | Every public web application or portal is its own test surface with its own authentication and logic, so three portals is not one portal three times. |
| Compliance scope | Evidence mapped to named control requirements, plus attestation-grade documentation, adds reporting time on top of testing time. |
| Retest depth | Verifying a handful of patched services is quick. Re-validating a rebuilt perimeter or a migrated gateway is a second engagement in miniature. |
Send us your address ranges and domain list and we will scope it against those specifics. Our pricing page shows the published ranges for assessment types that are packaged, and the services overview shows how perimeter testing fits alongside cloud, application and red team work.
When is external penetration testing required?
It is required whenever a regulation asks you to test the effectiveness of your security controls, and it is needed in practice whenever your perimeter changes. Regulators rarely use the phrase “external penetration test” outside of PCI DSS, but the obligation lands on the same systems.
| Framework | Requirement | What it means for your perimeter |
|---|---|---|
| PCI DSS v4.0.1 | Requirement 11.4 | External and internal penetration testing at least once every 12 months and after any significant infrastructure or application change, with exploited findings corrected and retested. |
| DORA (EU) 2022/2554 | Articles 24 to 27 | Financial entities run a digital operational resilience testing programme (Articles 24 and 25), and entities selected by their TLPT authority also run threat-led penetration testing (Articles 26 and 27). Internet-facing systems are the first candidates. |
| NIS2 (EU) 2022/2555 | Article 21 | Risk management measures must include policies for assessing the effectiveness of security controls, which means testing them rather than documenting them. |
| GDPR (EU) 2016/679 | Article 32 | Requires a process for regularly testing and evaluating technical measures. Any public system processing personal data sits inside that process. |
Three situations make a test worth scheduling regardless of the calendar: before a customer or partner security audit, where a recent report shortens the review considerably; after a change to the network edge such as a firewall replacement, a cloud migration or a new remote access gateway; and after a merger or acquisition, when you inherit an attack surface nobody on your team has mapped. The perimeter drifts even when the architecture diagram does not.
What can you check before you hire us?
Three things you can verify for yourself: what the report looks like, who does the testing, and how a real engagement went.
What does the report look like?
Every report opens with an executive summary for management, then one page per finding: severity and CVSS score, evidence of exploitation, business impact and step-by-step remediation. A retest is available after fixes, and the updated report shows which findings are closed. See a sample penetration test report with every section explained.
Who tests your systems?
Senior pentesters from our team of 25, holding hands-on offensive security certifications such as OSCP and OSCE alongside CEH, CISA, CISM and CRISC.
Retail platform before Black Friday
A black-box test of a web store, mobile API and AWS environment ahead of peak traffic, with every finding fixed and confirmed in a retest.
Internal or external: which should you test first?
External testing shows what an attacker on the internet can reach today. Internal testing shows how far they get once inside, for example after a phishing email or a stolen VPN account. Most organizations start with the perimeter, then add an internal penetration test for Active Directory and segmentation.
Frequently asked questions
What is the difference between external and internal penetration testing?
The difference is the starting position. An external test begins on the public internet with no access and tries to establish a foothold. An internal penetration test begins with that foothold already granted, simulating a compromised workstation, a malicious insider or a contractor’s connection, and measures how far an attacker can move once inside. They answer different questions, which is why PCI DSS asks for both and why most organizations run them as a pair. Our network penetration testing page explains how the two combine in one engagement.
How many IP addresses can you cover?
Coverage depends on tester-days and on how many addresses actually respond, not on a fixed limit. Discovery across a large range is fast, because most addresses are silent. Testing effort concentrates on live hosts and on the services they run, so a /24 with six live hosts is a smaller job than eight addresses running twelve applications between them. For large or uncertain ranges we agree a priority order during scoping, and the report states exactly what was covered.
Do you need credentials for an external test?
No. A standard external test is black box by design, because credentials would defeat the purpose of testing whether access can be earned from outside. The exception is when you want an authenticated review of a specific public portal as part of the same engagement, in which case we treat it as a separate, clearly labeled component so the black box results stay clean. We do ask you to confirm ownership of anything we discover before we test it.
Will the test take our services down?
Availability is protected by the rules of engagement, and denial of service and load testing are never in scope. We cap request rates on production systems, avoid exploits known to destabilize services, use clearly marked test accounts, and keep a named contact reachable throughout the window so testing can be paused immediately. Password spraying is paced under lockout thresholds, which also keeps your users from being locked out of their own accounts.
Do you re-test after we fix the findings?
Yes, a retest is available after fixes. Once your team deploys remediation, we re-run the original attack paths against the affected systems and confirm in writing whether each finding is resolved, partially resolved or still exploitable. Partial fixes are common on the perimeter, where one host gets patched while an identical service on a sibling host keeps the same flaw.
Fixed-price quote
Request an external penetration test
Tell us what to test. You get a written scope, the number of tester-days and a fixed price before any testing starts. No hidden fees.
See a sample report first (18-page PDF, no email required)
External network tests are quoted per engagement and priced in tester-days. All prices
For a market reference, see our external network test cost benchmarks.
What happens after you send it
- Tell us what to test Send your IP ranges or domains, the number of internet-facing applications, your deadline and any compliance requirement.
- Get a written scope and price We reply by email with scoping questions or a fixed quote in tester-days.
- Test, report, retest Most tests take 1–3 weeks plus a few days for the report. Critical findings are reported during testing. Retesting after fixes is available.
- OSCP, OSCE and CISSP certified testers
- 500+ penetration tests
- Aligned with OWASP WSTG, PTES and NIST SP 800-115
- Executive summary and technical report