Is assumed breach the same as a red team engagement?

They overlap but they are not synonyms. A red team engagement tests detection and response against a goal, usually covertly and often starting from outside. Assumed breach describes the starting assumption, and can be applied to a red team engagement, a penetration test, or a purple team exercise. Many red team engagements begin with an assumed breach phase specifically so the schedule is not consumed by gaining initial access.

Why grant the attacker access at the start of the test?

Because initial access is the least informative part of an engagement. Given enough time, phishing, a stolen session token or an unpatched edge device tends to work, so spending the budget proving it produces a result you could have assumed. Granting the foothold moves the entire schedule to the questions that decide how severe a real incident is: reach, privilege, and detection. Regulators accept the same logic: TIBER-EU provides for leg-ups precisely so a test is not wasted on obtaining access.

What foothold is usually granted?

Whatever most closely matches a realistic compromise for that environment. Commonly a standard domain user account, a managed corporate laptop build, a set of credentials of the kind an infostealer produces, or a container or workload identity inside the environment. It is agreed during scoping, and the level chosen should reflect what an attacker would plausibly obtain rather than what is convenient to provide.

How much access is too much to grant?

Any level that makes the result unfalsifiable. If the foothold is a privileged account, everything will be reachable and the assessment proves only that administrators can administer. The test of whether a starting position is reasonable is whether you can describe the real-world event that would produce it. A phished employee produces a standard user; nothing ordinary produces a domain administrator.

Does an assumed breach test replace a penetration test?

No. They answer different questions. A penetration test tells you whether a system or perimeter can be broken. An assumed breach assessment tells you what happens after one is. Organisations with weak external hygiene generally get more from conventional testing first, because an assumed breach engagement will succeed easily and teach them less.

How is assumed breach related to zero trust?

Zero trust is an architecture built on the premise that no network location is inherently trustworthy, set out in NIST SP 800-207. Assumed breach is how that premise gets tested. Implementing zero trust without ever running an assumed breach exercise leaves you with a design you believe in and no evidence it behaves as designed, which is the failure mode most zero trust programmes actually hit.

Will the security team know the test is happening?

That is a scoping decision with real consequences either way. Announced, the exercise becomes collaborative and is better at improving detection rules quickly. Unannounced, it produces a more honest measurement of what the team notices under normal conditions, at the cost of consuming their time on what they believe is a genuine incident. Either is defensible; deciding by default is not.

What happens if the security team detects the test immediately?

That is a good result, and it should be recorded as one rather than worked around. The exercise then shifts to what happens next: whether the alert reached a human, how quickly, whether the response contained the activity or only observed it, and whether the same detection holds against a variation of the technique. An engagement that quietly evades detection to keep going has discarded the most valuable finding it produced.

Can assumed breach testing run against cloud environments?

Yes, and the model translates cleanly because cloud has no perimeter to argue about. The foothold becomes a workload identity, a container, a compromised developer account or an over-permissive role, and the equivalent of domain compromise is durable control of the tenancy or subscription. The metrics are unchanged. What differs is that identity and the control plane matter more than network position, so a single role assignment can be worth more than any firewall rule.

Is it safe to run in production?

It is the only place the result means anything, which is why DORA requires threat-led testing to cover live production systems and excludes staging. Safety comes from the rules of engagement rather than from the environment: agreed destructive actions excluded, a named contact reachable at any hour, a deconfliction process, and defined conditions that pause the exercise. A provider unwilling to discuss those in detail before starting is the actual risk.

How do you measure time to detection fairly?

Measure to the moment a human begins acting, not to the moment an alert fires, and record both so the gap between them is visible. That gap is frequently the finding. It also requires the testers to log their own actions with timestamps, so the defensive timeline can be compared against what actually happened rather than against what was reconstructed afterwards.

What does the assessment produce?

The attack paths found, with the evidence for each one, the reach and privilege each path produces, what was detected and when, and remediation ordered by the reduction in reach it achieves rather than by raw severity score. The ordering matters: fixing the one misconfiguration that collapses six separate paths is worth more than fixing three unrelated high-severity findings.

Why prioritise by reach rather than by CVSS score?

Because severity scores describe a vulnerability in isolation and attack paths are chains. A medium-severity misconfiguration that appears in six of eight paths is worth more attention than an unconnected critical, since removing it collapses six routes at once. Reporting by score alone produces a remediation queue sorted by something other than how much it reduces risk.

Who should own the findings inside the organisation?

