Modern intrusions assume the attacker is already inside, so your test should too. Mandiant's M-Trends 2026 report, grounded in more than 500,000 hours of frontline incident response during 2025, found the median time between an attacker's initial access and hand-off to a second threat group has collapsed to 22 seconds, down from over eight hours in 2022. CrowdStrike's 2026 Global Threat Report puts the average eCrime breakout time, the window before an intruder pivots off the first host, at 29 minutes, with the fastest observed breakout at just 27 seconds. Perimeter break-ins are no longer the interesting part of an attack. What happens after the first foothold is.
An assumed breach engagement is built for exactly that question. Instead of spending days or weeks earning a foothold, the tester is granted one and starts from inside, so the engagement measures detection, response, and lateral-movement containment where real damage is done. This guide explains what an assumed breach engagement is, what it scopes, what you receive, and how to decide between it and a full kill-chain red team.
What is an assumed breach engagement?
An assumed breach engagement is a focused offensive-security test that begins from a realistic internal foothold rather than from the public internet. The client and the testing team agree on a starting position, for example a standard employee workstation, a set of low-privilege credentials, or an authenticated application session, and the tester works from there toward defined objectives such as reaching a crown-jewel system or a marked dataset.
Because the initial access step is granted rather than earned, the engagement concentrates every hour on the post-compromise phase: privilege escalation, credential access, lateral movement, and, most importantly, whether your detection and response program notices and contains the activity. It answers a sharper question than a perimeter test: once someone is inside, how far can they get, and how fast do you catch them?
This model reflects how attackers actually operate. The CISA, FBI, and partner advisory on Scattered Spider (AA23-320A), updated in July 2025, documents a group that routinely obtains valid accounts through help-desk social engineering, push-notification fatigue, and SIM swaps, then uses those legitimate credentials to move through the environment. When the front door is a stolen login, testing only the perimeter tells you very little about your real exposure.
Assumed breach vs full red team: how to choose
The two engagement types overlap but answer different questions. A full red team validates the entire kill chain, from reconnaissance and initial access through to impact, including your perimeter and human layer. An assumed breach engagement skips the break-in and invests that time in the internal blast radius. The table below maps the practical trade-offs.
Dimension | Assumed breach engagement | Full red team |
|---|---|---|
Starting point | A realistic internal foothold that is granted at kickoff | External, from open-source reconnaissance and an earned initial access |
Primary question | Once someone is inside, how far can they get and how fast do we catch them? | Can a determined adversary breach us end to end without being caught? |
Tests the perimeter and initial access | No, access is provided | Yes, this is part of the objective |
Depth on detection, lateral movement, and containment | High, most of the effort lands here | High, but a share of effort is spent getting in |
Human layer and social engineering | Usually out of scope | Often in scope |
Typical duration | Shorter | Longer |
Relative cost | Lower | Higher |
Best fit | Teams tuning detection and response, or wanting predictable coverage of the internal blast radius | Mature programs validating the full chain, including perimeter and people |
If your real goal is to settle the broader question of red team versus penetration test versus continuous validation, that comparison deserves its own treatment. We cover it in depth in Red Team vs Penetration Test vs Continuous Validation. This guide stays narrow: assumed breach, and when to reach for it.
What an assumed breach engagement scopes
Scoping an assumed breach engagement is mostly about agreeing on two things up front: where the tester starts, and what counts as success. Getting these right is the difference between a report full of theoretical findings and one that maps directly to your detection gaps. If you are new to scoping offensive tests, our guide on how to scope a penetration test covers the mechanics that carry over here.
A well-scoped engagement typically defines:
The foothold. The agreed starting position. Common choices are a managed workstation with a standard user profile, a set of employee-level credentials, a virtual machine placed in a representative network segment, or an authenticated session to a target application. The foothold should mirror the most likely real-world entry point for your organisation.
The objectives. Concrete flags such as reaching domain administrator, accessing a specific database, compromising a segmented environment, or exfiltrating a marked file. Objectives keep the test outcome-driven rather than open-ended.
The rules of engagement. Time window, deconfliction contacts, whether the blue team is informed (a known test) or not (double-blind), and any systems that are off limits.
The visibility model. Whether the exercise runs as a pure red team or shifts into a purple-team replay, where operators and defenders review the timeline together to tune detections.
Deliverables you should expect
The output of an assumed breach engagement is a story about your internal defences, not just a vulnerability list. A credible engagement delivers:
An attack narrative. A step-by-step timeline from the foothold to each objective, showing exactly how the tester escalated and moved.
A detection gap analysis. What alerts fired, what should have fired and did not, and where in the chain your team could have contained the activity. Findings are measured against your own detection and response metrics rather than any invented benchmark.
Prioritised, fixable findings. Each issue tied to a concrete remediation, ranked by the risk it introduced to the objective.
A blue-team debrief. A working session to walk defenders through the timeline, ideal for converting findings into new detection rules.
Compliance-ready evidence. A report your team can use to support a SOC 2, ISO 27001, PCI DSS 4.0, or DORA threat-led testing program.
A retest path. Confirmation that the highest-risk findings were closed after remediation.
When to pick assumed breach, and when you still need a full red team
Reach for an assumed breach engagement when the internal blast radius is your priority. It is the efficient choice when you are standing up or tuning a detection and response capability, when you have already tested the perimeter recently, when you need predictable coverage of lateral movement within a fixed budget, or when a specific segmentation or identity control needs to be proven under realistic pressure.
Choose a full red team when the question is whether an adversary can breach you end to end. If you need to validate the perimeter, test your people against social engineering, or produce the kind of full-chain evidence that regulators and boards expect from a mature program, the break-in phase is part of the point and should not be skipped. Frameworks such as the EU's DORA threat-led penetration testing lean toward this fuller scope.
Many organisations run both on a cycle: a full red team to validate the whole chain periodically, and more frequent assumed breach engagements to keep detection and response sharp between those larger exercises. If you are weighing cadence, our comparison of continuous red teaming versus the annual pentest is a useful next read.
How Stingrai runs assumed breach work
Stingrai is a CREST-accredited offensive-security firm founded in 2021, with teams in Toronto and London. Our assumed breach engagements are driven by senior human operators who own the internal, Active Directory, and cloud-lateral-movement work, the parts of the environment where escalation and containment are decided. They plant the agreed foothold, pursue the objectives, and sit down with your defenders to turn the timeline into stronger detections.
Where an engagement touches the web-application layer of your environment, our autonomous agent Snipe extends that coverage. Snipe is purpose-built to hunt complex, high-impact web vulnerabilities such as IDOR, broken authorization, and business-logic flaws, and it can run black-box and white-box testing on the applications in scope while the operators focus on the internal chain. The result is broad coverage without diluting the senior human judgment that makes an assumed breach report actionable.
Assumed breach fits naturally alongside our broader red teaming and PTaaS programs, and it produces evidence that supports your compliance objectives across SOC 2, ISO 27001, PCI DSS 4.0, and DORA. For engagement sizing and packages, see the Stingrai pricing page.
Frequently asked questions
What is an assumed breach engagement?
An assumed breach engagement is an offensive-security test that begins from a realistic internal foothold, such as a standard workstation or a set of employee-level credentials, rather than from the public internet. Because access is granted at kickoff, the engagement spends its time on privilege escalation, lateral movement, and whether your detection and response program catches and contains the activity. It measures the internal blast radius, the part of an attack where, per Mandiant's M-Trends 2026, adversaries now hand off access in as little as 22 seconds.
What is the difference between an assumed breach engagement and a full red team?
A full red team tests the entire kill chain, from reconnaissance and initial access through to impact, including your perimeter and your people. An assumed breach engagement skips the break-in and invests that time in the internal phase. Assumed breach answers "how far can an intruder get once inside, and how fast do we catch them," while a full red team answers "can an adversary breach us end to end without detection." Assumed breach is typically faster and lower cost as a result.
When should I choose an assumed breach engagement instead of a full red team?
Choose assumed breach when the internal blast radius is your priority: you are tuning detection and response, you tested the perimeter recently, or you need predictable coverage of lateral movement within a fixed budget. Choose a full red team when you need to validate the perimeter, test your people against social engineering, or produce full-chain evidence for a mature program. Many teams run both on a cycle.
How does an assumed breach engagement start?
It starts from a foothold agreed during scoping. Common starting positions include a managed workstation with a standard user profile, low-privilege employee credentials, a virtual machine placed in a representative segment, or an authenticated application session. The foothold is chosen to mirror the most likely real-world entry point, which increasingly means a valid account obtained through social engineering, as documented in the CISA and FBI Scattered Spider advisory.
What deliverables do you get from an assumed breach engagement?
You receive an attack narrative that traces the path from foothold to each objective, a detection gap analysis showing what fired and what did not, prioritised and fixable findings, a blue-team debrief to convert findings into detections, compliance-ready evidence, and a retest path for the highest-risk issues. The output is a story about your internal defences, measured against your own metrics, not a raw vulnerability dump.
Is an assumed breach engagement cheaper than a full red team?
Generally yes. Because the initial access phase is granted rather than earned, an assumed breach engagement removes the most time-consuming part of a full red team and concentrates effort on the internal chain. That usually makes it shorter and lower cost. Exact scope drives the price, so engagement sizing is best confirmed against current packages on the Stingrai pricing page.
Does an assumed breach engagement test detection and response?
Yes, that is its core purpose. By starting inside, the engagement stress-tests exactly the controls that decide an incident's outcome: endpoint and identity detections, alerting, analyst response, and network segmentation. With attacker breakout times now averaging 29 minutes per CrowdStrike's 2026 Global Threat Report, the speed and completeness of your internal response is often the difference between a contained event and a full compromise.
Is an assumed breach engagement the same as post-compromise or purple teaming?
They are closely related. "Post-compromise" describes the phase an assumed breach engagement focuses on. Purple teaming describes a collaborative mode where operators and defenders review activity together in real time to tune detections. An assumed breach engagement can run as a pure red team or shift into a purple-team replay, depending on whether you want an unbiased measure of detection or a hands-on tuning session.
References
Mandiant (Google Cloud). M-Trends 2026: Data, Insights, and Strategies From the Frontlines. March 2026. https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026. Frontline incident-response findings from over 500,000 hours of 2025 investigations, including global median dwell time and attacker access hand-off timing.
CrowdStrike. 2026 Global Threat Report. February 2026. https://www.crowdstrike.com/en-us/global-threat-report/. Adversary tradecraft analysis, including average and fastest eCrime breakout times and the shift toward identity-based intrusions.
Verizon. 2026 Data Breach Investigations Report. May 2026. https://www.verizon.com/business/resources/reports/dbir/. Analysis of breach entry points, including vulnerability exploitation, credential abuse, and third-party involvement.
CISA, FBI, and partners. Scattered Spider (AA23-320A). Updated July 2025. https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a. Joint advisory documenting valid-account initial access via help-desk social engineering, push-notification fatigue, and SIM swaps.
