Assume you have already been breached. Not as a worst case, but as the planning baseline. Modern security strategy, from NIST's guidance to every zero-trust architecture, accepts that a determined attacker eventually gets a foothold, which makes 'can they get in?' a far less interesting question than 'what happens in the hours and days after they do?'. An assumed breach assessment is the engagement built around that premise.
It starts the test with the attacker already inside, by handing testers a foothold, a low-privilege workstation, a set of valid credentials, or a planted implant, so every hour goes toward detection, response, and blast radius rather than achieving the breach. This guide explains how it works, what it can and cannot measure, and where it sits between a standard penetration test and a full red team. If you want to stress-test internal detection and segmentation without burning weeks on the front door, this is the model.
You start with an assumed breach because initial access is unreliable to test and rarely the thing that actually fails in a real incident. A traditional red team can burn a third of its time trying to get in, and if a single phishing email lands, you learn a lot about your email filtering and very little about whether you would catch and contain the intruder afterward. Assumed breach skips that and spends the entire budget on the part of the kill chain where most organizations are blind.
The case for it is straightforward. Efficiency: no time on initial access means more time on detection, lateral movement, and blast-radius analysis. Realism: breaches happen, so assuming one is a more honest posture than hoping the perimeter holds. Coverage: you test the internal controls (segmentation, EDR, identity hardening) a perimeter-focused test never reaches. Repeatability: a consistent starting foothold makes results comparable across assessments and over time.
There is also a regulatory angle. Threat-led testing frameworks like TIBER-EU and the Bank of England's CBEST, now reinforced by DORA for EU financial entities, increasingly expect an assumed-breach leg so the scenario reaches the internal controls intelligence says a real adversary would target. Mature programs often pair a perimeter-focused external test with an assumed breach for the internal picture, covered in our breakdown of the types of penetration testing.
An assumed breach assessment is an engagement that begins with the testers already holding a foothold inside your environment, so the test measures post-compromise detection, response, and lateral movement rather than perimeter strength. Instead of weeks spent phishing or hunting an exposed service, you grant a starting position and an objective, defined as precisely as any red team flag:
START STATE Domain-joined workstation WKS-4471 +
low-priv user JDOE (no local admin).
OBJECTIVE Reach the finance zone from the user subnet.
FLAG Contents of \\fin-fs01\treasury\flag.txt
FORBIDDEN Data destruction (T1486), real exfiltration
(T1041), any action on TREASURY-PROD.
MEASURE Dwell time, detection rate, blast radius.The starting foothold, agreed in scoping, usually takes one of three forms: a standard domain-joined workstation with a low-privilege user, a set of valid employee credentials as if harvested in phishing, or a planted implant on an internal host simulating a post-exploitation state. From that position the team behaves like an attacker who has just landed, enumerating the domain, harvesting credentials, escalating, and moving laterally, exactly the later stages of the standard penetration testing and red team lifecycle. The difference is purely the starting point, and that choice reshapes what the test can measure.
An assumed breach assessment tests three things a perimeter test cannot: how fast you detect an active intruder, how well you respond, and how far they can spread before you stop them. The last is the blast radius, the set of systems, data, and privileges an attacker can reach from a single compromised foothold.
Concretely, the team probes detection (does the SOC see internal reconnaissance via T1087 and T1069, credential dumping via T1003, and lateral movement via T1021, and which techniques pass silently?), lateral movement and privilege escalation (can a low-privilege user reach Domain Admin, reusing valid accounts via T1078, with BloodHound mapping the paths, detailed in our Active Directory checklist and the guide to defending against AD attacks), segmentation (can the team pivot from a user subnet into production or finance, or does the network contain them?), and response (once activity is detected, how fast and effectively does the IR process contain it?).
On a recent assumed breach against a healthcare provider, we started from a single nurse's workstation and reached a domain admin account in under a day through one over-privileged service account, while the SOC saw nothing until we deliberately tripped a noisy alert to confirm the response path even worked. The blast radius from one low-privilege foothold was the entire clinical network. Operators still apply OPSEC discipline, throttling activity and preferring living-off-the-land techniques, because the whole point is to see which behaviors your telemetry actually catches. The output is a clear picture of blast radius and the exact detections and segmentation gaps that let it grow.
The difference is the starting point and the scope of what is tested: a full red team includes initial access and the human and physical layers, while an assumed breach skips straight to post-compromise activity inside the network. A red team answers 'can a real adversary get in and reach the objective without us noticing?'. An assumed breach answers the narrower but often more useful 'once they are in, how bad does it get and do we catch them?'.
That makes assumed breach a focused subset of red teaming. It is faster and cheaper because it drops the most unpredictable phase, and it produces more consistent, repeatable internal findings. The trade-off is that you do not test your perimeter, email security, or user awareness, the very controls a full red team or a social engineering test exercises. Neither replaces the other. Many organizations run assumed breach assessments more frequently for internal assurance and a full red team less often for the complete picture, a continuous cadence that aligns naturally with agentic pentesting.
You measure an assumed breach by detection and response, then convert the gaps into detections. Three numbers carry the verdict, each with a formula. Dwell time = (first detection) minus (foothold granted). Detection rate = (techniques that fired an alert) divided by (techniques executed). MTTR = (containment) minus (first detection). Because the starting foothold is consistent, these numbers are directly comparable across engagements, so you get a clean trend line for whether your interior defenses are improving, something a full red team's variable initial access can never give you.
The uplift comes from the debrief, ideally run as a purple team session. Each missed technique becomes a concrete fix expressed as detection-as-code, for example a Sigma-style rule for the credential dump (T1003) that ran silently in the healthcare engagement above:
title: LSASS handle access by non-system process
tags: [attack.credential_access, attack.t1003.001]
logsource:
product: windows
service: sysmon
detection:
selection:
EventID: 10 # ProcessAccess
TargetImage|endswith: '\lsass.exe'
GrantedAccess: '0x1010' # read + query
condition: selection
level: highOther gaps close the same way: a SIEM rule for the LDAP recon storm (T1087/T1069), tighter segmentation between the user subnet and the finance zone, or removing the over-privileged service account that shortened the path to Domain Admin. The most common mistake is scoring an assumed breach like a pentest, by counting findings, and ignoring dwell time. The honest measure is how much faster you would catch the next intruder, and how many of this engagement's gaps you closed within 30 days.
Run an assumed breach assessment when you have internal detection and response worth testing and you want to know how an intrusion would actually play out inside your walls. It is the right choice if you have invested in EDR, a SIEM, network segmentation, and identity hardening, and you need evidence those controls would limit the damage of a foothold.
It is especially valuable when you assume the perimeter will eventually fail and want to test defense in depth, when you need to measure blast radius and validate segmentation between zones, when you want repeatable internal results to track detection improvements over time, or when a full red team is too slow or expensive for the cadence you need. If you have no internal detection capability yet, fix that first: an assumed breach against an unmonitored network will simply confirm the attacker reaches everything, which you already know. The assessment earns its value when there are real defenses to measure.