A client forwards you a vendor email claiming breach and attack simulation will replace the annual penetration test, runs continuously, and costs less than what they're paying you now. Then comes the question you knew was coming. Can we drop the pentest?
No. And it isn't because we sell pentests.
MSP Pentesting is channel-only, and this email is the one our partners forward to us more often than any other. Here's the short version you can paste into a reply. Breach and attack simulation measures your controls. A penetration test measures your exposure. Those aren't the same measurement, and a client who trades one for the other ends up with a very confident dashboard and an unanswered question.
What breach and attack simulation actually validates
BAS platforms run safe, instrumented versions of known attacker actions from inside the environment, usually via an agent on a host or a pair of agents talking across a segment. Then they check what the stack did about it. Blocked, detected, alerted, or nothing at all.
The library is almost always organized around MITRE ATT&CK, which is a public knowledge base of adversary tactics and techniques observed in real intrusions. That's why every BAS report you'll ever see is a grid of technique IDs with green and red squares.
So the unit of measurement is your tooling. Not the client's attack surface.
Which makes it genuinely good at a short list of things:
- Proving an EDR policy is in block mode and not still in audit mode six months after deployment.
- Proving a SIEM correlation rule fires, and that the alert reaches a human instead of a muted channel.
- Catching configuration drift, because you can run the same set of actions this month and compare it to last month.
- Comparing coverage across tenants, so you find the client where somebody disabled a policy during a troubleshooting call in March.
- Regression testing after a remediation project, without booking another human engagement.
Every one of those is a real problem. None of them is what a pentest is for.
What a penetration test actually validates
A pentest is a person, working under a scope and rules of engagement, trying to reach something that matters. NIST SP 800-115 describes the shape of it: planning, discovery, attack, reporting. The value sits almost entirely in the discovery and attack phases, because that's where a human does the thing no library does.
Chaining.
A tester finds a forgotten subdomain, pulls a credential out of a public repository, reuses it against a VPN with no MFA enforcement on that group, lands on a jump box, finds a service account with a weak password and an SPN, and walks to domain admin. Not one of those steps is a vulnerability with a CVE. The finding is the path, and the path only exists because somebody looked.
The other things only a tester gives you:
- Business logic. A BAS library has no idea that the client's portal lets you change an account number in a URL and see somebody else's invoices.
- Judgment about impact. A human can tell the difference between a finding that's embarrassing and a finding that ends the company.
- The unknown. BAS runs actions somebody already wrote down. A tester finds the thing nobody wrote down.
- Independence. A named third party puts their name on a dated report, which is the artifact insurers, auditors and enterprise buyers actually ask for.
| The question | Breach and attack simulation | Penetration test |
|---|---|---|
| Does the control stack stop known techniques? | Yes, that is the whole job | Only incidentally |
| What is exploitable in this environment right now? | No, it does not look | Yes, that is the whole job |
| How far does one foothold actually reach? | Simulated paths only | Real paths, chained by hand |
| Did detection improve since last quarter? | Yes, repeatable and comparable | Weakly, scope moves each time |
| Will an auditor or insurer accept it? | Usually not on its own | Yes, that is what they ask for |
| Who runs it? | You, on your own stack | An independent third party |