Whoever can change how privilege and segmentation work, which is usually not the team that commissioned the test. These engagements produce structural findings rather than patch-level ones, so an owner without the authority to change identity design or network boundaries can only escalate. Agreeing that owner before the engagement is one of the better predictors of whether anything changes afterwards.

How often should an assumed breach assessment be repeated?

The useful trigger is change rather than the calendar. A new identity provider, a cloud migration, a merger, or a significant change to privileged access all invalidate the previous result, because they change the paths. Repeating on a fixed schedule while the environment sits still mostly reconfirms the last report. Where a regulator sets a floor, as DORA does with a three-year cycle for designated entities, that is a minimum rather than a recommendation.

Is assumed breach required by any regulation?

Not under that name, but the shape of it is mandated in several places. DORA requires threat-led penetration testing every three years for designated financial entities in the EU, built on TIBER-EU, whose leg-up provision explicitly allows granting access. CBEST is the equivalent framework in the UK. PCI DSS requires segmentation testing annually, or every six months for service providers, which can only be answered by testing from inside a segment.

Methodology

What is assumed breach?

The testing model that starts inside the network instead of outside it: what it measures, how it differs from a penetration test and from zero trust, what the attack path looks like, what you need to log to measure detection, and when it is the wrong thing to buy.

Assumed breach is a security testing model that begins from the position that an attacker is already inside the network, and measures what happens next: how far they can move, what they can reach, and whether anyone notices.

Assumed Breach is a cybersecurity consultancy named after that model. It is also the model our engagements are built on: we start inside, and we report what the inside of your network is actually worth to an attacker.

Key takeaways

Assumed breach grants the attacker a starting foothold instead of spending the engagement proving one can be obtained, because initial access is the least informative part of a test.
An assumed breach assessment measures four things: blast radius, time to privileged control, time to detection, and which controls actually fired rather than merely being deployed.
Assumed breach is not a synonym for red teaming. Red teaming is an engagement type; assumed breach is the starting assumption, and it can be applied to a red team, a penetration test or a purple team exercise.
Zero trust is the architecture, assumed breach is how you find out whether the architecture works. Implementing one without the other leaves you with a design you believe in and no evidence.
Assumed breach testing is the wrong purchase for an organisation with weak external hygiene, no asset inventory and no usable logging, because the engagement will succeed easily and teach very little.

Reviewed 24 August 2026

The model

What is assumed breach?

The name describes the assumption you start with rather than the technique you use. A conventional security test asks whether an attacker can get in. An assumed breach test grants that they already have, then asks the questions that decide how bad a real incident becomes: what does a single compromised laptop reach, how long does it take to reach a domain admin, which controls actually fire, and what does the security team see while it happens.

The assumption is not pessimism. It is arithmetic. An attacker needs one route to work once; a defender needs every route closed every day. Any organisation large enough to have a help desk, a supplier, or an employee who can be phished should plan on the basis that the perimeter will be crossed at some point, because over a long enough period it usually is.

It is worth being precise about what the model is and is not, because the phrase gets stretched. Assumed breach is a starting condition, not an engagement type, not a product, and not a compliance category. You can run a penetration test, a red team operation or a purple team exercise from an assumed breach position. What changes is where the clock starts.

Where does the idea come from?

The phrase entered mainstream use through Microsoft, whose security engineering teams adopted an assume breach posture and wrote publicly about running internal red teams against their own production services on that basis. The same principle underpins zero trust architecture, described in NIST Special Publication 800-207, which starts from the position that no network location can be treated as inherently trustworthy.

None of that is new as an idea. Defence in depth and least privilege both assume that outer controls fail. What changed is that the assumption moved from a design principle nobody tested into something organisations deliberately measure, because cloud, remote work and supply chains dissolved the perimeter that prevention-first security had been organised around.

The distinction worth holding on to: zero trust is an architecture, and assumed breach is how you find out whether that architecture works. One is what you build. The other is what tells you whether you built it correctly.

Regulators arrived at the same conclusion independently, and their frameworks now encode it. The European Central Bank's TIBER-EU framework provides for leg-ups, where the testers are granted assistance or access when they cannot reach an objective in the time allowed, precisely so the exercise can still measure what happens after access rather than stalling on getting it.

How is it different from prevention-first security?

Prevention-first security spends its budget on keeping attackers out, and measures success by the absence of a known incident. The weakness is not that prevention is wrong, it is that the metric is unfalsifiable. Nothing has happened is equally consistent with strong controls and with an intrusion nobody has detected.

