NETWORK SECURITY
Network and Infrastructure Penetration Testing Services
Manual testing of your whole network, from the internet, from inside and over Wi-Fi, to show which attack paths actually work and how to close them.
What a network test covers
- External and internal perspectives in one plan
- Segmentation and firewall rule validation
- Wi-Fi, VPN and remote access testing
- Network devices and cloud network controls
- 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
Network and infrastructure penetration testing is an authorized, manual attack on your internet-facing hosts, internal servers, Active Directory, Wi-Fi, VPN, network devices and cloud network controls. Testers prove which attack paths work and whether segmentation holds. The scope spans the external and internal testing described in NIST SP 800-115 and the network-layer testing named in PCI Security Standards Council guidance.
Last updated: October 2, 2026
Key takeaways
- Network and infrastructure penetration testing proves which attack paths through your perimeter, Active Directory, segmentation, Wi-Fi, VPN and network devices actually work, with evidence for every finding.
- External testing asks whether an outsider can get in. Internal testing asks how far a foothold spreads. A combined scope answers both and tests the controls in between.
- Under PCI DSS v4.0.1, segmentation that limits scope is tested at least every 12 months and after changes (requirement 11.4.5), and at least every 6 months by service providers (11.4.6, per PCI SSC guidance).
- Quarterly is the PCI DSS cadence for vulnerability scans, not penetration tests (PCI SSC guidance). Directive (EU) 2022/2555 (NIS2) and the UK National Cyber Security Centre (NCSC) set no fixed testing interval.
- A penetration test validates your vulnerability management. It doesn’t replace scanning.
- Complex infrastructure and cloud assessments have a published range of $5,000 to $12,000+, priced in tester-days. External-only and internal-only tests are quoted individually.
Both perspectives
We test from the internet and from inside your network, so you see the full path an attacker could take.
Controls in between
Segmentation, firewall rules, VPN and Wi-Fi are tested as the links that connect the outside to the inside.
Proof, not guesses
Every finding ships with evidence and step-by-step remediation your team can act on.
Re-test after fixes
A retest is available once your fixes ship: we verify them and confirm the result in writing.
What does an infrastructure penetration test cover?
An infrastructure penetration test covers everything beneath your applications: internet-facing services, the internal network and Active Directory, segmentation between zones, Wi-Fi, remote access, network devices and cloud network controls on AWS and Azure. You choose which areas are in scope, and each is tested from a real attacker’s starting position.
| Area | What we test | Typical findings |
|---|---|---|
| Perimeter and exposed services | Hosts and services that answer from the internet under your name: web servers, mail, DNS, remote access portals and forgotten hosts | Unpatched or unmaintained software, misconfigured edge services (T1190), deprecated protocols and weak ciphers |
| Internal network and Active Directory | The directory, servers, file shares and management systems reachable from a standard user account, plus credentials stored where users can read them | LLMNR/NBT-NS name-resolution poisoning (T1557.001), default credentials (T1078.001), systems that were never hardened |
| Segmentation between zones | Whether zones documented as separate actually are, and firewall rules that allow more than intended | Weak or bypassable segmentation (T1599) |
| Wireless | Corporate, guest and device Wi-Fi: encryption, authentication, guest isolation, rogue access points and reach into the wired network | Deprecated protocols and weak ciphers, weak segmentation between guest and corporate networks |
| Remote access and VPN | VPN gateways, remote desktop services and third-party connections: authentication strength, multi-factor coverage and what a connected user can reach | Exposed remote services (T1133), unpatched gateway software |
| Network devices | Switches, routers, firewalls and wireless controllers: management interfaces, credentials, firmware and configuration | Default credentials, exposed management protocols such as SNMP, unmaintained firmware |
| Cloud network controls on AWS and Azure | Virtual networks, security groups, network access lists and links between cloud and on-premises environments | Misconfigured rules, such as one widened during a deployment and left open, and weak segmentation between cloud and on-premises networks |
Technique IDs refer to MITRE ATT&CK, and our testing is aligned with NIST SP 800-115 and the Penetration Testing Execution Standard (PTES), so auditors and defenders can check every finding against a reference they already use. Application logic is out of scope here: web application and API tests are separate penetration testing services.
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.
Internal vs external infrastructure testing: which do you need?
External testing answers whether someone on the internet can get in. Internal testing answers how far an attacker spreads once inside, with testers acting as “a trusted insider or an attacker who has penetrated the perimeter defenses” (NIST SP 800-115). PCI DSS requirement 11.4 asks for both, so a combined test suits PCI DSS and first-time testing.
| Aspect | External | Internal | Combined |
|---|---|---|---|
| Starting position | Public internet, no access | Inside the network, with a standard user account | Both, plus the controls that connect them |
| Main question | Can an outsider get in? | How far does a foothold spread? | What is the full path from outside to your critical systems? |
| PCI DSS v4.0.1 | 11.4.3 | 11.4.2 | 11.4.2, 11.4.3 and, where segmentation reduces scope, 11.4.5 |
| Best fit | New internet-facing systems, perimeter changes, partner audits | Flat networks, directory changes, post-incident checks | PCI DSS, mergers, first-time testing, multi-site networks |
A combined engagement runs as one attack narrative, so a weakness found from outside feeds the internal phase. Separate tests suit a change on one side only, such as a new VPN gateway or an Active Directory migration.
For depth, see external penetration testing and internal penetration testing. Not sure which fits? Describe your network in a quote request and we’ll recommend the test type.
What is segmentation testing?
Segmentation testing checks whether network zones documented as separate really are, such as a cardholder data environment (CDE) cut off from office systems. PCI DSS v4.0.1 requirement 11.4.5 defines its purpose as “confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems.”
- How often: merchants test at least every 12 months and after any change to segmentation controls or methods. Service providers test at least every 6 months (requirement 11.4.6).
- How: “actively attempting to identify routes and paths from networks outside the CDE into the CDE” (PCI SSC guidance), with every path that answers logged in a reachability matrix.
- Who: a tester “organizationally separate from the management of the target systems” (PCI SSC guidance) who, under requirement 11.4.5, need not be a Qualified Security Assessor (QSA) or Approved Scanning Vendor (ASV).
Segmentation itself “is not a PCI DSS requirement. However, it is strongly recommended”, PCI SSC guidance adds. A failed test widens your assessment scope. Zones and sites drive the effort, so list them when you request a quote.
Wireless penetration testing
Wireless penetration testing checks whether your Wi-Fi gives an attacker a way into the network from the parking lot, the lobby or the floor below, without ever touching your internet perimeter. Wireless is the one part of the network that ignores walls, so it deserves its own place in the scope. NIST SP 800-115 also notes that it is “important for organizations to actively test and secure their enterprise wireless environments”.
Encryption and authentication settings
Whether each network uses current security standards, and whether enterprise authentication is configured so that staff devices verify the network they’re joining.
Guest network isolation
Whether a guest can reach corporate systems, other guests or device management interfaces.
Rogue and look-alike access points
Unapproved devices plugged into your network, and networks imitating yours that could trick staff devices into connecting.
Wireless-to-wired reachability
What a device on each wireless network can reach on the wired side. This is where Wi-Fi findings turn into segmentation findings.
Shared key hygiene
Pre-shared passwords that never change, are posted on a wall or are reused across office sites.
What a vulnerability scan misses on a network
A vulnerability scan tells you which hosts run software with known weaknesses. It doesn’t tell you whether any of them connect into a path an attacker can follow, and on a network, the path is the finding. Scanners still run for coverage; the value is in what testers do with the output.
Segmentation failures
A scanner reports what it sees from where it sits. It doesn’t flag that a zone which should be unreachable answered at all.
Firewall rule intent
An allowed connection looks normal to a tool. Whether that rule should exist is a judgment about your business.
Working credentials
A reused or default password that logs in successfully raises no alert, because nothing is technically broken.
Chained low-severity issues
A weak Wi-Fi key, an over-broad firewall rule and a shared admin password each rate low. Together they can form a route from the guest network to a server zone.
Exposed device management
A switch or firewall admin interface reachable from the user network often has no CVE at all. The risk is who can reach it.
A penetration test doesn’t replace scanning either: the UK National Cyber Security Centre (NCSC) recommends using a test as “a method for gaining assurance in your organisation’s vulnerability assessment and management processes, not as a primary method for identifying vulnerabilities”. The NCSC adds that a test can only validate your systems against known issues on the day it runs. PCI SSC guidance keeps both in the calendar, with penetration tests at least annually and vulnerability scans at least quarterly, and our guide to penetration testing vs vulnerability scanning explains the difference.
How a network penetration test runs
Scoping
We agree the address ranges, sites, wireless networks, cloud accounts and starting positions in scope, plus exclusions, testing windows and escalation contacts, in a signed rules of engagement document.
Reconnaissance
We map what is reachable from each starting position: public exposure from the internet, live hosts and services inside, wireless networks on site and network rules in the cloud.
Vulnerability analysis
We rank weaknesses by where they sit on a path to your critical systems, so a medium finding on the route to a payment zone can outrank a high one on an isolated host.
Controlled exploitation
We attempt each viable path from its starting position and stop once impact is shown, recording evidence at every hop between zones. Critical findings are reported to you as soon as we confirm them.
Reporting and retest
One report covers every phase. We walk your team through the paths that cross zones, and a retest of the fixes is available.
What you receive
You receive an Executive Summary for management and a Technical Report for the people doing the fixes. A retest is available once your fixes are deployed. The Executive Summary explains what an attacker could reach from each starting position, what that means for the business and what to fix first.
The Technical Report lists every finding with the affected hosts or devices, a severity rating with its reasoning, evidence of exploitation and step-by-step remediation. A combined engagement ties the phases together: the segmentation matrix extends to wireless, remote access and cloud zones, and an end-to-end attack narrative follows a path from the internet or the Wi-Fi to your critical systems. That narrative shows which single fix breaks the most chains.
How long does it take and what does it cost?
A network penetration test typically runs one to three weeks of testing, plus a few days to produce the report, with critical findings shared during the test. Combined network assessments are priced as infrastructure work, where our published range for complex infrastructure and cloud assessments is $5,000 to $12,000+. External-only and internal-only tests are quoted individually, as listed on our pricing page. We price in tester-days with no hidden fees.
| What moves the quote | Why it matters |
|---|---|
| Number of starting positions | Internet, internal network, wireless and cloud are separate phases, each with its own reconnaissance and attack paths. |
| Live hosts and network devices | Effort follows what actually answers, and how many services and management interfaces run on it. |
| Segments and sites | Every zone adds reachability checks, and every office with wireless in scope adds on-site time. |
| Cloud networks and links | Each virtual network, and each connection back to on-premises systems, adds rules to review and paths to test. |
| Compliance mapping and retest | Evidence mapped to named requirements such as PCI DSS 11.4 adds reporting time, and retest effort depends on how much changed. |
The right price covers the tester-days your scope actually needs. Price alone doesn’t tell you whether you’re buying manual testing or a scan, so ask any provider for a sample report with evidence of manual exploitation. For a fixed quote, send us your scope.
How often should infrastructure be tested?
How often depends on the framework. PCI SSC guidance lists penetration tests at least annually and after significant changes, and vulnerability scans at least quarterly. Under the Digital Operational Resilience Act (DORA), Delegated Regulation (EU) 2024/1774 requires automated vulnerability scanning at least weekly for ICT assets supporting critical or important functions. NIS2 and the UK NCSC set no fixed interval.
| Activity | Cadence | Source |
|---|---|---|
| Automated vulnerability scanning of ICT assets supporting critical or important functions | At least weekly | Delegated Regulation (EU) 2024/1774 (DORA RTS), Art. 10(2) |
| Vulnerability scans (PCI DSS) | At least quarterly and after significant changes | PCI SSC penetration testing guidance |
| Segmentation testing, service providers (PCI DSS) | At least every 6 months | PCI DSS v4.0.1 requirement 11.4.6; PCI SSC guidance |
| Internal and external penetration tests (PCI DSS) | At least annually and after significant changes | PCI SSC penetration testing guidance; PCI DSS requirement 11.4 |
| Segmentation testing, merchants (PCI DSS) | At least every 12 months and after changes to segmentation controls | PCI DSS v4.0.1 requirement 11.4.5 |
| Assessing whether cybersecurity risk-management measures are effective (NIS2); penetration testing (UK NCSC guidance) | No fixed interval; risk-based | Directive (EU) 2022/2555 (NIS2), Art. 21(2)(f); NCSC penetration testing guidance |
Regulation (EU) 2022/2554 (DORA) lists “network security assessments” among the tests in a resilience testing program and reserves threat-led penetration testing for financial entities “mature enough from an ICT perspective”. For NIS2 evidence, see NIS2 penetration testing.
Outside any compliance calendar, test after a firewall replacement or network redesign, a cloud migration, a new office or wireless rollout, or a merger that joins another organization’s network to yours. We don’t certify compliance: the report is evidence for your auditor or your own risk assessment. If a deadline is driving the test, include it when you request a quote.
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.
Frequently asked questions
Is infrastructure penetration testing the same as network penetration testing?
For scoping purposes, yes: we use both names for one engagement. Whatever you call it, the written scope lists exactly what’s included (address ranges, sites, wireless networks, cloud accounts and the starting positions we test from), and that scope, not the label, sets the tester-days and the price.
What does a network penetration tester do?
A network penetration tester attacks your infrastructure with written authorization, from the starting positions a real intruder would have. They map what is reachable, confirm which weaknesses are exploitable, chain them into attack paths and stop at proof. Then they document each step with evidence and remediation, so your team can reproduce the path and close it.
How much does a network penetration test cost?
It depends on scope, measured in tester-days. Our published range for complex infrastructure and cloud assessments is $5,000 to $12,000+, while external-only and internal-only network tests are quoted individually. The pricing page lists every assessment type and what moves the number.
Is wireless penetration testing part of a network test?
It is when you include it in scope. Wireless testing covers encryption and authentication settings, guest isolation, rogue access points and what each wireless network can reach on the wired side. It requires on-site work at the agreed locations, so we scope it per office.
Can you test our cloud network?
Yes. At the network level we test virtual network segmentation, security group and access list rules, and the connections between cloud and on-premises environments. Our black box engagement for a retail platform before Black Friday shows external testing that spanned a web store, a mobile API and cloud infrastructure. For identities, storage, serverless and Kubernetes inside your AWS or Azure accounts, see cloud penetration testing.
Will network testing disrupt production?
Disruption is unlikely because the rules of engagement are built to prevent it. Fragile systems are excluded in writing, scanning on production segments is paced, and testing stops at proof. Denial of service and load testing are never in scope, and your named contact can pause the test at any time.
Fixed-price quote
Request a network 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)
Complex infrastructure and cloud tests: $5,000–$12,000+, priced in tester-days. External-only and internal-only tests are quoted individually. All prices
Market ranges are in our network penetration testing cost benchmarks.
What happens after you send it
- Tell us what to test Send your public IP ranges and domains, the number of internal hosts, sites and Wi-Fi networks, any cloud accounts in scope and your compliance deadline.
- 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