Read those two columns as two different purchase orders, because that's what they are. The left column is an operations spend that makes your service desk better. The right column is an assurance spend that makes a contract signable.
Adversary emulation is a third word, and it isn't a synonym
People throw adversary emulation into this argument as if it settles it. It doesn't, because it's a narrower idea than either of the other two.
Adversary emulation means replicating the specific, documented behaviors of a named threat actor rather than running a generic technique library. The Center for Threat-Informed Defense publishes an open Adversary Emulation Library of exactly these plans. MITRE's CALDERA is an open-source platform built to automate them. Red Canary's Atomic Red Team is a public collection of small tests mapped to ATT&CK techniques that a lot of teams use for the same purpose.
Commercial BAS products productize that idea and wrap reporting around it. Purple teaming is what you call it when you run the emulation with the defenders in the room, watching their console live, tuning as you go.
All of it still measures your controls against behavior somebody already cataloged. Useful. Not the same as somebody hunting for the thing nobody cataloged.
Where BAS earns its money in an MSP stack
If you run a security stack across thirty tenants, there's a real case for this, and it isn't the case the vendor makes.
- Proving your own stack works. You sold the EDR, the SIEM and the mail filter. BAS is the cheapest way to show the client that the thing they pay you for every month actually did something.
- Finding drift across tenants. Standardization decays. Somebody excluded a folder to fix a line-of-business app and never put it back. A monthly run finds that before an attacker does.
- Feeding detection engineering. Every red square is a candidate for a new rule. That's a tighter loop than waiting a year for a pentest report to tell you the same thing.
- Regression after remediation. You closed twenty findings. Re-run the relevant actions and confirm they're still closed in ninety days.
- Bake-offs. When a client wants to swap EDR vendors, running the same technique set against both is a far better trial than a feature grid.
Notice that all five of those are about you. That's the tell. BAS is an internal instrument. It's a great one. It just doesn't face outward.
Where it will get you in trouble
Compliance. PCI DSS v4.0.1 Requirement 11.4 asks for internal and external penetration testing, performed at least once every 12 months using an industry-accepted methodology, by a qualified internal resource or a qualified external third party with organizational independence from the thing being tested. A BAS run doesn't meet that wording and no QSA is going to pretend it does. ISO/IEC 27001:2022 pushes the same direction through Annex A 8.8 on technical vulnerability management and A 8.29 on security testing. SOC 2 doesn't require penetration testing, but the AICPA names it by name in the points of focus under CC4.1, and any service auditor will tell you what they want to see against CC4.1 and CC7.1.
Insurance and vendor review. Cyber applications and enterprise security questionnaires ask whether an independent third party tested the environment in the last twelve months. There isn't a box for a dashboard.
The green-dashboard illusion. A perfect BAS score means the library passed. It says nothing about the technique that isn't in the library, and it says nothing about the web app the client had built by a contractor in 2019.
Safe by design. BAS stays safe on purpose, which means it declines to do the destructive and genuinely creative things a motivated attacker will happily do.
That's why the sane structure is both, with the outward-facing half handled by somebody who isn't you. Our partners run this as white-labeled penetration testing underneath their own managed stack, so the independence holds up on the questionnaire and the client relationship stays theirs.

How to answer the client who wants to swap
Keep it to three sentences and don't get defensive.
The simulation tells us whether the tools we already sold you are working, and we should buy it for that. The pentest tells us what somebody could actually do to you, and it's the only one of the two your insurer and your biggest customer will accept. If the budget is genuinely fixed this year, we keep the test and we phase the simulation in next year, because losing the test costs you a contract and losing the simulation costs you a report.
If they want to see what the outward-facing artifact looks like before they commit, hand them our penetration test report template. Comparing that against a technique-coverage grid ends the argument faster than any explanation you can write.
Questions MSPs ask when a client wants to swap
Is breach and attack simulation the same as automated penetration testing?
No, though the categories are converging in marketing language. Automated pentest tools try to discover and chain real weaknesses in the environment. BAS executes a curated set of known behaviors to see what the controls do. If a product claims both, ask which library it runs and whether it discovers anything that isn't in that library.
Will a QSA or a service auditor take BAS output as the annual test?
Not on its own for PCI DSS, and not in our experience for ISO 27001 or a SOC 2 examination. The requirements are written around methodology, qualification and independence. A tool your own team runs against your own stack fails the independence half no matter how good the tool is.
Can BAS break production?
It's designed not to, and the vendors work hard on that. It can still generate a real incident response, which is the part MSPs forget. Tell the SOC before the first run or you'll burn an afternoon on your own alert.
Do we need a red team as well?
Almost never for an SMB client. Red teaming assumes a mature detection function worth testing. If the client hasn't had a pentest yet, a red team is theater with a bigger invoice.
What should an MSP buy first?
The test. You need the baseline of what's exploitable before spending money to confirm your controls stop things that were never going to be the way in. After the first test cycle, BAS becomes the cheap way to hold the line between engagements.
Run both, and say why in one sentence
Breach and attack simulation is a control-assurance tool that belongs in a serious MSP stack. It'll make your detection better and your QBRs sharper. It won't tell you what an attacker could do to your client, and it won't sign anything.
Run both. Let the automation hold the line month to month, and bring in an independent tester once a year to look for the thing the library never modeled. Want the annual half handled under your brand? Get a pentest quote and send us the last coverage report your platform produced. The gaps in it are the scope.


.png)
.avif)
.png)
.png)
.png)