Assumed breach replaces that with something measurable. Instead of asking whether you are secure, it asks how much an attacker gains from a foothold, and how quickly you find out. Those are questions with answers, and the answers change when you fix something, which is what makes them useful to report to a board.

Prevention asks: can they get in? Assumed breach asks: what happens when they do?
Prevention is measured by incidents avoided, which cannot be counted. Assumed breach is measured by reach, privilege gained and time to detection, which can.
Prevention treats the perimeter as the control. Assumed breach treats segmentation, privilege boundaries and detection as the controls, because those are what still apply once the perimeter is behind the attacker.
Prevention produces a finding list that resets every year. Assumed breach produces a number that can be tracked across years and compared after remediation.

Assumed breach vs a traditional penetration test

The two overlap, and plenty of engagements sold as penetration tests include an assumed breach phase. The difference is where the starting line is drawn, and therefore what the engagement can tell you.

Aspect	Traditional penetration test	Assumed breach assessment
Starting position	Outside, with no access. Time is spent finding a way in.	Inside, with an agreed foothold. Time is spent on what comes after.
Core question	Can the perimeter be broken?	What is the inside worth once it has been?
Typical outcome	A list of vulnerabilities, ranked by severity.	A set of attack paths, with the reach and privilege each one produces.
Detection	Often out of scope, and frequently the tester avoids alerting on purpose.	Explicitly in scope. What the security team saw is part of the result.
Fails usefully when	Nothing is found, which says the perimeter held on the days tested.	Nothing is reachable, which says segmentation and privilege boundaries hold.
Best used when	A specific system, application or perimeter needs depth.	The organisation as a whole needs to know its blast radius.

Assumed breach vs zero trust

These get used interchangeably and they are not the same kind of thing. One is an architecture you implement; the other is a testing model that tells you whether the implementation is real.

Aspect	Zero trust	Assumed breach
What it is	An architectural model. Verify every request explicitly, regardless of network location.	A testing and operating model. Start from the assumption that compromise has already happened.
Produces	Design decisions: identity-aware access, micro-segmentation, continuous verification.	Evidence: attack paths, reachable assets, detection gaps.
Answers	How should access be granted?	Does access actually work the way the design says?
Reference	NIST SP 800-207 sets out the architecture and its components.	No single standard. TIBER-EU, CBEST and DORA encode the closest regulated form.
Relationship	Built on the same premise: no location is inherently trusted.	The way that premise gets verified rather than assumed.

Assumed breach vs adversary emulation, purple teaming and BAS

This is the comparison buyers get wrong most often, because four vendors will sell four different things under overlapping language. The useful way to separate them is by what each one is optimised to produce.

Aspect	What it optimises for	Where assumed breach fits
Red teaming	Testing detection and response against a goal, usually covertly, judged on whether the objective was reached without being stopped.	An engagement type. Assumed breach is a common starting condition for one, so the schedule is not consumed by gaining access.
Adversary emulation	Reproducing a named threat actor's known behaviour, so defences are tested against what that group actually does.	Compatible. Emulation chooses which techniques to use; assumed breach chooses where to start using them.
Purple teaming	Attack and defence working together in the open, tuning detections technique by technique in a feedback loop.	Highly compatible, and often the better second engagement. An assumed breach test finds the gaps; a purple exercise closes them.
Breach and attack simulation	Continuous automated execution of known techniques, giving coverage and repeatability without a human operator.	Complementary, not a substitute. Automation runs known techniques; it does not chain unexpected misconfigurations the way an operator does.
Threat hunting	Searching existing telemetry for intrusions that were never alerted on, assuming compromise has already occurred.	The defensive twin. Same assumption, opposite direction: hunting looks for the attacker, assumed breach plays them.
Vulnerability assessment	Enumerating known vulnerabilities broadly and cheaply across an estate.	A prerequisite, not a peer. Run this first if the basics are unknown.

The engagement

What does an assumed breach assessment actually involve?

The engagement starts where a real intrusion starts on day two, not day one. Rather than spending the schedule on gaining an initial foothold, the client provides one, and the whole budget goes into what an attacker would do with it.

The foothold is agreed during scoping. It is usually a standard user account, a build of a corporate laptop, a container in the environment, or a set of credentials of the kind that phishing or an infostealer routinely produces. The point of granting it is efficiency: the initial access step is the least informative part of a test, because it is the part everybody already accepts will eventually succeed.

