Every pathfrom outsideinto your network.

We start with passive reconnaissance via certificate transparency, DNS history, ASN relationships, code leaks and public repositories. Completeness is the means here, not the end: the only thing you can overlook is what you never found. Once the inventory of every IPv4 and IPv6 endpoint is in place, including services on unusual ports, we weigh each against a single question – can this be the start of a route into your internal network? In almost every engagement that turns up assets the customer did not know about: a server switched off but never decommissioned, a test instance from a project that ended years ago, the subdomain of a provider who is now somebody else.

This is where the shortest route inwards runs, which is why this part of the test matters most. VPN and edge appliances face the internet by definition, they terminate authentication, and on the other side they talk straight to your internal network – a successful attack does not end at the appliance, it starts there. They get patched less often than servers because a reboot hits every remote workplace at once. We check patch levels against current and historical CVEs, including ones that may already have been exploited before the update – a patch applied afterwards removes no web shell dropped before it. We look for management interfaces that do not belong on the public internet, validate whether MFA is genuinely enforced for every account, and test the typical misconfigurations in SSL-VPN and web interfaces.

SPF, DKIM, DMARC and BIMI are reviewed – not merely for existence but for effect: a DMARC record set to “p=none” looks fine in any compliance report and stops not one spoofed mail. We test for open relays and auth bypass in mail servers, subdomain takeover via dangling CNAMEs in Azure, AWS and GitHub Pages, weak certificates and missing CAA policies. These findings are rarely spectacular and almost always cheap to fix. Their leverage lies elsewhere: they open a route inwards that runs not through a vulnerability but through a person. A phishing mail pointing at a taken-over subdomain of your own domain passes the checks your staff are trained to make – and wherever your VPN asks for a password alone, the credentials they enter there are enough.

The process is the same for every perimeter test; what differs is the scope. Up front we record in writing which IP ranges and domains are in scope, who is reachable during the test, and which checks stay excluded. Critical findings are reported immediately – while a route inwards stands open, waiting for the final document is the actual risk.

1. 01

   Scoping & authorisation

   We settle the scope together, record it in writing and obtain the necessary authorisations – including your hosting provider's, where their terms require it. You name a technical contact and an escalation path for critical findings.

2. 02

   Passive reconnaissance

   Before a single packet reaches your systems, we collect what is publicly available about you anyway: certificate transparency logs, DNS history, netblock allocations, code and credential leaks. The result is an asset list that regularly turns out longer than the one we started from.

3. 03

   Active testing

   Only now does testing begin: service fingerprinting, vulnerability assessment, appliance and configuration analysis, manual verification. Manual is the operative word – a scanner produces candidates, but whether they add up to a route inwards in your particular setup is a judgement a human makes.

4. 04

   Report

   You receive a report with a management summary and a technical part, each finding with a reproducible walkthrough, evidence, a severity rating and a recommendation. It is written so your administrators can work from it and an auditor accepts it as evidence.

5. 05

   Debrief & optional retest

   We walk through the report with your team, prioritise together and answer questions about remediation. If you want it, we then retest the resolved findings specifically and document the state reached; that retest is a service of its own and is itemised separately in the proposal.

This page deliberately carries no day rates, person-day figures or price ranges. A perimeter test is not a standard product sold by the unit; it follows the attack surface you actually have – and before reconnaissance nobody knows that precisely, yourself included. Rather than a number too high for half of all enquiries and too low for the other half, we set out what drives the effort.

• Size of the attack surface

  The number of reachable hosts, services and domains is the single strongest factor. Twenty systems behind one firewall behave differently from a landscape grown over years across several sites, legacy networks and cloud accounts.

• What actually talks to the inside

  A static web presence with no connection to your network is quickly assessed. The effort sits where a system genuinely talks to your internal network: VPN concentrators, mail infrastructure, portals authenticating against your directory service, APIs and OT connections.

• Depth of testing

  A baseline inventory, a full test with proof of exploitation, and a test with a social engineering component are three different services. Which one makes sense depends on whether you are testing for the first time or already have a history.

• Obligations and evidence

  If the test has to follow a specific framework – the BSI guide, a customer audit, TISAX or an insurance clause – documentation and formatting requirements come with it, and those show up in the effort.

• Repetition and retesting

  A first test costs more than the second on the same infrastructure, because the inventory is then already in place. Repeated annually, the effort per round falls and the value rises, because change becomes visible.

How you get to a number you can rely on.

In a scoping conversation we go through your external attack surface and settle the five points above. Out of it you get a written proposal with a fixed scope, a fixed price and a committed time window; the conversation is free and commits you to nothing. If you need a budget range to raise an internal request, a rough description of your environment is usually enough.

We do not work to an in-house method nobody outside the company knows. Testing follows publicly documented standards – that is the precondition for a result to mean anything to an auditor, an insurer or your own customer.

• OWASP Web Security Testing Guide

  The de facto standard for testing web applications and services. At the perimeter that covers everything a browser reaches: customer portals, appliance admin interfaces, webmail and API endpoints.

• Penetration Testing Execution Standard

  Describes the course of an engagement from pre-engagement interaction through reconnaissance and exploitation to reporting. The five phases above follow this structure.

• BSI: practical guide to IS penetration testing

  The guide from Germany's Federal Office for Information Security, including its classification by information base and aggressiveness. The usual reference when a German auditor or authority asks what was tested against.