An external assessment answers how somebody gets in. This one answers what happens next: which hosts that position can reach, what reaching them actually yields, and where a recovered credential works that it should not. B-52 runs it from a position deployed inside your network, inside a movement boundary you write into the scope.
The boundary
Three actions need your written approval on every coverage class. On this one the second is not an edge case that might come up — it is the work, so it is settled at scoping rather than raised mid-run.
| State | What it means | What follows |
|---|---|---|
| Persistence and movement past the entry host | Moving from the first host to the next, and holding what has been reached. On an internal scope this is what you are buying, so the authorisation and its limit are part of the scope agreement. | Agreed at scoping, with its boundary written down. |
| Destructive or state-changing actions | Anything that alters or removes what is on a system rather than demonstrating that it could be altered. Inside a network that covers anything other people are relying on while the run is going. | Stops and waits, in writing. |
| Live credentials or real customer data | Using a real account’s credentials, or reading a real person’s records, once a path to them has been proved. Proving the path and walking through it are separate decisions. | Stops and waits, in writing. |
| Everything else inside the authorised scope Terminal | Enumeration, service and configuration analysis, trust mapping, exploitation, chaining and reporting. | Runs without asking. |
What an approval covers
An approval names a boundary and an engagement, not one action. Authorising movement inside a named segment authorises it inside that segment for that engagement, and B-52 does not return for a second signature on each host it reaches. Nor does it read that as licence to leave the segment: the boundary is the thing that was approved, and reaching past it is a new decision that comes back to you. The audit trail records what was permitted, when and by whom — and where a gate was never released, that is on the record as plainly as what was allowed, which is the half a reviewer actually reads.
Class and boundary
It starts from a position inside the network rather than from the internet. What that position is, and how far it may travel from there, are both your decisions and both are taken before the run.
Hosts and services reachable from the deployed position: what is listening, how it is configured, what authenticates to what, which shares and interfaces will hand something over, and which of those turn one host into a route to another.
Domain and identity infrastructure is assessed as the Active Directory class, against its own model. An internal assessment reports what it reached of the directory; the directory assessment works the directory.
AdjacentThe route from the public internet to that first host is the external network class. The two are scoped apart because the positions are different, and they run as one engagement where you want the whole chain.
Out of scope for the platform entirely, in every class. It is the only exclusion, and it is stated the same way everywhere on this site.
Who this page is for
Both are answered here. What they should read first is not the same.
By phase
Discovery from inside a network is a different job from discovery against one. These are the platform phases with what enters and what leaves each on this class.
| Phase | What enters | What leaves |
|---|---|---|
| Discovery | A deployed position inside the network, and the ranges you authorised it to look at. | What is reachable from there: hosts, the services listening on them, and the identities those services accept. |
| Planning | The reachable set, and the movement boundary you agreed. | A scope signed in writing, including how far movement may go. In the fully autonomous model that sign-off is the last human action of the engagement. |
| Scanning | The authorised hosts. | Candidates — versions, configuration, and the trust relationships between them. Nothing is reported from this phase. |
| Exploitation | A candidate, and the position it is reachable from. | A proved finding or a dropped one, and where a finding opens a route, the route is walked inside the boundary you set. |
| The ledger above is what decides how far this phase is allowed to go. | ||
| Reporting | Confirmed findings. | Each written up with the exchange that proved it, landing in your dashboard as it is confirmed. |
| QA | The finished report. | A gate that can send it back to reporting before it reaches you. It is where a host that was merely reachable is separated from a host that mattered. |
Discovery
Planning
Scanning
Exploitation
The ledger above is what decides how far this phase is allowed to go.
Reporting
QA
The deployment
External and application testing need nothing deployed on your side. Internal testing does, because the position is the premise: an assessment that has to come through the perimeter first is measuring the perimeter rather than what sits behind it. B-52 deploys on-premise or into your own virtual private cloud, and both are available today. Which segment the position sits in, and what it is routed to, is agreed at scoping — because that is what decides what the assessment can honestly say afterwards, and because a system placed inside your network is a system your own controls have a view on.
What the run works
A reachable host and a useful host are different findings. Everything below is a question about which of the two something turned out to be.
The hosts, services and interfaces visible from where the assessment starts, and which of them will respond to something they were not configured to expect.
A service that answers is not a finding. A service that hands over a file, a configuration or a session is, and the difference between the two is established by asking it for one.
Identity is the currency inside a network. Where a recovered credential or token authenticates elsewhere is the question that turns one host into a route, and it is the question a host-by-host report never asks.
Whether the segment the run started in is separated in practice from the one it was not meant to reach. Answered by trying, inside the authorisation you gave, and recorded either way.
Why the chain is the unit
Inside a network a great deal is reachable from somewhere, which is why a list of reachable hosts is not an assessment. What carries meaning is the sequence: this service gave up a credential, that credential authenticated somewhere it should not have, and what sits at the end of it is the reason the engagement was bought. B-52 walks the sequence and reports it as one finding with its steps intact, rather than as three rows that a severity sort would separate and a triage queue would then close in the wrong order.
Methodology
Each cited at the version current on the date beside it. The tactic vocabulary matters more on this class than on any other, because it is the one your own detection team is already using.
| Standard | Version | What it carries here |
|---|---|---|
| MITRE ATT&CK | v19.2, released 6 August 2026. Read 2026-09-13 | The tactic and technique vocabulary a chain is described in, so your detection team can take a finding straight to the rule that should have caught it. |
| Enterprise ATT&CK. Deliberately not cited on the mobile class, where the device-level equivalent would need a claim the product source does not make. | ||
| NIST SP 800-115 | Final, September 2008. Read 2026-09-13 | The structure of a technical assessment — planning, discovery, attack, reporting — and the handling rules for what the attack phase turns up. |
| Still the current edition: it has been neither withdrawn nor superseded. | ||
| PTES | Current | The engagement structure — scoping, authorisation in writing, and the shape of the report. |
| CVSS | v4.0, November 2023. Read 2026-09-13 | The severity vector on every finding, so your team can recompute the score against its own environmental metrics instead of taking ours. |
| The version FIRST currently publishes and maintains. | ||
MITRE ATT&CK
Enterprise ATT&CK. Deliberately not cited on the mobile class, where the device-level equivalent would need a claim the product source does not make.
NIST SP 800-115
Still the current edition: it has been neither withdrawn nor superseded.
PTES
CVSS
The version FIRST currently publishes and maintains.
Before a run starts
Deliberately excluded
Per finding
The request as sent and the response as returned, with the part that proves the defect marked. Inside a network that is the share that listed, the service that answered, or the token that came back.
Which host, on which segment, holding which identity. A finding without its starting position cannot be reproduced and cannot be argued about honestly.
Steps in order, each with its own evidence, reported as one finding. A chain broken into rows loses the only thing that made it worth reporting.
Severity with its CVSS v4.0 vector, the CWE, and the ATT&CK technique each step maps to.
In the model with no auditor in it, findings pass a second automated gate before they are reported. It is a check on top of the exploit, not a substitute for it.
Where this sits
No vendor is named here — these are categories of work, compared on what each one produces rather than on which is cleverer.
| Authenticated internal scanner | Breach and attack simulation | Scheduled internal pentest | B-52 | |
|---|---|---|---|---|
| What it works from | A host list and a signature catalogue. | A library of documented techniques, replayed on a schedule. | An assessor on a position inside, for the days bought. | A deployed position and a scope with the movement boundary written into it. |
| What ends the run | The host list. | The technique library. | The days. | The boundary you authorised. |
| Chaining across hosts | No. Each host is assessed on its own. | Within the techniques it ships. | Yes. | Yes, and reported as one chain with its steps rather than as separate rows. |
| What a finding costs you to confirm | Triage. A share of them are not real. | Usually nothing; it was executed. | Usually nothing; it was proved. | Nothing. It arrives with the exchange that proved it. |
| Cadence | Continuous. | Continuous. | When it is scheduled and staffed. | The interval you set, against a deployment that stays in place. |
| Whose signature it carries | None. | None. | The firm that ran it. | Security Brigade’s, in the two models with an empanelled auditor in them. |
What it works from
What ends the run
Chaining across hosts
What a finding costs you to confirm
Cadence
Whose signature it carries
On technique libraries
Replaying documented techniques is genuinely useful, and it is the right instrument for confirming that a control you paid for does what the datasheet said. What a library works from is what is already written down. What it cannot work from is whatever is peculiar to your estate — the service account given more than it needed three years ago, the trust relationship nobody documented, the share opened for a migration and never closed. Those are not techniques; they are facts about one network, and reaching them means working that network rather than running a list against it.
Filing
Coverage is identical across the three delivery models. What changes is whose signature the report carries, and that is what decides where it can be filed.
Annexure L of the circular dated 20 August 2024 names infrastructure alongside applications, APIs, operating systems, databases and cloud. Read 2026-09-08.
Where an obligation rests on a network boundary holding, the evidence is an attempt to cross it from inside, recorded whether or not it succeeded.
Each finding carries through open, fixed, retested and closed, and closes on a retest that cannot reproduce it.
Where the report goes to a regulator, start with the expert-verified model.
On empanelment
Two of the three delivery models put an empanelled Security Brigade auditor inside the engagement, and those two produce a report that can be filed where CERT-In empanelment is required. The fully autonomous model does not, because the empanelment attaches to the testing rather than only to the firm selling it. The hosts reached and the depth of the run are the same in all three.
Worked example
Four steps, each unremarkable on its own. The reason they are one finding is that each one is only reachable because of the last.
| Link | Alone | In sequence |
|---|---|---|
| 1 An internal service | An application reachable from the segment the run started in. | It accepts a destination it was never meant to be handed. |
| 2 A request it makes for you | One fetch, made by the service rather than by the tester. | It reaches what the segment boundary existed to keep apart. |
| 3 A credential in the reply | A token returned in a response body. | It authenticates somewhere the first host had no business reaching. |
| 4 What sits at the end | A record, or a console. | One finding with four steps, not four rows a severity sort would separate. |
Measured
Security Brigade put B-52 alongside its own expert assessment team, on the same targets, at the same time, and pooled what both produced into a single set with each item counted once. Against that pooled set B-52 reached 90–95%, and part of what it reached the team had not — which is why pooling the two produces a larger set than either side alone. It is also the honest argument for the expert-verified model, where both are in the engagement.
One scan is one target and the entry tier is $500. Internal testing needs a deployed position and a movement boundary agreed with you, so this one starts with a scoping call.