Autonomous Penetration Testing: Market Trends, Real Limits, and Where It Fits

Most organisations still buy penetration testing the way they buy a fire inspection: once a year, scheduled, scoped to what was standing when the purchase order went out. Meanwhile, CISA added a new confirmed-exploited vulnerability to its catalogue roughly every 1.3 days over the past twelve months, and the environment being tested changed on almost every one of those days. Autonomous penetration testing exists because that arithmetic stopped working. This article covers what the term actually means, what is driving the market toward it, where it genuinely outperforms a human tester, and — just as importantly — the classes of finding it will not produce no matter how good the platform gets.

What "autonomous penetration testing" actually means

The term is used loosely enough to be nearly meaningless in vendor marketing, so it is worth being precise. An autonomous penetration test is an automated system that chains weaknesses together without a human driving each step, attempts real exploitation in the target environment, and produces evidence that a specific attack path works — not a list of things that might be exploitable.

The operative words are chains and evidence. A vulnerability scanner tells you a host is missing a patch. An autonomous pentest tool takes that missing patch, uses it to obtain a credential, replays the credential laterally, finds that it grants access to a file share holding a service account password, and stops at domain administrator — then hands you the path with the artefacts that prove each hop. The distinction matters commercially, because a great many products described as autonomous pentesting are scanners with a reporting layer.

Autonomous testing and AI-assisted testing are frequently conflated and are not the same thing. In an AI-assisted workflow a consultant remains the decision-maker and the model accelerates their work; we covered the control loop and safety architecture for that model in building a safe AI-assisted pentesting agent. In an autonomous test the system decides its own next move within a bounded technique library. Those are different risk profiles and different procurement questions.

Market trends: why this category is consolidating now

The clearest signal is that the analyst category itself has been redrawn. Gartner now describes this space as Adversarial Exposure Validation (AEV) — a consolidation that absorbs what were previously treated as two separate segments, breach and attack simulation and automated penetration testing / red teaming. AEV is positioned as the validation stage of Continuous Threat Exposure Management (CTEM): the step that filters a discovered-issues backlog down to what an attacker can actually reach and use, and then retests after remediation to confirm the exposure is genuinely closed.

That framing is the important part, more than any single vendor's positioning. It reflects a shift in what buyers are asking for: not more findings, but proof of which findings matter. Four forces are driving it.

Force 1 — Vulnerability volume has broken the triage model

NIST reports that CVE submissions grew 263% between 2020 and 2025, with early 2026 running nearly a third higher than the same period the previous year. NIST enriched close to 42,000 CVEs in 2025 — 45% more than in any prior year — and still could not keep pace.

The consequence landed in April 2026. NIST changed how the National Vulnerability Database operates: enrichment is now prioritised for CVEs in CISA's Known Exploited Vulnerabilities catalogue, CVEs affecting federal government software, and critical software as defined by Executive Order 14028. Everything else is listed but categorised, in NIST's own words, as "Lowest Priority — not scheduled for immediate enrichment." CVEs published before 1 March 2026 moved to "Not Scheduled" status.

Force 2 — Confirmed exploitation arrives faster than annual testing

CISA's Known Exploited Vulnerabilities catalogue is the most conservative public measure of real-world exploitation: an entry means exploitation has been observed, not theorised. We pulled the catalogue directly (version 2026.08.24) and analysed it rather than citing a secondary summary. As of 24 August 2026 it holds 1,675 entries, of which 274 were added in the preceding twelve months — one roughly every 1.3 days. The pace is steady, not spiky: the trailing 90 days and 2026 year-to-date both work out to the same 1.2–1.3 day interval.

Two details in that data matter more than the headline count. First, 21.0% of catalogue entries are linked to known ransomware campaigns. Second — and this is the one that undermines the annual-test model most directly — 62.3% of actively exploited vulnerabilities in the catalogue carry a CVE identifier from 2022 or earlier. Attackers are not predominantly burning novel zero-days against you. They are exploiting things that have been publicly known for years and remain present because nobody proved they were reachable.

total entries                       1,675
added in trailing 12 months           274   -> one every 1.3 days
added 2026 year-to-date               191   -> one every 1.2 days
linked to known ransomware use        352   (21.0%)
CVE assigned 2022 or earlier        1,043   (62.3%)
listed in same year as CVE assigned   718   (42.9%)

A point-in-time test conducted in March tells you nothing about the 190-odd confirmed-exploited vulnerabilities that will be published before your next one. It also tells you nothing about the ones already in your estate that were not in scope that quarter.

Force 3 — The way attackers get in has shifted toward what changes fastest

Verizon's 2025 Data Breach Investigations Report found that exploitation of vulnerabilities reached 20% of breaches as an initial access vector, a 34% increase year over year, bringing it close to credential abuse as the most common route in.

Where that exploitation lands is the striking part. Edge devices and VPNs accounted for 22% of the exploitation-of-vulnerabilities cases, up almost eightfold from 3% the year before. And organisations struggled to close them: by Verizon's analysis only about 54% were fully remediated across the year, taking a median of 32 days. The same report found the share of breaches involving a third party doubled from 15% to 30%.

Edge infrastructure, remote access and third-party connectivity are exactly the parts of an estate that change between annual tests — and exactly the parts most likely to sit outside a scope agreed months earlier. This is the structural argument for continuous validation: the fastest-moving, most-targeted surface is the one a scheduled engagement is least likely to have covered.

Force 4 — Compliance and commercial pressure now assume re-testing