Establish the foothold and enumerate what it can see, without triggering anything that would be unfair to the detection question.
Escalate privilege locally and then within the domain or cloud tenancy, recording every path found rather than stopping at the first one that works.
Move laterally, mapping which segmentation boundaries hold and which are boundaries only on the network diagram.
Reach the assets that matter, defined during scoping in business terms: the customer database, the payment path, the source repository, the backup system.
Track what the security team detected, when, and what they did with the alert. This half is frequently more valuable than the attack path itself.
Report the paths, the proof, the fixes, and the order to do them in.

What does the attack path look like?

A concrete chain, with the MITRE ATT&CK technique for each step. Technique identifiers are included because they are the shared vocabulary between an offensive report and a detection team's backlog: a finding that names T1558.003 can be handed straight to whoever owns the detection content.

This is the ordinary case rather than a highlight reel. It is also, step for step, the path that most first engagements actually follow.

Stage	Technique	What happens	What it establishes
Foothold	Valid AccountsT1078	Start as an ordinary domain user on a standard corporate laptop build, the position a phished employee or an infostealer log would produce.	Establishes the baseline. Everything that follows is reachable from an account with no special privilege.
Situational awareness	Domain Trust Discovery, Account DiscoveryT1482, T1087	Enumerate users, groups, machines, trusts, shares and access control lists from the standard account, without touching anything privileged.	How much of the estate is visible to any employee. This step alone regularly maps the whole privilege structure.
Credential access	KerberoastingT1558.003	Request service tickets for accounts with service principal names and attempt offline recovery of weak passwords.	Whether service accounts have strong, rotated credentials, and whether anomalous ticket requests are alerted on.
Privilege escalation	Exploitation for Privilege Escalation, Abuse Elevation ControlT1068, T1548	Escalate on the local host through a misconfigured service, an unquoted path, a writable directory in the search path, or a missing patch.	Whether endpoint hardening is real or assumed, and whether EDR flags local escalation.
Credential harvesting	OS Credential DumpingT1003	Recover credentials and tokens cached on the compromised host, including any left by a privileged user who logged in previously.	Whether privileged accounts are exposed on ordinary workstations. This is the single most common escalation route we find.
Lateral movement	Remote Services, Use Alternate Authentication MaterialT1021, T1550	Authenticate to other hosts using recovered material, crossing from the workstation network into server or management segments.	Whether segmentation boundaries hold in practice, or exist only on the network diagram.
Domain or tenancy control	Domain Policy Modification, Additional Cloud CredentialsT1484, T1098.001	Convert accumulated access into durable administrative control of the directory or the cloud tenancy.	The end of the path. From here every remaining objective is reachable, which is why time-to-this-point is the headline metric.
Objective	Data from Information RepositoriesT1213	Reach the assets defined as mattering during scoping: the customer database, the payment path, the source repository, the backup system.	Translates technical compromise into the business consequence, which is the only form the finding is useful to a board in.

What foothold should be granted?

The level chosen should reflect what an attacker would plausibly obtain, not what is convenient to provide. Granting too much makes the result unfalsifiable, because everything is reachable from a position no real attacker would start in. Granting too little reintroduces the initial access problem the model exists to skip.

In practice the choice is between a small number of realistic starting positions, and it is worth deciding deliberately rather than accepting whatever the provider proposes.

Standard domain user, no local administrator. The default, and the right choice for most first engagements. It answers what any employee's account is worth.
Managed endpoint, unprivileged. A real corporate build with the real agent stack, which additionally tests whether endpoint controls are configured as intended rather than merely installed.
Contractor or third-party account. Models supply chain compromise, and frequently reveals privilege granted for a project that ended years ago.
Workload or container identity inside the environment. The cloud-native equivalent, and the right start for testing whether a compromised service can reach the control plane.
Developer or engineer account. Deliberately harder, and worth doing once the standard-user path has been fixed, because it models the account an attacker would target second.

What does it measure?

Four numbers carry most of the value, and all four are comparable between one assessment and the next, which is what makes them worth tracking over time rather than reading once. Defining them precisely matters, because vague versions of these metrics are easy to report and impossible to act on.

