TL;DR
- ✓An assumed breach assessment hands the testers a starting foothold inside the network, skipping the initial-access phase entirely.
- ✓It assumes a breach is inevitable and focuses every hour on what happens next: detection, response, and how far an attacker can spread (blast radius).
- ✓It is more efficient than a full red team because no engagement time is spent trying to phish or exploit a way in.
- ✓Use it when you want to test internal detection and segmentation, not when you need to know whether your perimeter can be breached in the first place.
An assumed breach assessment starts the engagement with the attacker already inside, by handing testers a foothold (a low-privilege workstation, a set of valid credentials, or a planted implant), so that every hour of testing goes toward what happens after a breach rather than achieving one. The premise is the modern security reality: a determined attacker will eventually get in, so the more important question is how quickly you detect them and how far they can spread before you respond.
This guide explains how an assumed breach assessment works, why skipping initial access makes it more efficient, and where it fits between a standard penetration test and a full red team engagement. If you want to stress-test internal detection and segmentation without burning weeks on the front door, this is the model.
What is an assumed breach assessment?
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 spending the first weeks phishing or hunting for an exposed service, you grant a starting position and tell the team to work toward an objective from there.
The starting foothold is agreed in scoping and usually takes one of these forms:
- A standard domain-joined workstation with a low-privilege user account.
- A set of valid employee credentials, as if harvested in a phishing campaign.
- A planted implant or beacon 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 privileges, and moving laterally toward high-value targets, 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.
Why start with an assumed breach instead of testing initial access?
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 but 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 spent on initial access means more time on detection, lateral movement, and blast-radius analysis.
- Realism. Breaches happen. Assuming one is a more honest planning posture than hoping the perimeter holds.
- Coverage. You test the internal controls (segmentation, EDR, identity hardening) that a perimeter-focused test never reaches.
- Repeatability. A consistent starting foothold makes results comparable across assessments and over time.
This is why mature programs often pair a perimeter-focused external test with an assumed breach for the internal picture, covered further in our breakdown of the types of penetration testing.
Assumed breach vs full red team
| Aspect | Assumed breach | Full red team |
|---|
| Starting point | Foothold already granted | Starts from outside, zero access |
| Initial access tested? | No, skipped by design | Yes, core part of the test |
| Main focus | Detection, response, blast radius | Whole kill chain incl. perimeter |
| Cost and speed | Faster, cheaper, repeatable | Slower, broader, more variable |
| Best for | Testing internal defense in depth | Testing end-to-end adversary path |
What does an assumed breach assessment test?
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 of these 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 the internal reconnaissance, credential dumping, and lateral movement? Which ATT&CK techniques fire an alert and which pass silently?
- Lateral movement and privilege escalation. Can a low-privilege user reach Domain Admin? BloodHound is the standard tool for mapping these 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 the production or finance environment, or does network segmentation contain them?
- Response. Once activity is detected, how fast and how effectively does the incident-response process contain it?
The output is a clear picture of blast radius and a list of the exact detections and segmentation gaps that let it grow.
How is an assumed breach different from a full red team engagement?
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.
When should you run an assumed breach assessment?
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 that 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.
- You need to measure blast radius and validate network segmentation between zones.
- You want repeatable internal results to track detection improvements over time.
- 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 a network with no monitoring will simply confirm the attacker reaches everything, which you already know. The assessment earns its value when there are real defenses to measure.
Strobes insight
If you can only run one internal exercise this year, make it an assumed breach. The perimeter is a coin flip; the blast radius after a foothold is what actually determines how bad a breach becomes.
Frequently asked questions
What is an assumed breach assessment?
An assumed breach assessment is a security engagement that starts with the testers already holding a foothold inside the network, such as a low-privilege workstation or valid credentials. By skipping initial access, it focuses entirely on measuring detection, response, lateral movement, and blast radius, the things that determine how bad a real breach would become.
What is blast radius in an assumed breach assessment?
Blast radius is the set of systems, data, and privileges an attacker can reach starting from a single compromised foothold. Measuring it shows how far an intrusion would spread before being contained, which is the core output of an assumed breach assessment and a direct test of segmentation and least-privilege controls.
How is an assumed breach assessment different from a red team engagement?
A full red team engagement includes initial access and tests the perimeter, email security, and user awareness, while an assumed breach skips straight to post-compromise activity inside the network. Assumed breach is a focused, faster, more repeatable subset of red teaming that concentrates on internal detection, lateral movement, and blast radius.
Why would you assume a breach instead of testing if one is possible?
Because initial access is unpredictable and rarely the control that actually fails in a real incident, while internal detection and containment usually are. Assuming a breach lets the entire testing budget go toward the post-compromise phase where most organizations are blind, producing more useful findings than spending weeks trying to phish a way in.
When should a company run an assumed breach assessment?
Run one when you already have internal detection and response, EDR, a SIEM, segmentation, and identity hardening, and want evidence those controls would limit the damage of a foothold. It is less useful for organizations with no internal monitoring, who should build detection capability before testing how far an attacker can spread.
Does an assumed breach assessment skip phishing and perimeter testing?
Yes, by design. The starting foothold is granted in scoping, so no time is spent on phishing, exploiting exposed services, or testing the perimeter. That trade-off is the point: it concentrates the engagement on internal controls. Organizations that also want to test the perimeter pair it with an external test or a full red team.
Sources and references
A
Akhil Reni
Co-founder and CTO, Strobes
Akhil Reni is co-founder and CTO of Strobes, building AI-driven penetration testing and exposure management for security teams.