Regulatory language has quietly moved from "annually" to "annually and after significant change", which is a materially different obligation. Under PCI DSS v4.x, internal and external penetration testing are required at least every 12 months and after any significant infrastructure or application change. Segmentation controls must be tested at least every 12 months, and every six months for service providers. A cloud migration, a new payment API or a firewall rework all trigger the clause — and few organisations can commission a full manual test on each occurrence.

Indian regulated entities face the same directional pressure through SEBI's CSCRF and RBI's master directions, which we cover in detail in the SEBI CSCRF compliance guide and the RBI master direction implementation guide. Cyber insurers have added their own layer, increasingly asking for evidence of validation and remediation rather than a certificate.

Analysts size the resulting market differently enough that any single figure should be treated with caution — 2025 estimates for the overall penetration testing market range from roughly USD 2.4 billion to USD 3.0 billion depending on the firm and what they count. The directional signal is more reliable than the absolute: MarketsandMarkets projects penetration-testing-as-a-service growing from about USD 0.72 billion in 2026 to USD 1.98 billion by 2031, a 22.6% CAGR — roughly double the growth rate attributed to conventional testing. Buyers are shifting spend toward delivery models that repeat.

What autonomous testing is genuinely good at

Set the marketing aside and there is a real, defensible set of jobs this technology does better than a human consultant — not because it is smarter, but because it is tireless, consistent and cheap to repeat.

That last row is where most of the return sits. The value is not the discovery of new vulnerabilities; it is the demotion of thousands of theoretical ones. When the NVD is no longer scoring most of your backlog, reachability evidence becomes the prioritisation signal you have left.

Five things autonomous testing will not do for you

This is the section most vendor material omits, and the one that determines whether the technology helps or quietly creates false assurance.

1. Business logic abuse

A platform can confirm that an API endpoint requires authentication. It cannot know that a discount code should not be applied twice, that a loan status should not be modifiable after approval, or that a partner tenant should not see settlement data for another tenant. Logic flaws are defined by intent, and intent is not present in traffic. These are consistently among the highest-impact findings in a real engagement and they are essentially invisible to autonomous testing.

2. Authorisation reasoning across roles

Broken object-level authorisation requires knowing which identity should be able to reach which object. Detecting that user A can fetch user B's record demands a model of entitlement that comes from product understanding, not from the response. Automated checks find the crude cases — sequential identifiers, missing checks — and miss the ones that depend on the role hierarchy the business actually operates.

3. Chained abuse that crosses systems and processes

The findings that end up in an executive summary usually chain a technical weakness to a process weakness: a low-severity information disclosure that reveals an employee naming convention, combined with a helpdesk reset procedure that does not verify identity properly. Neither half is a finding on its own. Recognising the combination requires knowing how the organisation works.

4. Judgement about real impact

A proven path to domain administrator in a lab-equivalent segment and the same path in the segment processing settlements are technically identical and commercially unrelated. Severity is a business question. Platforms approximate it with asset tags; those tags are usually stale, and the approximation is where credibility is lost with an audit committee.

5. Novel exploitation and safe operation in production

Autonomous systems operate within a technique library. Genuinely novel exploitation — chaining an undocumented behaviour in your own application into something exploitable — remains human work. Separately, running exploitation against production requires judgement about blast radius that a schedule cannot supply. Any serious deployment needs explicit exclusions, change-freeze awareness and a defined abort path.

How to evaluate a platform without buying a scanner

A short set of questions separates genuine validation from repackaged scanning. Ask them during a proof of value, against your own environment, not a vendor demo range.

The operating model that works

The organisations getting value from this are not choosing between autonomous and human testing. They are assigning each to what it is good at, on different clocks.

If you are deciding where a red team fits relative to a penetration test, this comparison covers when to use which.

Metrics worth reporting

Continuous validation makes a better class of metric available. Findings-per-quarter is a volume measure that rewards noise; the metrics below measure whether exposure is actually shrinking.

How Adayptus approaches this

Our position is deliberately unfashionable: automation should expand coverage and cadence, and a consultant should still decide what reaches your report. We use tooling — including autonomous path-finding — to widen what gets touched and how often. We do not ship its raw output as findings.

Concretely, that means every finding we deliver has been reproduced by hand before it appears in your report. It is the reason we are able to commit to zero false positives in delivered findings, and the reason our reports contain the reproduction steps an engineer needs rather than a tool identifier. When you fix something, the remediation retest is included at no additional cost — retesting is the part of the loop that actually reduces risk, and charging for it discourages the behaviour we want.

One clarification we make routinely, because it affects procurement: Adayptus is not empanelled by CERT-In. Where a regulation or contract specifically requires a CERT-In empanelled auditor — as SEBI's CSCRF does for certain VAPT obligations — that engagement needs an empanelled organisation. We are direct about this at scoping rather than after a purchase order.

Where this is heading

Two things follow from the data above. The first is that validation becomes a continuous control rather than a project — the same transition that monitoring made a decade ago, driven by the same underlying cause, which is that the environment changes faster than the assessment cycle. The second is that the scarce resource shifts. When proving reachability is cheap and repeatable, the differentiating skill is no longer finding the weakness; it is understanding the business well enough to know which proven path actually matters, and testing the abuse cases no library contains.

The organisations that get this wrong will be the ones that read a falling finding count as improving security. The ones that get it right will use automation to make the routine continuous, and spend their human testing budget on the things that only humans currently find.

Frequently Asked Questions

Click any question to expand the answer.

References