Blast radius: the set of systems, data and identities reachable from one compromised identity or host, counted rather than described. The result that most often surprises people is how rarely the answer is not much.
Time to privileged control: elapsed operator time from the granted foothold to durable administrative control of the directory or cloud tenancy, and how many distinct paths reach it. The path count matters more than the time, because a single path is a single fix.
Time to detection: elapsed time between an action that should have alerted and a human beginning to act on it. Measured to the human, not to the alert, because an alert nobody triages is the same outcome as no alert.
Control efficacy: which controls fired, which fired but were not routed anywhere, and which were deployed and licensed but silent. The middle category is the common one and the one nobody discovers without testing.

Running it well

What should you prepare before the engagement?

Most of the value lost in these engagements is lost before they start, in scoping. An assessment that begins without these decisions made produces a technically accurate report that nobody can act on, because nothing in it is tied to anything the business cares about.

Name the assets that matter, in business terms. Not the customer database server, but customer records. The technical target follows from the business one, and stating it the other way round is how engagements end up proving access to something nobody minds losing.
Decide the foothold and write down why that level was chosen. It is the single assumption the entire result rests on.
Decide whether the security team is told. Both answers are defensible; deciding by default is not, and the consequences differ sharply.
Agree what stops the test. Rules of engagement should name the actions that are out of bounds and the conditions under which the exercise pauses, before anyone is under pressure.
Confirm logging is on and retained for the window the test will cover. A detection finding is worthless if the answer turns out to be that the logs were never collected.
Nominate a control contact who can be reached at any hour, and a channel that does not depend on the systems being tested.
Agree the deconfliction process, so a real incident during the test window can be separated from the test immediately rather than after an hour of uncertainty.
Decide in advance who receives the report, and whether a retest is in scope. Findings without a verification path tend to stay findings.

What do you need to log for detection to be measurable?

Detection cannot be measured if the evidence was never collected, and the most common outcome of the detection half of an assessment is not that alerting failed but that the data source was absent. Most detection stacks are tuned for initial access, which is the phase an assumed breach engagement skips, so the middle of the attack is exactly where telemetry tends to run out.

The list below is the minimum that makes the four metrics answerable. It is deliberately short: this is what has to exist for the exercise to produce a number, not a complete detection engineering programme.

Authentication events across the whole estate, including failures, and including workstation to workstation. Successful lateral authentication is invisible if only servers are collected.
Kerberos service ticket requests, which is what makes Kerberoasting detectable at all, and which are commonly not forwarded.
Process creation with full command lines, plus script block logging where PowerShell is present. Without command lines, process telemetry records that something ran and not what it did.
Privileged group membership changes and the assignment of sensitive rights, alerted on rather than merely stored.
Remote service creation and scheduled task creation, the two most durable and most frequently missed persistence mechanisms.
Cloud control plane audit logs, including role assignments, key and token creation, and consent grants for applications.
Retention that covers the engagement window and the investigation that follows it. Telemetry that has already rolled over cannot answer whether anything was seen.
A record of which alerts were routed to a human and what they did, because the metric is time to human action rather than time to alert.

How do you operationalise assumed breach?

Running one assessment produces a report. Operationalising the model means changing what the organisation treats as normal, and that is mostly a set of standing decisions rather than a project.

Segment on the assumption that any one segment is already hostile, and test the boundaries rather than trusting the diagram.
Make privilege temporary by default. Standing administrative access is the single most common reason a small foothold becomes a total compromise.
Keep privileged credentials off ordinary workstations, using separate administrative accounts and dedicated administration hosts, because credential reuse across tiers is what turns one machine into all of them.
Instrument for the middle of an attack, not the start of it. Most detection is tuned for initial access; lateral movement and privilege escalation are where the dwell time actually accumulates.
Rehearse the response, not only the defence. A detection nobody triages is the same outcome as no detection, and only an exercise reveals which one you have.
Treat identity as the perimeter, in the cloud especially, where a role assignment can be worth more than any network control.
Retest after remediation. A fix that was never verified against the path that found it is a belief, not a control.

Where are you on the maturity curve?

Locating yourself matters more than it sounds, because the right next step differs completely between levels and the wrong one wastes a budget. Level 1 is the normal starting point for a first engagement.

