Assumed breach testing
Assumed breach testing
Begin from a defined compromise and find out what it exposes. We test the routes from an agreed identity, endpoint or system towards the objectives that matter, validating the access and trust an attacker could use.
A penetration tester replies within one working hour with the questions that set the scenario.
Overview
What is assumed breach testing?
Assumed breach testing starts from access an attacker might already hold, such as an employee identity, managed endpoint, internal device, server or cloud role. We map the trust available from that position and validate the paths towards agreed systems, data and privileges.
This is for you if…
You need to know the blast radius
You want to know what one compromised identity, endpoint or system could expose.
Important systems depend on trust
You need to see how access changes as an attacker moves between identity, infrastructure and cloud services.
A critical objective matters most
You want testing shaped around the data, privileges or operational systems your organisation depends on.
New to the term? Assumed breach, explained in our glossary
Why you need it
Why does your organisation need assumed breach testing?
The starting position does not define the impact. That depends on the identities, permissions and trust available from it, the boundaries that restrict movement and the systems an attacker can ultimately reach. We agree those starting conditions and objectives before testing begins.
Starting access
The identity, endpoint, device, server or cloud role provided at the start of the scenario.
Identity and permissions
The accounts, roles, groups and delegated access that determine what the foothold can use.
Systems and trust
The infrastructure, applications and cloud services that accept those identities or trust connected systems.
Critical objectives
The data, privileges and operational capabilities the engagement is designed to assess.
Motive
Which objectives matter after a compromise?
Initial access rarely explains the full risk. An ordinary account may hold delegated access to cloud services, an endpoint may expose reusable credentials, or one trusted server may provide a route into management systems. The material risk sits in how those relationships combine.
We design the engagement around the outcomes that matter to your organisation, then trace and safely validate the paths that could reach them. Findings are prioritised by what they enabled and where the path led.
Directory control
Privileged access in Active Directory or Microsoft Entra ID.
Management systems
Tools that administer endpoints, infrastructure, backups or security controls.
Cloud and application access
Roles, tokens and connected services opened by the compromised position.
Critical data or operations
The information and capabilities the organisation needs to protect most.
Reach
What could the starting access reach?
Starting from the agreed access, we map reachable identities, systems and trust, then safely validate the paths that could materially change the scenario. The result shows the blast radius of the compromise, the objectives reached and the controls that restricted or enabled each path.
Entry
Begin from agreed access
An identity, endpoint, device, server or cloud role represents the defined compromise.
Yields a known starting position
Step
Map identity and trust
Permissions, reachable systems and connected services reveal the available routes.
Yields candidate attack paths
Step
Cross a security boundary
A material weakness is safely validated to show how the attacker's access changes.
Yields broader access
Impact
Reach an objective
The path is followed only as far as needed to demonstrate its business impact.
Yields evidenced exposure
In practice
The work may cross Active Directory, Microsoft Entra ID, endpoints, internal infrastructure, management platforms, applications and cloud services, depending on the agreed scope. We examine how identities and systems are connected rather than treating each technology in isolation.
Where defensive validation is included, we also compare selected activity with the telemetry, alerts and response produced by your security controls. This is agreed during scoping rather than assumed for every engagement.
Methodology
How Adversify runs an assumed breach test
We define the compromise, access, objectives and safeguards, then map available trust, validate material paths and report what they exposed. The agreed starting position and stopping points shape all four phases and how far each route is followed in practice.
- Missed by your defences
- Reported all clear
Engagement design
We agree the compromise to assume, the access provided, the critical objectives and the actions that require prior approval. This gives the engagement a realistic starting position and clear safety boundaries.
- Starting access
- Objectives
- Safeguards
Analyse the attack surface
From the starting position we map the identities, permissions, reachable systems and trust relationships that could support further access. This identifies the paths most relevant to the agreed objectives.
- Identities
- Permissions
- Trust
Validate attack paths
We investigate the material routes and safely validate the access they provide. Testing follows the agreed rules of engagement and stops at the level needed to demonstrate impact without unnecessary disruption.
- Attack paths
- Safe validation
- Objective reach
Reporting and evaluation
The Adversify report sets out the blast radius, the validated paths, what each path reached and the changes that would interrupt it. Where defensive validation was included, relevant telemetry and alerts are recorded alongside the activity.
- Blast radius
- Attack paths
- Priorities
Coverage
What does an assumed breach test cover?
Each engagement starts from access agreed during scoping. The examples below show the positions we can work from, not a fixed package. We define the objectives, systems and safety boundaries with you before testing, so the work reflects a relevant compromise and an appropriate stopping point.
Employee identity
A standard account with the access and cloud services available to a member of staff.
Managed endpoint
A corporate laptop or desktop with an authenticated user and the controls applied to it.
Internal network device
An unmanaged device connected to an agreed segment of the internal network.
Compromised server or application
Access representing an attacker who has gained control of an internal workload.
Cloud identity or workload
An agreed role, service account or workload identity within a cloud environment.
Developer or operational role
Access held by someone who administers code, platforms, infrastructure or business systems.
Each scenario is agreed with you before testing starts, including who on your side knows the test is running.
What you get
What you get from an assumed breach test
You receive a clear account of the compromise's blast radius, the paths validated and the objectives reached. Leadership gets a plain-language view of business exposure, while technical teams receive the evidence and prioritised changes needed to interrupt the routes we used.
You receive
The assumed breach report
A summary in plain words for the people who decide, and each attack path in full for the teams who act on it.
Evidence of objective reach
The access created at each step and the systems, data or privileges it exposed.
Remediation guidance
What to change first, in order, from access controls to alerting.
A debrief with the testers
A post-assessment discussion of the lessons learnt, for your IT and security teams together.
What changes
- The scenario starts from defined access and agreed business objectives
- Each validated path shows how permissions or trust changed the attacker's reach
- Defensive evidence is included where detection and response validation forms part of the scope
Questions
Assumed breach testing questions
Clients ask how assumed breach differs from internal testing, which access we use, how live systems are protected and if defence checks are included. Together we agree the scenario, objectives, safeguards, stopping points and scope before any test work starts.
Not answered here? Ask it on the scoping call
How is this different from internal enterprise penetration testing?
Internal enterprise testing examines the wider internal attack surface from an agreed level of access. Assumed breach testing is shaped around a defined compromise and a set of critical objectives, with the work focused on the blast radius and attack paths from that starting position.
What access do you start with?
We agree the starting point at scoping to suit you. It can be a staff account we sign in with remotely, a laptop you set up for us as you would for a new starter, a small device we send you to plug into your network, or a connection through your VPN. The starting access is chosen to represent the agreed scenario and recorded in the scope.
Will the test affect our live systems?
The test runs on your live network, with care. We avoid actions that could disrupt normal work, agree any risky step with you before we take it, and stop and call your named contact if we find something serious.
Can the engagement test detection and response as well?
Yes, where this forms part of the agreed scope. We can compare selected activity with the telemetry, alerts and response it produced. If the main objective is collaborative detection improvement across a series of techniques, a purple team exercise may be more suitable.
How is assumed breach testing different from purple teaming?
Assumed breach testing asks what a defined compromise could reach and follows the material attack paths towards agreed objectives. Purple teaming is a collaborative exercise focused on how specific activity is logged, detected, investigated and handled by your defenders.
What happens next?
Get a test scoped to your scenario
Tell us which starting position and objectives you want to assess. A penetration tester will reply within one working hour to agree the access, environments and safety boundaries. Your quote will then set out the scope and deliverables, or you can book a scoping call first.
- Scoped to your scenario, agreed before we start
- CREST-accredited for penetration testing
- York based, UK wide
A penetration tester will help you choose a real-world scenario and starting foothold before anything is quoted.