Testing your perimeter the way an attacker actually finds it.
Most breaches don't start with a clever zero-day. They start with a forgotten VPN appliance, an unpatched mail gateway, or a login page nobody remembered was public. We test the internet-facing estate you know about, and go looking for the parts you don't.
Your attack surface is bigger than your asset register.
Every organisation with an internet connection has a perimeter, and almost every organisation's perimeter has drifted further from its asset register than anyone in IT would like to admit. A staging server spun up for a project two years ago, a subdomain pointing at a decommissioned marketing platform, a branch office router with a management interface left facing outward — none of these show up in a spreadsheet, but all of them show up to an attacker running mass internet scanning.
The services that do make it onto the register aren't automatically safe either. VPN gateways, mail servers and remote access portals are consistently among the most targeted internet-facing services because they're designed to accept connections from outside, which makes patch discipline and configuration hardening on them far more consequential than on an internal file server that never leaves the LAN.
Credential exposure compounds the problem. Password reuse, credentials leaked in historic third-party breaches, and default or weak passwords left on management interfaces give attackers a way in that has nothing to do with unpatched software. We regularly find valid corporate credentials sitting in public breach data that would grant access to a VPN or webmail portal on the day we test it.
For remote and hybrid organisations, the perimeter has also quietly expanded to include every remote access route employees use to reach internal systems — not just the head office firewall. A test that only looks at the office's public IP address misses the branch sites, the cloud-hosted jump boxes and the third-party remote support tools that now form just as much of the real perimeter.
None of this requires sophistication to exploit. Automated internet-wide scanning tools find exposed services within hours of them going live, and opportunistic attackers routinely work down lists of known-vulnerable software versions looking for whoever hasn't patched yet. The organisations that get hit first are rarely the specific target; they're the ones the scanner happened to find open.
- Forgotten hosts and subdomains outside the known asset register
- Unpatched VPN, mail and remote access services facing the internet
- Exposed management interfaces reachable without VPN or IP restriction
- Corporate credentials already circulating in public breach data
Discover everything, then test what's actually exposed.
We start with reconnaissance rather than assuming your provided scope is complete. Using a mix of passive open-source intelligence and active discovery, we build a picture of your public-facing footprint from your domain names and known IP ranges outward, then compare it against the asset list you've given us. The differences are often the most interesting part of the engagement before a single exploit attempt has happened.
Once the live estate is mapped, we enumerate every service in scope — web applications, mail gateways, VPN concentrators, remote desktop and administration interfaces, DNS, and anything else answering on a public address. Each service is fingerprinted properly rather than trusted on banner text alone, because misconfigured or spoofed version strings are common enough to catch out automated tooling.
From there, testing moves to manual verification. Where a scanner flags a potential vulnerability, we confirm exploitability by hand rather than reporting it on the strength of a version number. Where credential-based attacks are in scope, we check for exposed logins against breach data and test for weak or default passwords under agreed rate limits, so live services aren't disrupted in the process.
We pay particular attention to patch level and configuration on remote access and mail infrastructure specifically, because these services carry disproportionate risk given they're built to accept untrusted connections by design. A missing security update on an internal print server is a different conversation to the same gap on a VPN appliance.
Findings are triaged and reported by real-world impact, not by CVSS score alone. A medium-rated finding that gives an unauthenticated path to internal systems gets treated with more urgency than a high-rated finding that requires conditions your environment doesn't meet, and we explain that reasoning in plain terms in the report.
- Passive and active discovery run before scope is finalised, not after
- Manual verification of every finding before it reaches the report
- Credential exposure checked against known breach data where agreed
- Findings prioritised by real exploitability, not raw scanner severity
Everything in the engagement, set out up front.
A scoped engagement covering discovery, testing and reporting for your internet-facing estate.
Perimeter discovery
Passive and active reconnaissance to identify hosts, subdomains and services beyond your declared scope.
Service enumeration
Full fingerprinting of every live service, including web, mail, VPN, DNS and remote access.
Manual exploitation testing
Hands-on verification of vulnerabilities rather than reliance on automated scan output alone.
Credential exposure review
Checks against known breach data and weak or default password testing on exposed logins where agreed.
Patch and configuration assessment
Review of software versions, TLS configuration and hardening across every exposed service.
Free retest of critical and high findings
A follow-up check once fixes are applied, included in the original engagement fee.
What you receive.
- Discovered asset inventory versus declared scope
- Risk-rated findings report with reproduction steps
- Executive summary for leadership and auditors
- Evidence pack for every confirmed finding
- Remediation guidance written for your IT or hosting provider
- Credential exposure summary where in scope
- Retest report confirming remediation
- 30-minute debrief call to walk through results
Built for organisations that need the work done properly.
Organisations that have never mapped their true perimeter
Firms whose internet-facing estate has grown through mergers, projects and provider changes without a single owner keeping track.
Businesses supporting hybrid and remote teams
Organisations relying on VPN, remote desktop or cloud jump boxes as the main route into internal systems.
Companies needing evidence for insurance or client due diligence
Firms asked to demonstrate independent testing of their internet-facing footprint as part of a renewal or a tender.
Anyone due an annual or post-change retest
Organisations that test regularly and need this cycle's engagement to reflect infrastructure changes since the last one.
What changes once the work is done.
What changes once the perimeter has been properly mapped and tested.
A true asset inventory
A confirmed list of what's actually internet-facing, closing the gap between the register and reality.
Fewer opportunistic entry points
Patched, hardened services that no longer sit on the low-hanging-fruit list automated scanners work through.
Credential exposure addressed
Reused and leaked passwords rotated before they're used against you, rather than after.
Evidence for insurers and clients
A report that satisfies due diligence questionnaires without needing to be explained or caveated.
A prioritised, realistic fix list
Findings ranked by actual exploitability, so effort goes where it reduces risk rather than where the CVSS score is highest.
A baseline for future change
A dated record to compare against after the next infrastructure or provider change.
Why discovery matters as much as the exploitation phase.
It's easy to focus attention on the exploitation phase of a penetration test because it's the part that produces the memorable findings, but in our experience the discovery phase is where the genuinely useful information turns up. Organisations rarely lose control of a system because a tester found a novel technique against a well-managed, well-documented service. They lose control because something existed that nobody was watching.
That's why we treat scope as a starting point rather than a fixed boundary. If your provided IP ranges and domain list turn up additional infrastructure during reconnaissance — a subdomain resolving to a different provider, an IP address just outside your declared range that clearly belongs to you — we flag it and agree with you whether to bring it into scope before testing continues, rather than quietly ignoring it because it wasn't on the original list.
We also make a point of testing the boring services properly, not just the interesting ones. Mail servers, DNS and VPN gateways rarely generate headline findings, but a missing patch or a weak TLS configuration on any of them is a realistic route in, and they're exactly the services that get deprioritised for maintenance windows because nobody wants to risk an outage on something business-critical.
We deliver this work for clients across Chesterfield, Sheffield, Derby, Nottingham, Leeds, Manchester, Birmingham and London, and the pattern holds regardless of sector or size: the perimeter is bigger, older and less documented than the asset register suggests. Finding that out under controlled conditions, from a report you can act on, is considerably better than finding it out from an incident.
Questions we are asked most often.
What counts as our external infrastructure?
Anything reachable from the internet: firewalls and VPN gateways, mail and web servers, DNS, remote access portals, cloud-hosted virtual machines, and any forgotten box a previous project stood up and never decommissioned. Before we test anything, we run discovery to build an asset list against your known estate, because the gap between the two is often where the real risk sits.
How is this different from a vulnerability scan?
A scan gives you a list of CVEs matched against banner versions, with no verification of whether they're actually exploitable in your configuration. We run the same automated discovery but then manually chain findings together, attempt exploitation where it's safe to do so, and strip out false positives, so the report reflects genuine exposure rather than a raw scanner export.
Will testing affect our live services?
We scope and agree testing windows and rules of engagement before work starts, and we avoid denial-of-service style techniques against production infrastructure unless specifically requested and controlled. Where a service looks fragile during discovery, we flag it and check with you before pushing further rather than causing an outage to prove a point.
Do you test our cloud-hosted servers as part of this?
Yes, where a server or service is internet-facing regardless of where it's hosted, whether on-premises, in AWS or Azure, or with a third-party provider. This is separate from our cloud configuration testing, which reviews the management plane, identity and platform settings rather than the exposed services themselves — many clients run both together for full coverage.
How long does an external infrastructure test take?
Most engagements run one to two weeks from discovery through to reporting, depending on the size of the address range and the number of live services found. A small office perimeter with a handful of public services is usually quicker; a larger estate with multiple sites, subsidiaries or legacy IP ranges takes longer to enumerate properly before testing begins.
Do you need credentials or prior access to test the perimeter?
No. This is unauthenticated, outside-in testing that mirrors what an opportunistic attacker or automated scanning tool would see with no inside knowledge. If a finding requires valid credentials to demonstrate impact, such as password spraying against a VPN portal, we'll say so clearly rather than assume access we haven't actually obtained.
What happens if you find something critical mid-engagement?
We stop and tell you immediately rather than waiting for the final report. Exposed management interfaces, unpatched remote access services and leaked credentials get flagged the same day by phone or email, with enough detail for your team to start remediation while testing continues on the remaining scope.
Can you test infrastructure we don't know we have?
That's often the most valuable part of the engagement. Given a company name, domain set and known IP ranges, we run open-source reconnaissance and passive discovery to surface subdomains, forgotten hosts and shadow IT before active testing starts, and it's common to find services nobody in the room knew were still live.
Penetration testing
The full range of manual-led testing services, from web applications to internal infrastructure.
Vulnerability management as a service
Ongoing scanning and patch tracking to keep the perimeter in the state this test confirms.
Managed security
Continuous monitoring and response for the services and alerts a one-off test can't watch year-round.
Want to know what's actually visible from the internet?
Send us your domains and known IP ranges and we'll scope a straightforward external test, no pressure and no obligation.
Scope an external test