L0Unmeasured
No asset inventory, no reliable logging, internet-facing systems of unknown patch state. Security is assumed to work because nothing has visibly failed.
Next step
Do not commission an assumed breach engagement yet. Inventory, patching and log collection return more per pound spent, and an assumed breach test here only confirms what is already suspected.
L1Prevention established
Patching is routine, endpoints are managed, multi-factor authentication is broadly deployed. Testing is periodic and perimeter-focused, and the results are vulnerability lists.
Next step
A first assumed breach assessment from a standard user account. Expect the blast radius to be larger than the architecture diagram suggests. This is the normal starting point.
L2Blast radius known
The reach of an ordinary account has been measured at least once. Segmentation and privilege problems are documented, and some have owners.
Next step
Fix the paths that collapse the most reach, then retest against those specific paths. Begin measuring time to detection deliberately rather than incidentally.
L3Detection measured
Telemetry covers lateral movement and privilege escalation, not just initial access. Time to detection is a tracked number, and alerts reliably reach a human.
Next step
Purple team the gaps technique by technique, and extend the model to the cloud control plane and the identity provider if it has not been already.
L4Assumed breach as standing posture
Privilege is temporary by default, segmentation is tested rather than diagrammed, and exercises are triggered by architectural change rather than by the calendar.
Next step
Vary the starting position: contractor accounts, workload identities, developer access. The interesting question is no longer the standard user, because that path is closed.

Buying it

When is assumed breach the wrong choice?

It is not the right test for every organisation, and pretending otherwise would make the rest of this page less useful.

If you have no asset inventory, no logging worth querying, and unpatched systems facing the internet, an assumed breach engagement will succeed comprehensively and tell you very little you did not already suspect. Vulnerability assessment and basic hygiene are better value first. The model earns its cost once prevention is genuinely decent, because that is the point at which can they get in stops being the interesting question.

It is also the wrong shape when a specific product needs depth rather than breadth. If the question is whether a particular web application or API can be broken, test that application directly. Assumed breach is an organisational question, not an application one.

And it is the wrong purchase if the organisation cannot act on the result. These engagements produce structural findings, and structural findings need an owner with the authority to change how privilege and segmentation work. Without that, the report describes problems nobody is empowered to fix.

How do you tell a good assumed breach engagement from a bad one?

The market for this is uneven, and the difference between an engagement that changes something and one that produces a formatted vulnerability scan is mostly visible before you sign. What follows is what to look for and what should give you pause, stated plainly enough to be used as a checklist against any provider, including us.

Signs it is being done properly

Scoping starts with which assets matter to the business, not with an IP range.
The foothold level is proposed with a reason attached, and can be argued about.
Detection and response are in scope explicitly, with agreement on how time to detection will be measured.
Attack paths are reported as chains, with the specific misconfiguration that enables each hop.
Findings are prioritised by how much reach a fix removes, not by raw CVSS score.
Techniques are mapped to a shared vocabulary such as MITRE ATT&CK, so detection engineers can act on the report directly.
Rules of engagement, deconfliction and an out-of-hours contact are agreed in writing before the start.
A retest path exists, so remediation can be verified against the path that found it.
The provider is willing to tell you when this is not the engagement you need.

Signs to ask harder questions

A quoted price and scope before anyone has asked what you are trying to protect.
The word automated doing heavy lifting in the description of methodology.
A report that is a tool export with a cover page, where findings are listed individually and never chained.
No discussion of what happens if the security team detects and responds during the test.
Claims about detection outcomes made before the environment has been seen.
Reluctance to describe the rules of engagement, or to name what would stop the test.
A deliverable that ends at findings, with no remediation ordering and no retest.
Every engagement scoped identically regardless of what the organisation does.

Where is this shape of testing required?

Not under the name assumed breach, but the shape of it is mandated in several places. Regulators reached the same conclusion independently, and in TIBER-EU's case wrote the granting of access directly into the framework.

DORA, threat-led penetration testing

European Union

Applies to: Financial entities designated as significant by their competent authority.

Article 26 requires threat-led penetration testing at least every three years, with the frequency adjustable by the competent authority on a risk basis. Testing must cover live production systems supporting critical or important functions, and staging environments do not qualify. The technical standards are set out in Commission Delegated Regulation (EU) 2025/1190, applicable from 8 July 2025, and require an independent threat intelligence provider separate from the red team provider.

TIBER-EU

European Union, adopted nationally

Applies to: The framework DORA's threat-led testing is built on.

TIBER-EU provides for leg-ups: assistance or access granted to the red team where an objective cannot be reached within the planned timeline. Each leg-up must state what it entails, who grants it, by when, and under what protocol. This is the assumed breach principle written into a regulatory framework, and it exists for the same reason the model does, so the exercise measures what happens after access rather than stalling on obtaining it.

CBEST

United Kingdom

Applies to: Firms whose disruption would threaten UK financial stability.

