A nine-month-old test report versus 3.4 hours of attack time
The pentest report sits in the quality management folder, and the certificate hangs framed in the hallway next to the kitchenette. What nobody has checked is how much of the tested environment still exists nine months later. That is exactly the gap continuous pentesting is meant to close!
Some version of this plays out at half of all mid-sized companies. In January, an external provider tests the external infrastructure and finds four medium-severity issues, all of which get fixed. In March, a new VPN concentrator goes live. In May, the CRM moves to the cloud with a service account whose password sits in a pipeline variable. In July, a contractor takes over remote maintenance of a production line, and MFA is exempted "for now" because the maintenance tool doesn't support it.
In October, a clerk clicks on a login prompt that looks like Microsoft 365. From that moment on, a different clock is running than the one the testing cycle follows.
After initial access, attackers need on average just 3.4 hours to reach the Active Directory server, based on 661 cases from incident response and managed detection. The average time to first lateral movement in 2025 was 29 minutes, and the fastest observed was 27 seconds. Identity-related causes such as stolen credentials, brute force, and phishing were the starting point in 67.32 percent of incidents.
On average, an attacker needs half a working day to take control of the domain. According to Sophos, it takes exactly 3.4 hours. By that point, the environment an annual pentest describes has often been gone for months.
What a penetration test delivers, and where the test date limits it
In Germany, a penetration test is clearly defined. The BSI guide describes five phases: preparation, information gathering, assessment, active intrusion attempts, and follow-up. The methodology is sound and holds up in audits. It applies, however, to a bounded engagement with a start, an end, and a fixed scope.
That structure has a built-in property that is often mistaken for a flaw: a pentest says nothing about the state of things the next day. According to Security-Insider, every infrastructure change and every new application creates new attack surface, while the test itself only captures a snapshot.
| Framework | What it requires | Actual testing interval |
|---|---|---|
| NIS2, Art. 21 | Risk-based technical and organizational measures, no fixed testing frequency | usually annual |
| § 39 BSIG (KRITIS) | Proof of implementation submitted to the BSI | every 3 years |
| BSI implementation concept | Five-phase methodology, five aggressiveness levels | per engagement |
The NIS2 directive requires a risk-based approach and sets no fixed frequency for penetration tests. Operators of critical infrastructure have to submit their evidence under § 39 BSIG every three years. The annual cycle is an industry convention driven by budgets, not a legal requirement.
Breakout time, and why it keeps dropping
Breakout time is the span between initial access and the first lateral movement. It is the window in which defenders can still contain an incident to a single system. According to CrowdStrike, breakout time got 65 percent faster compared with the previous year. Highly professional groups aren't the only reason. AI-assisted tools now let less skilled actors run complex attack chains at high speed.
The chain from a stolen login to domain control
The typical sequence shows why testing intervals and attack speed don't match. It is technically unremarkable, which is exactly why it works so reliably.
None of these steps needs an exotic vulnerability. In just over half of the cases examined, multi-factor authentication was missing or misconfigured. Pulling credentials from memory and the registry relies on techniques that have been documented in the MITRE framework under T1003 for years. If you want to know whether this chain works in your own network, you need a dedicated Active Directory pentest, not just an external perimeter scan.
The problem is the mismatch between timelines. Attackers work in hours, and the ransomware goes off at night when hardly anyone is watching the SIEM. Defenders work in quarters, sometimes in three-year cycles. With annual testing, up to twelve months can pass between the day a misconfiguration appears and the day someone notices it.
Three mistakes that keep the annual cycle alive
- Documents the state on exactly one date
- Every later change goes untested
- New CVEs don't show up in the report
- The directive sets no fixed frequency
- It calls for a risk-based approach
- A high rate of change means shorter intervals
- AI assistance lowers the barrier to entry
- Breakout time dropped by 65 percent
According to CrowdStrike, breakout time fell by 65 percent within a single year.
Tie the testing cycle to your rate of change, not the budget year
- Measure your rate of change: Count how many external services, subdomains, and access points were added in the last twelve months. That number should set your testing interval, not the calendar.
- Enforce MFA everywhere: Cover all privileged and remote access, including maintenance access for contractors. In more than half of the cases, MFA was missing or misconfigured.
- Harden and monitor Active Directory: Tier privileged accounts, log credential-dumping techniques listed under T1003, and alert on unusual replication requests.
- Introduce attack surface management: Every new system has to be in scope within days, not at the next engagement. This is where continuous testing comes in.
- Sort out night and weekend coverage: The ransomware payloads were executed outside business hours. Who on your team responds at 3:15 a.m. on a Sunday?
- Keep the annual pentest, but rethink its scope: Nothing replaces its manual depth. Shift the scope to attack paths and assumptions instead of asset lists that go out of date anyway.
The goal is to catch a new misconfiguration right away, not after the next budget year.
Common questions about testing intervals
How often should you run a penetration test?
No frequency is set by law. The NIS2 directive calls for a risk-based approach, and in practice security professionals recommend testing at least once a year. It makes sense to match the interval to how quickly your infrastructure changes, and to test again after every major architecture change.
How long do attackers need to reach Active Directory?
After initial access, attackers need an average of 3.4 hours to reach the Active Directory server. The average time to first lateral movement in 2025 was 29 minutes. Detection and response therefore have to kick in within minutes, not working days.
What is a continuous pentest, and when is it worth it?
With continuous testing, an ongoing relationship with a testing provider replaces individual engagements. It pays off especially for organizations with frequent releases, growing cloud use, or many external access points.
Keep the pentest, rethink the annual cycle
Nobody should conclude from these numbers that penetration tests are useless. The BSI's five-phase methodology delivers the kind of depth no automated tool can replace. What no longer holds up is the assumption that one test a year tells you anything about the other 364 days.
The cause is a mismatch between two rhythms. Attacks play out in hours, infrastructure changes happen weekly, and tests happen once a year, or for critical infrastructure only every three years. Closing that gap means keeping a constant eye on your own attack surface.
- Know the time window: 3.4 hours to the AD server is the benchmark your detection and response have to meet.
- Start with identity: Two out of three incidents begin with compromised credentials, so MFA and privileged accounts belong at the top of the list.
- Justify your interval: Put in writing why your testing cycle fits your rate of change.
- From phishing email to Domain Admin: the full attack path, traced step by step
- Why certifications don't mean you're secure: where evidence and reality drift apart
- MFA bypass techniques: how AiTM, MFA fatigue, and SIM swapping defeat the second factor
How old is your last test report, really?
We test Active Directory environments, attack surfaces, and identity paths, either as one-off assessments or on an ongoing basis, depending on how fast your infrastructure changes.
Request an initial consultation →
