What is assumed-breach testing?

Key takeaways

• Assumed-breach testing skips the perimeter and starts from a realistic post-initial-access position (a phished user account, a compromised device, a stolen credential).
• It measures the controls that actually matter once an attacker is inside: privileged access, segmentation, detection, identity governance, and data access controls.
• It produces more impactful findings than perimeter-focused engagements, because real intrusions almost always defeat the perimeter through phishing or credential theft anyway.
• It is the default engagement model after a baseline of external testing has been established (typically Year 2 onward in a continuous program).
• For mid-market manufacturers, assumed-breach exercises the most expensive failure modes: lateral movement to OT-adjacent IT, finance and AP compromise, and vendor-account abuse.

What does "assumed breach" actually mean in a security test?

"Assumed breach" is shorthand for a deliberate constraint: the engagement skips the initial-access question and starts from a position the tester is granted, on the assumption that a real attacker would eventually reach an equivalent position through phishing, credential theft, OAuth abuse, or a third-party compromise.

The constraint is realistic for a specific reason. Verizon's annual breach data and most major incident-response reports converge on the same finding: the vast majority of incidents at mid-market organizations begin with credential abuse, phishing, or third-party compromise. The perimeter is defeated routinely, and rebuilding it to be impenetrable is not a realistic strategy. The internal controls determine whether a foothold becomes a breach.

Assumed-breach testing puts the engagement budget where the real risk lives. Instead of spending two weeks proving the perimeter can be bypassed (which it can), the engagement spends two weeks measuring what happens after.

The starting position is chosen deliberately to model a likely scenario. Common starting positions:

• A standard user workstation, logged in as a finance team member, no local admin.
• A standard user workstation, logged in as a help desk technician, with a few elevated tickets in queue.
• A remote desktop session as a vendor account with limited access into a designated environment.
• An executive's laptop with valid Microsoft 365 SSO and a small set of synced files.
• A compromised OAuth token with mailbox.read and offline_access scopes for a specific user.

Each starting position exercises a different set of internal controls. Engagements often combine two or three to map coverage across the most likely paths.

How an assumed-breach engagement is structured

A typical engagement runs three to six weeks:

1. Scoping and starting position. The executive sponsor, the operating team, and (in some models) the defending team agree on the starting position, the objectives, the rules of engagement, and the out-of-scope list. Objectives are business-impact statements: "reach the production ERP", "exfiltrate engineering files for product line X", "gain ability to initiate wire transfers", "access an OT engineering workstation".

2. Drop-in. The tester is granted the starting position. For a user-account starting position, this usually means receiving credentials, MFA enrollment, and a corporate laptop or VDI. For an OAuth-based starting position, a token with specified scopes.

3. Post-exploitation execution. The tester operates from the starting position toward the objectives. Each step is logged against MITRE ATT&CK techniques and timestamped. The tester rotates technique deliberately to test multiple detection paths.

4. Detection observation. The defending team's response (or lack of it) is logged in parallel. If the engagement is run in purple team mode, the defending team sees execution in real time; if run black-box, detection events are reconstructed afterward from telemetry.

5. Reporting and debrief. Final report and debrief, structured around the chain from starting position to each objective, with the detection and prevention opportunities along the way.

Why assumed-breach testing finds more impactful gaps

Three reasons assumed-breach engagements consistently produce findings that perimeter-focused testing misses:

1. Internal trust assumptions are usually weaker than external ones. Organizations harden the perimeter; they rarely harden the lateral surface to the same degree. Service accounts with broad rights, share permissions inherited from a 2018 migration, helpdesk RBAC nobody has reviewed, file-server access lists that grew organically: all of these are the assumed-breach surface.
2. Identity is the real perimeter. Once a tester has valid credentials, most of the relevant controls are identity controls: conditional access, privileged access management, just-in-time elevation, anomaly detection on logons, OAuth governance. Assumed-breach engagements exercise these directly. See What is privileged access management (PAM)? and What is least privilege?.
3. The blast radius of a real foothold is usually larger than expected. Defenders model the worst case; testers find it. Assumed-breach engagements routinely demonstrate that a single phished finance user reaches the controllers' shared drive, that a help desk account can grant itself elevation, or that a vendor account intended for a single integration can read the entire CRM.

The findings translate directly into business-impact language a non-specialist can act on. "If one of your AP clerks gets phished, here is the wire that goes out the door, here is the time-to-detect, and here is the change that prevents it" is harder to argue with than a vulnerability list.

Examples of internal controls assumed-breach testing exercises

Patterns ARG sees repeatedly in mid-market manufacturer engagements:

• Privileged access reachable from a standard user. A standard finance account can access a "helper" service account via a stored credential in a shared OneNote, then pivot to the ERP admin role.
• Lateral movement to engineering file servers. A drop-in finance workstation can read CAD repositories on the engineering file server because the share inherits from a domain-wide "Authenticated Users" ACE no one remembers setting.
• MFA gaps on internal SSO-protected applications. External-facing apps enforce MFA; the internal SAML SP for the ERP does not, because it is "behind the firewall".
• OAuth grants from prior incidents that survived rotation. Old Microsoft 365 OAuth grants with offline_access tokens still work months after the user's password was reset. See What is consent phishing (OAuth phishing)?.
• Help desk workflow abuse. A vishing call to the help desk results in MFA reset on an executive account; the engagement shows the elapsed time from call to wire-transfer-ready access.
• Vendor-account scope creep. A remote vendor account intended for one specific integration has access to several adjacent systems through inherited group membership.
• No outbound DLP on sensitive data classes. Engineering files exfiltrate cleanly over HTTPS to a controlled endpoint with no alert.

Each finding ties to a specific control change with measurable impact. The change is then re-tested in the next engagement or in the continuous layer to confirm it actually closed the path.

When to choose assumed-breach over external-only testing

Three signals point toward assumed-breach as the right next engagement:

1. External testing has run for at least one cycle and findings are getting smaller. Perimeter findings shrink quickly once the basics are addressed. Continuing to focus engagement budget on external testing produces diminishing returns.
2. Most realistic threats start from inside. If the organization's threat model is dominated by phishing, BEC, ransomware affiliates, and supply chain compromise (as it is for almost every mid-market manufacturer), the internal surface determines the actual outcome.
3. Compliance asks for it. CMMC 2.0 Level 2 and 3 assessments value evidence of internal control effectiveness, not just perimeter testing. Insurance underwriters increasingly do too. See What is cyber insurance underwriting?.

A mature program runs continuous external testing as the always-on baseline (What is continuous penetration testing?), with periodic assumed-breach engagements (annually or semi-annually) layered on top.

Best practices for assumed-breach engagement scoping

1. Pick the starting position deliberately, based on threat modeling. The most likely real-world initial-access path determines the most useful starting position. Phished finance user, vendor account, OAuth token, executive laptop: each one tests different controls.
2. State objectives as business outcomes, not technical milestones. "Reach domain admin" produces a flag-capture engagement. "Initiate a wire transfer", "exfiltrate CAD files for product X", or "gain ability to modify the ERP item-master" produce engagements that matter to the people writing the check.
3. Decide detection visibility up front. Black-box, purple team, or hybrid (black-box for the first half, purple team for the second). Each produces different data; pick deliberately.
4. Keep at least one OT-relevant objective in scope where applicable. For a manufacturer, "could an attacker reach an OT engineering workstation from a finance foothold" is often the most consequential question. Even with strict out-of-scope rules for live OT systems, the path to the boundary is testable.
5. Plan to re-test. Findings from assumed-breach engagements are remediation-heavy. Schedule the re-test before the report is written.
6. Pair the engagement with incident response readiness work. Each finding is also a test scenario for the IR plan.

Assumed-breach testing FAQs

Is assumed-breach testing the same as insider threat testing?

No. Insider threat testing models a legitimate employee acting maliciously, with their normal privileges and knowledge. Assumed-breach testing models an outside attacker who has compromised an employee's account or device, usually through phishing or a stolen credential. The starting conditions are different, and so are the controls that matter.

What initial access does the tester get?

Typically a workstation login under a specified user account, often without administrative privileges. The starting position is chosen to match the most likely real-world initial-access scenario for the organization: a phished finance user, a compromised remote vendor account, or an executive's stolen laptop, for example.

Does assumed-breach replace external pen testing?

No. Assumed-breach testing measures internal controls; external penetration testing measures the perimeter. Both surfaces matter. Most mature programs run both: continuous external testing plus periodic assumed-breach engagements that exercise the internal half of the attack chain.

How do you measure success in an assumed-breach engagement?

By objectives reached and by detection events fired. A successful engagement measures both how far an attacker could get from the assumed starting point (privileges gained, data accessed, business outcomes possible) and how visible their behavior was to the defending team along the way.

How ARG uses assumed-breach as the default after Year 1

ARG's engagement model assumes the perimeter will be defeated, because in real incidents it usually is. The first year of a client engagement establishes the external testing baseline; from Year 2 onward, assumed-breach testing becomes the default model for the digital side of on-site engagements.

The starting position is chosen with the client based on the threat profile and the prior year's findings. For a manufacturer with active CMMC obligations, the starting position is often "a phished CAD engineer with normal access to the engineering file server". For a manufacturer with active acquisition activity, the starting position is often "a remote vendor account inherited from an acquired company". For an organization with high-volume AP processing, the starting position is "a phished AP clerk during month-end close".

Objectives are scoped to business outcomes: route a wire, exfiltrate a specified file set, reach a designated control-room workstation, manipulate an item-master record in the ERP. Out-of-scope rules cover anything that would interact with live OT control logic or production safety systems.

The engagement runs three to six weeks. During on-site weeks, the engagement is run in purple team mode with the client's IT team. Between on-site weeks, the assumed-breach tooling stays in place and the continuous simulation layer keeps probing newly closed paths to confirm remediation held.

James Wall leads the post-exploitation execution. Findings feed into the same monthly packet and quarterly review as the continuous testing and social engineering layers. The client sees one program, one backlog, and one rhythm of improvement.

Apply as a founding client or see how the engagement works for the full delivery cycle.