The Bank of England's intelligence-led testing framework, and the model TIBER-EU drew on. Same structure: threat intelligence informs realistic scenarios, and a separate red team executes them against live systems under controlled conditions.

PCI DSS v4.0, segmentation testing

Global, card payment environments

Applies to: Any organisation using segmentation to reduce cardholder data environment scope.

Requirement 11.4.5 requires segmentation controls to be tested at least annually and after any change; 11.4.6 raises that to every six months for service providers. Segmentation testing is assumed breach in miniature: it is only answerable by starting inside an out-of-scope segment and establishing what can be reached from there.

Reference

Glossary

The terms this page uses, defined here so a follow-up question can be answered from the same source as the parent concept.

Blast radius: The set of systems, data and identities reachable from a single compromised host or account. The primary output of an assumed breach assessment.
Foothold: The starting access granted at the beginning of an assumed breach engagement, chosen to match what an attacker would plausibly obtain rather than what is convenient to provide.
Lateral movement: Moving from one compromised system to another within an environment, typically using credentials or authentication material recovered along the way.
Privilege escalation: Gaining rights beyond those originally held, either on a single host or across a directory or cloud tenancy.
Dwell time: The period between an attacker gaining access and being detected. The metric assumed breach testing is designed to make measurable in advance rather than after an incident.
Segmentation: Dividing a network so that compromise of one part does not grant access to another. Frequently present on the diagram and absent in practice, which is why it is tested rather than reviewed.
Leg-up: In TIBER-EU, assistance or access granted to a red team when an objective cannot be reached within the planned timeline. The assumed breach principle expressed inside a regulatory framework.
Purple team: An exercise where offensive and defensive teams work together openly, tuning detection technique by technique, rather than the attacker operating covertly.
Adversary emulation: Reproducing the known behaviour of a specific threat actor, so that defences are tested against what that group actually does rather than against generic technique.
Rules of engagement: The written agreement covering what testers may do, what is out of bounds, what pauses the exercise, and how a real incident is deconflicted from the test.
Deconfliction: The agreed process for quickly establishing whether suspicious activity is the test or a genuine intrusion, so a real incident is not dismissed as the exercise.
MITRE ATT&CK: A public knowledge base of adversary tactics and techniques, used as the shared vocabulary between an offensive report and the detection engineering work that follows it.

Common questions

