Assumed breach: why granting a foothold saves weeks
Assumed breach means the engagement starts with the attacker already inside, because you granted the access rather than making them earn it. It is not a shortcut for weak testers. Initial access is the phase you can least influence and already know the answer to, and spending three weeks of a six week engagement proving that phishing works leaves half the budget for the part you can actually change. The decision that matters is which foothold you hand over.
What does assumed breach actually mean?
That the engagement begins from a defined position of access, agreed in the rules of engagement and provisioned by you. Typically that is a standard user account on a managed laptop, or code execution inside one container in one namespace. From there the team pursues the objective normally, and everything after the grant is tested exactly as it would be in a covert engagement.
The grant is a scoping decision, not a concession on rigour. Detection is still measured, stealth still matters, and the team still has to survive your tooling. What has been removed is the discovery of an initial access route, which in practice is a mixture of phishing, an exposed service and credential reuse, and which almost never changes what you do next.
The variant worth naming separately is announced assumed breach, where the defenders know a test is happening in a window but not what or when. It loses the surprise measurement and keeps everything else, and it is the right choice for organisations that cannot keep a covert exercise secret for six weeks.
Why does it save weeks?
Because the perimeter phase is expensive and low-information. Building phishing infrastructure that survives filtering, waiting for someone to click, and getting a payload past endpoint controls can consume half of an engagement's elapsed time, and the outcome is a sentence you could have predicted: eventually someone clicked. Meanwhile the questions you commissioned the exercise to answer, about lateral movement, privilege escalation and detection, go untested.
It also removes a scheduling dependency. Initial access has a random element, which makes engagement planning unpredictable and occasionally means a team that has not landed by week four has to force a noisier route, contaminating the detection result. A granted foothold makes the timeline deterministic and the detection measurements comparable between engagements.
There is a fairness argument in favour of it as well. Testing initial access hard enough to succeed means putting real pressure on individual members of staff, and if the outcome was predictable, that pressure bought nothing. Granting the foothold moves the exercise off your people and onto your architecture, which is where the decisions that matter were actually made.
The reasonable middle ground is to test initial access separately and cheaply. Run a phishing simulation as its own exercise with its own metric, test your external surface with scanning and a scoped penetration test, and start the red team from inside. You get both answers, and the second one arrives in full rather than truncated.
Which foothold should you grant?
The one that matches the question you are asking. Each starting position tests a different part of the estate and skips a different part, and the mismatch between the foothold and the concern is a common reason an engagement reads as irrelevant afterwards.
| Starting position | What it tests | What it skips | Choose it when |
|---|---|---|---|
| Standard user on a managed laptop | Endpoint controls, identity, internal lateral movement | External surface and email filtering | You want the default enterprise question answered |
| Local administrator on one host | Credential access, domain or directory escalation | Whether endpoint controls stop the first stage | You know the endpoint stage fails and want what follows |
| Code execution in one pod | Workload identity, cluster RBAC, escape to the node | How an attacker gets into the workload | The cluster runs your revenue services and is untested |
| A CI pipeline runner token | Build system trust, deployment reach, secret sprawl | Developer endpoint compromise | Deployment credentials are broad and nobody has mapped them |
| Contractor VPN plus a SaaS account | Third party access paths and joiner-mover-leaver hygiene | Your internal endpoint estate | Suppliers have standing access you cannot fully see |
| Developer laptop with cloud CLI credentials | Cloud permission blast radius, key handling | Perimeter and email entirely | Your worst case is a stolen developer session |
Does it make the result less realistic?
It makes one phase unrealistic and the rest more so. The honest version of the objection is that a granted foothold might be better than one an attacker could obtain, for example administrative rights when a real intrusion would start unprivileged. That is a scoping error rather than a flaw in the approach, and it is avoided by granting the least privileged position consistent with the question.
The broader answer is that initial access is the most commercially solved and least differentiating part of an intrusion. Credentials are sold, sessions are stolen from infostealer logs, and multi-factor prompts are fatigued into approval. Treating access as a given is closer to how compromises actually begin than treating it as a wall an attacker must scale.
Document the grant in the report as a stated assumption. A reader six months later needs to know that the team started from a standard user account with no privileged access, otherwise every conclusion in the document is unmoored. Suppliers who omit this are usually the same ones who omit action timestamps, and the two absences together make a report impossible to verify.
The test for whether your grant was fair is to ask what a real intruder would plausibly hold on day one, and to write that reasoning down in the report. If the answer is uncomfortable, that is itself a finding: an organisation where the plausible starting position is a broad cloud credential has a problem no amount of perimeter work will fix.
What does assumed breach look like in Kubernetes?
It looks like a shell in one pod, and it is the highest-yield container security exercise available to most teams. Grant execution inside a single workload in a single namespace, define the objective as something concrete such as reading a named secret in a different namespace or obtaining credentials that can deploy to production, and then measure both the path and what the cluster recorded.
The chain the team will walk is predictable enough that you can pre-empt it. Discovery of the cluster and its resources from inside the pod. The mounted service account token, and what its role permits, which is commonly far more than the workload needs because permissions were widened during migration. Creation of a new pod if allowed, or command execution in an existing one. Escape to the node through a host path mount, a permissive security context or a shared namespace. Then the node's own cloud instance credentials, which are frequently far broader than any workload identity and turn a container problem into a cloud account problem.
The detection question runs alongside it. For each step, ask whether the control plane audit log recorded it, whether the record reached a system where somebody could query it, and whether any rule would have fired. Teams with strong endpoint coverage commonly find that the entire chain above is invisible, because the sensor lives on the node and nobody wrote rules for API activity. That is the finding, and it costs a fortnight of pipeline work rather than a product purchase.
How do you scope it so it stays safe?
Do it in production, and manage the risk rather than avoiding it. Running an assumed-breach exercise in staging is tempting and largely pointless for the detection half, because staging has different telemetry, different permissions and usually no monitoring at all. The result tells you about an environment nobody attacks.
Manage the risk with three controls. Provision the foothold with credentials created for the exercise and revoked afterwards, so nothing granted outlives it. Agree an explicit blast radius, naming which namespaces, accounts and business units are boundaries rather than targets. And require notification and rotation for any secret the team captures, treating captured credentials as live rather than as evidence.
Provision the foothold so that it does not itself create a lasting weakness. A dedicated account with a strong credential, created for the exercise and disabled afterwards, is better than borrowing a real employee's access, which contaminates that person's audit trail and makes the timeline reconciliation harder for everybody involved.
Finally, agree the reset rule. If the team achieves the objective in the first week, the productive response is to revoke, grant a different starting position and go again, because a second starting position doubles the coverage of the detection map for a fraction of the original cost. Write that into the engagement plan up front so it is not a renegotiation halfway through.
Common questions
- What is an assumed breach test?
- An engagement that begins from a defined position of access you provision, such as a standard user account on a managed laptop or code execution inside one container. Everything after the grant is tested as normal, including detection and stealth. It removes only the initial access phase, which is expensive in elapsed time and rarely changes what an organisation does next.
- Is assumed breach less realistic than a full red team?
- One phase is unrealistic and the rest is more so. Credentials are sold, sessions are stolen from infostealer logs and multi-factor prompts are fatigued into approval, so treating access as a given resembles how intrusions actually start. The genuine risk is granting more privilege than an attacker would plausibly hold, which is avoided by granting the least privileged position consistent with the question.
- What foothold should you grant a red team?
- The one that matches your concern. A standard user on a managed laptop answers the default enterprise question. Code execution in one pod tests workload identity, cluster permissions and escape to the node. A CI runner token tests deployment reach and secret sprawl. A developer laptop with cloud CLI credentials tests cloud blast radius. Each skips a different area, so state which explicitly.
- How do you run an assumed breach test in Kubernetes?
- Grant execution inside one pod in one namespace and set a concrete objective, such as reading a named secret elsewhere or obtaining production deployment credentials. Expect the chain to run through cluster discovery, the mounted service account token and its role, pod creation or exec, escape to the node, then the node's cloud instance credentials. Measure what the audit log recorded at each step.
- Should an assumed breach test run in production or staging?
- Production, with managed risk. Staging has different telemetry, different permissions and usually no monitoring, so the detection half of the result describes an environment nobody attacks. Control the risk instead with exercise-specific credentials that are revoked afterwards, an explicit blast radius naming boundaries rather than targets, and mandatory notification and rotation for any secret the team captures.
- What if the red team reaches the objective in the first week?
- Revoke the foothold, grant a different starting position and run again. A second starting position roughly doubles the coverage of the detection map for a fraction of the original cost, and it prevents the report describing a single lucky path. Agree the reset rule in the engagement plan up front so it is not renegotiated halfway through.
