TL;DR: BAS, CTEM, CART, pen testing, VA and AEV solve different security problems, but most programs blur them and waste budget on mismatched controls, according to FireCompass. The practical shift is toward continuous offensive validation, because exposure discovery without exploitability testing leaves a measurable gap between visibility and risk reduction.
At a glance
What this is: FireCompass breaks down how BAS, CTEM, CART, pen testing, VA, ASM and AEV differ, and argues that the main program failure is treating exposure discovery and exploitability validation as the same control.
Why it matters: IAM, NHI and broader security teams need these categories separated so discovery, validation and response controls map to the right risk problem instead of creating false confidence.
Context
Offensive security programmes fail when teams assume that any exposure tooling answers the same question. Vulnerability assessment finds known issues, attack surface management finds assets and exposures, breach and attack simulation checks whether controls react to known techniques, and pen testing proves whether an attack path is actually exploitable. The article is about how those layers differ, not about a single product category.
That distinction matters whenever identity, credentials, or application access are part of the attack path. Continuous validation becomes more important as environments add APIs, shadow assets, and agent-like automation that can be reached through exposed services or reused credentials. The practical governance problem is choosing the right control for the right stage of exposure, then avoiding duplicated spend on overlapping tools.
Key questions
Q: Where does exposure management fail when teams skip validation?
A: Exposure management fails when discovery is treated as the finish line. Teams can know they own an exposed asset and still not know whether it is reachable, exploitable or chainable into sensitive systems. Without validation, prioritisation becomes guesswork and the highest-risk items may remain hidden inside the noisiest inventory.
Q: Why do BAS and CART produce different security answers?
A: BAS checks whether known techniques are detected or blocked by defensive controls, while CART tries to reach a real objective through an adaptive attack path. One grades the stack against a script, the other tests whether an adversary can actually get to the crown jewels. They are complementary, not interchangeable.
Q: What are the signs that vulnerability scans are not enough?
A: They are not enough when the output is a long CVE list with no proof of reachability, chaining or business impact. If triage keeps focusing on version data while real risk sits in access paths, business logic or lateral movement, the programme is still operating at candidate-risk level, not exposure-risk level.
Q: Should organisations prioritise continuous testing over annual penetration tests?
A: Yes, in high-change environments. Continuous testing is more aligned to how autonomous attackers operate and gives teams faster feedback on exposure, especially where APIs, web apps, and shadow AI change often. Annual tests still have value, but they are too slow and too narrow to serve as the primary assurance model.
Technical breakdown
Why vulnerability assessment stops at candidate risk
Vulnerability assessment is designed to enumerate known weaknesses from version, signature, or authenticated configuration data. It is useful for hygiene and compliance, but it does not prove reachability, chaining, or business impact. A scanner can identify a CVE and still tell you nothing about whether an attacker can actually use it from the internet or combine it with another flaw. That is why VA creates large candidate lists but weak risk answers.
Practical implication: Use VA as an input to prioritisation, not as proof that a control failure is exploitable.
How BAS differs from exploit validation
Breach and attack simulation runs known techniques against defensive controls to see whether detection or blocking works. It is a control validation exercise, not an attempt to discover new weaknesses or build attacker chains. BAS answers whether the SOC stack, EDR, firewall, or SIEM reacts as expected, which makes it valuable for drift detection. But because it follows a script, it cannot replace adversarial reasoning about attack path selection.
Practical implication: Use BAS to measure defensive coverage, then separate that result from exploitability testing and application depth work.
What CART adds to continuous offensive testing
Continuous automated red teaming aims for an objective such as crown jewel access and adapts the path to get there. Unlike BAS, it is not technique-first; unlike traditional pen testing, it is designed for repeated execution at operational cadence. The architecture matters because the attacker may pivot through shadow assets, exposed APIs, or credential reuse rather than the most obvious vulnerability. That makes CART a better fit for measuring whether exposure management translates into reachable compromise paths.
Practical implication: Use CART when you need objective-based validation of whether an adversary can reach high-value assets, not just whether a control fires.
Threat narrative
Attacker objective: The attacker objective is to move from exposure discovery to a validated path into high-value systems or data, proving that the organisation's surface is not merely visible but reachable.
- Entry begins with exposed assets, forgotten subdomains, or internet-facing services discovered through ASM or CTEM scoping.
- Credential access or exploitability testing then determines whether those exposures can actually be used, rather than merely listed as theoretical risk.
- Escalation and chaining reveal whether the initial foothold can reach crown jewels through privilege escalation, lateral movement, or application-to-network pivoting.
- Impact is measured by whether the attacker can prove a path to data exfiltration or other material compromise rather than a scan result alone.
Breaches seen in the wild
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Exposure discovery and exploit validation are different governance problems: organisations that treat them as one control end up funding visibility without reduction in compromise likelihood. VA, ASM, BAS and CART each sit at a different point in the security decision chain. The governance failure is category collapse, where reporting volume is mistaken for defensive progress. Practitioners should map each tool to the question it actually answers.
Continuous offensive security is becoming the default operating model: the article reflects a market shift from annual assurance to ongoing validation. That shift matters because application change, API exposure and credential-driven access do not follow audit cycles. In identity-heavy environments, the gap is often not discovery but whether access paths can be used to move from one system to another. Practitioners should assume cadence is now part of control design.
Attack surface management is only valuable when it hands off to validation: exposure inventories without proof of exploitability create triage debt and false prioritisation. The article is right to treat validation as the point where CTEM becomes operational rather than descriptive. Validation debt: the backlog created when organisations can name exposed assets but cannot prove which ones matter. Practitioners should measure how much of their exposure inventory ever reaches exploit testing.
The rise of CART and AEV shows that buyers want outcomes, not tool labels: the market is converging around continuous exposure validation, but many programmes still buy disconnected point solutions. That fragmentation is especially damaging where identity, credential reuse, and application reachability drive actual compromise paths. Practitioners should evaluate whether they are buying dashboards, control checks, or adversarial proof.
Identity and access pathways are central to modern compromise chains: the article repeatedly shows that credentials, privilege escalation, and pivot paths determine whether exposures become incidents. That makes offensive testing relevant to IAM and NHI governance, not just perimeter security. Practitioners should ensure offensive validation covers access paths, not only CVEs and exposed services.
What this signals
Validation debt: the real operational failure is not lack of tooling but lack of proof that exposed assets are actually exploitable. When exposure inventory outruns validation capacity, prioritisation becomes a queue management problem instead of a security decision.
In identity-heavy environments, offensive testing should increasingly follow the access path rather than the asset list. That means validating whether credentials, privilege boundaries and application pivots can actually produce compromise, not just whether a scanner can name the surface.
Programs that stop at discovery create false confidence for boards and risk committees. The useful governance question is no longer how many exposures were found, but how many were proved blockable, chainable or truly exploitable.
For practitioners
- Separate exposure discovery from exploit validation Map VA, ASM, BAS, pen testing and CART to distinct programme decisions so no single tool is expected to answer all of them.
- Use CTEM to stage validation handoffs Require every discovered exposure to move from inventory into a validation step that proves reachability, exploitability or block effectiveness.
- Measure attack-path coverage, not scan volume Track how many assets are merely found versus how many are tested for chaining into privileged access, lateral movement or data access.
- Test identity-driven pivot paths explicitly Include credential reuse, privilege escalation and application-to-network pivots in offensive exercises so identity paths are not left unvalidated.
- Align board reporting to validation outcomes Report how many exposures were confirmed exploitable, how many were blocked by controls, and where continuous validation still has no coverage.
Key takeaways
- BAS, CTEM, CART, VA, ASM and AEV solve different operational problems, and conflating them creates control gaps as well as duplicate spend.
- The article’s central warning is that discovery without validation leaves teams with exposure inventories but no evidence of exploitability.
- Continuous offensive testing matters because modern environments change faster than annual assurance cycles, especially where identity paths and exposed services shape real compromise routes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article centres on validated attack paths, credential abuse and pivoting into crown jewels. |
| Recommendation — Map offensive validation findings to credential access and lateral movement to prioritise paths that lead to real compromise. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Identity and access paths are part of the exposure chain that CART and pen testing should validate. |
| Recommendation — Test whether permissions and entitlements can be abused to reach protected assets, then close the reachable paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | Credential reuse and account paths are repeatedly described as mechanisms for attack-path success. |
| Recommendation — Review account lifecycle and access scope so offensive tests can focus on accounts that would actually enable compromise. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article highlights credential-driven pivoting and the need to validate authenticators as part of exposure risk. |
| Recommendation — Apply authenticator management controls to reduce the chance that exposed credentials become valid attack routes. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | ASM and validation discussions include exposed services and APIs that may be reachable before exploitability is known. |
| Recommendation — Validate API and service configurations so exposed endpoints are assessed for exploitability, not just discovered. | ||
Key terms
- Breach and Attack Simulation: Breach and attack simulation is the practice of repeatedly running safe attack-like tests against live environments to see whether controls detect or block them. It measures defensive effectiveness across real paths, not just policy intent, and is most useful when tied to current threats and business-critical assets.
- Continuous Automated Red Teaming: Continuous Automated Red Teaming is the ongoing use of automated attack simulations to test security controls, detection, and response. It repeatedly emulates adversary behavior across systems, identities, and workflows, then measures whether defenses detect, block, or contain the activity. The goal is to expose control gaps before real attackers do.
- Attack Surface Management: Attack surface management is the practice of finding and evaluating assets that could be exposed to misuse or compromise. CAASM focuses on internal visibility across the environment, while EASM focuses on externally reachable assets. It is a discovery discipline, not a complete identity control model.
- Adversarial Exposure Validation: Adversarial Exposure Validation is the practice of testing whether an environment can be exploited in realistic attack paths. It combines controlled offensive techniques, attack simulation, and exposure analysis to identify reachable weaknesses, misconfigurations, and privilege chains. The goal is to measure actual exploitability, not just the presence of individual vulnerabilities.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is a useful path for practitioners who need to connect access governance to broader security operations and risk management.
Published by the NHIMG editorial team on September 6, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org