Is assumed breach the same as a red team engagement?: They overlap but they are not synonyms. A red team engagement tests detection and response against a goal, usually covertly and often starting from outside. Assumed breach describes the starting assumption, and can be applied to a red team engagement, a penetration test, or a purple team exercise. Many red team engagements begin with an assumed breach phase specifically so the schedule is not consumed by gaining initial access.
Why grant the attacker access at the start of the test?: Because initial access is the least informative part of an engagement. Given enough time, phishing, a stolen session token or an unpatched edge device tends to work, so spending the budget proving it produces a result you could have assumed. Granting the foothold moves the entire schedule to the questions that decide how severe a real incident is: reach, privilege, and detection. Regulators accept the same logic: TIBER-EU provides for leg-ups precisely so a test is not wasted on obtaining access.
What foothold is usually granted?: Whatever most closely matches a realistic compromise for that environment. Commonly a standard domain user account, a managed corporate laptop build, a set of credentials of the kind an infostealer produces, or a container or workload identity inside the environment. It is agreed during scoping, and the level chosen should reflect what an attacker would plausibly obtain rather than what is convenient to provide.
How much access is too much to grant?: Any level that makes the result unfalsifiable. If the foothold is a privileged account, everything will be reachable and the assessment proves only that administrators can administer. The test of whether a starting position is reasonable is whether you can describe the real-world event that would produce it. A phished employee produces a standard user; nothing ordinary produces a domain administrator.
Does an assumed breach test replace a penetration test?: No. They answer different questions. A penetration test tells you whether a system or perimeter can be broken. An assumed breach assessment tells you what happens after one is. Organisations with weak external hygiene generally get more from conventional testing first, because an assumed breach engagement will succeed easily and teach them less.
How is assumed breach related to zero trust?: Zero trust is an architecture built on the premise that no network location is inherently trustworthy, set out in NIST SP 800-207. Assumed breach is how that premise gets tested. Implementing zero trust without ever running an assumed breach exercise leaves you with a design you believe in and no evidence it behaves as designed, which is the failure mode most zero trust programmes actually hit.
Will the security team know the test is happening?: That is a scoping decision with real consequences either way. Announced, the exercise becomes collaborative and is better at improving detection rules quickly. Unannounced, it produces a more honest measurement of what the team notices under normal conditions, at the cost of consuming their time on what they believe is a genuine incident. Either is defensible; deciding by default is not.
What happens if the security team detects the test immediately?: That is a good result, and it should be recorded as one rather than worked around. The exercise then shifts to what happens next: whether the alert reached a human, how quickly, whether the response contained the activity or only observed it, and whether the same detection holds against a variation of the technique. An engagement that quietly evades detection to keep going has discarded the most valuable finding it produced.
Can assumed breach testing run against cloud environments?: Yes, and the model translates cleanly because cloud has no perimeter to argue about. The foothold becomes a workload identity, a container, a compromised developer account or an over-permissive role, and the equivalent of domain compromise is durable control of the tenancy or subscription. The metrics are unchanged. What differs is that identity and the control plane matter more than network position, so a single role assignment can be worth more than any firewall rule.
Is it safe to run in production?: It is the only place the result means anything, which is why DORA requires threat-led testing to cover live production systems and excludes staging. Safety comes from the rules of engagement rather than from the environment: agreed destructive actions excluded, a named contact reachable at any hour, a deconfliction process, and defined conditions that pause the exercise. A provider unwilling to discuss those in detail before starting is the actual risk.
How do you measure time to detection fairly?: Measure to the moment a human begins acting, not to the moment an alert fires, and record both so the gap between them is visible. That gap is frequently the finding. It also requires the testers to log their own actions with timestamps, so the defensive timeline can be compared against what actually happened rather than against what was reconstructed afterwards.
What does the assessment produce?: The attack paths found, with the evidence for each one, the reach and privilege each path produces, what was detected and when, and remediation ordered by the reduction in reach it achieves rather than by raw severity score. The ordering matters: fixing the one misconfiguration that collapses six separate paths is worth more than fixing three unrelated high-severity findings.
Why prioritise by reach rather than by CVSS score?: Because severity scores describe a vulnerability in isolation and attack paths are chains. A medium-severity misconfiguration that appears in six of eight paths is worth more attention than an unconnected critical, since removing it collapses six routes at once. Reporting by score alone produces a remediation queue sorted by something other than how much it reduces risk.
Who should own the findings inside the organisation?: Whoever can change how privilege and segmentation work, which is usually not the team that commissioned the test. These engagements produce structural findings rather than patch-level ones, so an owner without the authority to change identity design or network boundaries can only escalate. Agreeing that owner before the engagement is one of the better predictors of whether anything changes afterwards.
How often should an assumed breach assessment be repeated?: The useful trigger is change rather than the calendar. A new identity provider, a cloud migration, a merger, or a significant change to privileged access all invalidate the previous result, because they change the paths. Repeating on a fixed schedule while the environment sits still mostly reconfirms the last report. Where a regulator sets a floor, as DORA does with a three-year cycle for designated entities, that is a minimum rather than a recommendation.
Is assumed breach required by any regulation?: Not under that name, but the shape of it is mandated in several places. DORA requires threat-led penetration testing every three years for designated financial entities in the EU, built on TIBER-EU, whose leg-up provision explicitly allows granting access. CBEST is the equivalent framework in the UK. PCI DSS requires segmentation testing annually, or every six months for service providers, which can only be answered by testing from inside a segment.

References and further reading

Primary sources for the standards and regulations cited above. Every regulatory specific on this page was checked against these rather than against secondary commentary.

SP 800-207, Zero Trust ArchitectureNIST
SP 800-115, Technical Guide to Information Security Testing and AssessmentNIST
MITRE ATT&CK, Enterprise tactics and techniquesMITRE
TIBER-EU, threat intelligence-based ethical red teamingEuropean Central Bank
Regulation (EU) 2022/2554 (DORA)EUR-Lex
Commission Delegated Regulation (EU) 2025/1190, TLPT technical standardsEUR-Lex
CBEST threat intelligence-led assessmentsBank of England
PCI DSS v4.0PCI Security Standards Council
Attack simulation and the assume breach strategyMicrosoft

Running one against your environment

Assumed Breach runs assumed breach engagements as red team operations, internal network testing and cloud assessments, depending on where the foothold sits and what the assets worth reaching actually are. Scoping decides which, and the buyer's guide above applies to us as much as to anyone else.

Talk about scoping one Red team operations Incident response What engagements look like