← Back to blog

August 7, 2026 Penetration Testing

Manual Vs Automated Penetration Testing: Pros, Cons, And When To Use Each

Automated penetration testing uses scanners to catch known CVEs, misconfigurations, and injection flaws on every deployment, at low cost per endpoint. Manual penetration testing puts a skilled tester on the flaws scanners cannot detect: cross-role authorization, IDOR across tenants, and business logic abuse. Most products need both. If budget allows only one, run continuous scans plus one manual test each year.

Penetration testing began as an entirely human exercise. A consultant sat with your application for a fixed window, probed it by hand, and wrote up what broke. As attack surfaces grew from a handful of servers to hundreds of endpoints across dozens of services, the tooling grew alongside: scanners that run on every deployment, and more recently agent-based systems that can chain steps on their own. Today both methods are mature, both are widely used, and both carry real strengths and real limits.

That history is why the choice between them is a coverage decision rather than a budget one. Some vulnerability classes produce a signature a machine can match. In others, the flaw stems from a valid request sent by the wrong identity, producing no signature at all. Which of those classes exist in your product determines which method you need, which means your requirements decide the answer, and neither method wins in the abstract.

Most comparisons of the two resolve to a recommendation to use both. That is accurate, and it does not support a decision. It identifies neither what to fund first nor what your current coverage omits.

The pros and cons below cover both methods in full, including the limits of each, so you can draw the coverage line for your own product. That line runs along the vulnerability class, which is the axis this decision actually turns on.

Summary

Table of Contents

TL;DR

What automation finds

Automation reliably finds vulnerabilities that have a signature. Known CVEs in dependencies, configuration drift, and injection in crawlable inputs. In those classes it beats human testers on both speed and recall, and it runs on every deployment.

What it misses

It cannot find flaws where a valid request is sent by the wrong identity. Cross-role authorization, IDOR across tenants, and business logic abuse produce no distinctive signal, because the response is indistinguishable from an authorized one.

The two are not competing on the same axis.

AutomationAutomation buys breadth and frequency.

Manual testingManual testing buys depth in the identity graph.

That is why “use both” is technically correct and operationally empty.

Compliance

PCI DSS requires penetration testing explicitly. SOC 2 and ISO 27001 do not name it in their criteria, and auditors expect it regardless.

If you can only fund one

Scan continuously and test manually once a year.

Start here

Count how many distinct roles can hold a valid session in your application, including service accounts and support tooling. Two or more means the classes carrying most of your risk sit outside what automation reaches.

Scope a manual pentest

What is the Difference Between Manual and Automated Penetration Testing?

Automated penetration testing runs a predefined set of checks against a target and reports which ones matched. Manual penetration testing puts a person in that loop, choosing what to send next based on what the last response returned.

The difference is not effort or cost. It is whether the test can form a hypothesis. A tool asks a fixed question of every endpoint. A tester asks a different question of the endpoint that just behaved strangely, and that second question only exists because of the first answer.

NIST draws the same line in its own vocabulary. SP 800-115 groups discovery, enumeration, and vulnerability scanning under target identification and analysis. Establishing that a candidate weakness is actually exploitable sits separately, under target vulnerability validation. The first category is almost entirely tool work. The second is where an assessor is required.

Two boundaries. This is not the difference between a penetration test and a vulnerability scan, which is a category question covered in pentest vs vulnerability scan. It is not about how to evaluate a vendor’s oversight model, which is covered in AI penetration testing, but what you should know before choosing a vendor. Everything below is about execution, and what each method can actually reach.

Manual vs Automated Penetration Testing at a Glance

The table below puts the two methods side by side. Every method of testing fails in a characteristic way, and the “fails by” row shows the trade-off you accept with each.

	Automated	Manual
Strongest at	Known CVEs, configuration drift, injection in crawlable inputs	Cross-role authorization, IDOR across tenants, business logic, chained exploits
Cannot reach	Any flaw where a valid request is sent by the wrong identity	Full endpoint coverage inside a fixed engagement window
Cadence	Every deployment, continuous	Annually, plus after any change to roles or authorization
Cost shape	Low per endpoint, scales with surface area	High per endpoint, scales with attention
Fails by	Missing what has no signature, and producing false positives your team pays to triage	Going stale the day after, and varying between testers
Compliance role	Evidence of continuous vulnerability identification	Evidence that a skilled tester attempted to defeat your controls

What are the Pros and Cons of Automated Penetration Testing?

Automation is the baseline most products should already have. The question is not whether it works, because it does, but where it stops being coverage and starts being reassurance. The pros are larger than most posts written by manual testing firms will admit.

They fall into three groups: things a tool does better than a person, things a person cannot practically do at all, and one that changes what a manual test is for.

Recall on known vulnerabilities

A tool comparing your dependency lockfile or your host software versions against a CVE database beats any human on both speed and completeness, every time. This is not close.

Deterministic configuration checks

TLS settings, security headers, exposed administrative interfaces, default credentials, and public storage buckets are comparisons against a known-good state. There is nothing to reason about, so reasoning confers no advantage.

Surface discovery

A tool enumerates what you have, which is frequently not what your architecture diagram says you have. Subdomains, undocumented endpoints, staging environments left reachable, API versions nobody deprecated. A human tester works from the scope you hand them. A crawler finds the scope you forgot.

Consistency

A tool does not get tired at endpoint 400 of 600. It checks every one the same way and returns the same result on Tuesday that it returned on Friday. Human attention degrades on repetitive work, and the classes above are almost entirely repetitive work.

Those four are things a tool does better than a person. The next five are things a person could do in principle but it becomes almost impossible to do, because the cadence or the cost makes it impractical.

Frequency. A manual test is a snapshot of one day. Automation runs on every deployment, which catches the regression introduced 3 weeks after the report was signed. On an annual cadence, the gap between snapshots is 364 days.
Regression baselines. Frequency tells you the test ran again. A baseline tells you what changed, so a reintroduced flaw is flagged as a reintroduction rather than as a new finding. A manual test carries no memory of the last one unless the same tester returns to the same code.
Cost per endpoint. Across a modern API surface, automated coverage costs a small fraction of what the same coverage would cost in human hours, and it should. The same holds across environments. Checking production, staging, and 40 microservices that share one authentication middleware costs a tool almost nothing extra.
Retest is nearly free. PCI DSS Requirement 11.4.4 expects exploitable findings to be corrected and testing repeated to confirm the fix. Re-running a tool costs a pipeline minute. Re-engaging a tester costs a scheduling cycle.
A repeatable audit trail. Timestamped and re-runnable. For evidence of continuous vulnerability identification, that beats an annual PDF.
Automation makes the manual test better. This is why the two are complements rather than substitutes. A 2-week engagement is 10 working days. If the known CVEs, the misconfigurations, and injection in crawlable inputs are already cleared, none of those days go to finding them.

All 10 go to the authenticated layer, where a manual test finds what nothing else does. Begin a manual engagement with no automated coverage in place, and part of the budget is spent doing a tool’s job.

The cons are structural not a maturity problem that better tooling fixes next year.

None of these limits is a gap in somebody’s product roadmap. They follow from what a detection tool is: something that compares what it observes against a description of what bad looks like. Where no such description can exist, or where the tool never reached the thing worth observing, the limit holds no matter how good the tool gets.

No model of identity

A tool can enumerate every object reference in your application. It cannot know which of them should belong to whom, because that fact lives in your business rules and nowhere in the traffic.

Dependence on a signal

Detection works by recognizing an indicator: a database error, reflected script content, a stack trace, an unexpected status code. Where the vulnerability produces no distinctive artifact, there is nothing to match.

Authentication is where tools quietly lose coverage

Multi-step login, MFA, SSO redirects, device attestation, short-lived tokens, and signed requests all break automated session handling. A tool that falls out of session does not stop and report that it fell out of session. It carries on, and it tests the login page several hundred times. The finding count looks normal, and the authenticated surface was never reached.

The crawler only tests what the crawler can reach

Endpoints invoked only by a mobile client, GraphQL resolvers absent from the introspection schema, routes behind a feature flag, and anything that requires a specific object to exist first all sit outside a crawl. They are not listed as untested. They are simply absent.

No state, and no sequence

A tool sends each request independently. It cannot create an order, abandon it, and then attempt a refund against it, which is the shape of most workflow abuse. Race conditions and time-of-check to time-of-use flaws need 2 requests timed against each other, and that is a test design problem rather than a payload problem.

Severity arrives without context

A CVSS vector describes the mechanics of a flaw, not what sits behind the endpoint. An exposed test route can score higher than an authorization gap in front of customer records, and both land in the same queue at the same priority. Left unedited, that inverts your remediation order.

False positives are paid for in engineering hours

Unvalidated findings cost the vendor nothing. They cost your team a sprint of triage, and that cost is invisible in the price of the scan.

Tuning debt accumulates

Someone maintains the configuration, the authentication recording, and the exclusion list. A suppression added in March to quiet a noisy rule is still suppressing it in November, and nobody re-reads it. This is unglamorous, and it is where coverage is lost without anyone deciding to lose it.

Coverage figures are measured against a narrow denominator

The OWASP Benchmark Project is the most widely used yardstick for scoring automated detection tools. Version 1.2 for Java comprises 2,740 test cases spanning 11 vulnerability areas: command injection, weak cryptography, weak hashing, LDAP injection, path traversal, secure cookie flag, SQL injection, trust boundary violation, weak randomness, XPath injection, and cross-site scripting. Not one of them is an access control weakness. OWASP lists covering all vulnerability types in the Top 10 as a potential future enhancement, which is the project acknowledging the same gap.

The Benchmark was built to measure code-level detection by static, dynamic, and interactive tools, so the absence of access control cases is a scoping decision rather than a failure. OWASP is candid about the limits of its own instrument, noting that the test cases are simpler than production code and that real applications are harder to analyze. The practical effect stands anyway. When a vendor quotes a detection rate, ask which categories were in the denominator.

A tool cannot tell you what it did not test

Every limit above compounds into this one. A clean report produced from full coverage and a clean report produced by a tool that dropped its session on the third endpoint are the same document. There is no field for the endpoints the crawler never found, the roles it never held, or the sequences it could not construct. That silence is what makes a clean scanner report feel like an answer, when it is a description of one instrument’s reach.

What are the Pros and Cons of Manual Penetration Testing?

Manual testing costs far more per endpoint than automation, so the case for it cannot rest on doing the same work more carefully. It has to rest on work automation cannot do at all. Its weaknesses are equally real, and several of them are rarely stated by the firms that sell this service.

The pros come down to reasoning about relationships between things.

What a tester finds here is never visible in a single request. It exists in the relation between two things: a session and an object, one role and another, the step just completed and the step now permitted. A tool examines requests one at a time, so it has nothing to compare.

Role pairs. 3 roles produce 6 directional pairs. A tester holding 2 valid sessions at once can ask whether this role should reach this object, which is the question carrying most authenticated-layer risk.
Chaining. 4 findings, each individually low severity and each individually correct behavior, that combine into account takeover. A tool scores each step. Only a person scores the sequence.
Testing for what is absent. A tool checks whether a bad thing is present. It does not notice that a good thing is missing. No rate limit on the password reset endpoint, no re-authentication before an email change, no audit record written when an admin opens a customer account. Absence has no signature either, and a substantial share of real risk lives there.
Design rather than implementation. OWASP lists insecure design as A04 in the 2021 Top 10, which recognizes that some flaws are decisions rather than defects. A tool tests the code that was written. A tester can ask whether the feature should have been built that way at all, which is the only route to a flaw with no incorrect line to point at.
Trust between services, not only between users. Role pairs are the visible version of this problem. The harder version is an internal API that treats any caller inside the network as authorized, or a service token whose scope nobody has audited since it was issued. Finding that requires reading how the system was assembled rather than scanning what it exposes.
Reproduction. A finding reproduced by a human is a proven result. A finding that has not been is a claim. The difference shows up in whether your engineers trust the report enough to act on it in week one.
Severity in context. 2 findings can be technically identical and matter differently, because one sits in front of data that would end a customer relationship. That judgment requires knowing what your business does.
Accountability. Someone signs it, and you can ask them questions.

A finding is where the work start. It is also where most reports stop. Someone who reproduced the flaw in your application can tell you which of the available fixes survives your architecture, what it will break, and how to confirm it held. A report that stops at the finding has handed you a research task and called it a deliverable.

Manual testing has weaknesses that no amount of skill removes.

A vendor listing the weaknesses of the thing it sells is unusual enough to be worth explaining. The coverage argument above only works if you can trust the boundaries drawn around it, and you cannot check those boundaries against a page that admits no limits.

It is a snapshot. The report describes your application on the day it was tested. Ship on Thursday and part of it is already historical. This is the strongest argument for automation and it has no manual counterargument.
It does not scale to your endpoint count. Nobody tests 600 endpoints across 6 role pairs in 2 weeks. Someone chose what not to test, and unless the report says so plainly, that choice is invisible to you. Ask for it.
Scope is set before anyone has looked. You define the boundary of the engagement before any evidence exists, which makes the scope an informed guess. The finding that would have mattered most can sit one subdomain outside it, and a fixed-price engagement creates no incentive to widen it mid-test.
Variance between testers. 2 competent testers produce different reports on the same target. Skill, familiarity with your stack, and where they spent the first 2 days all move the outcome. Vendors rarely volunteer this.
Cost per endpoint is high, and it should be, because what is being bought is attention.
It is slow. Weeks to schedule, weeks to run, weeks to report. That cadence fits an annual audit and fits a weekly release train badly.
Worse recall on known CVEs than a tool. A human working a dependency tree by hand will miss things a scanner catches in 90 seconds.
A signed report is more persuasive than it is complete. A named researcher’s report carries more weight with your board and your auditor than a tool’s export does, and that weight is not proportional to coverage. The endpoints nobody reached went untested either way. Ask what sat outside scope before you circulate it.

Those two lists are not mirror images. Any post presenting them as a balanced trade-off is misleading you. Automation’s advantages are all about time and breadth: frequency, consistency, and cost across a wide surface. Manual testing’s advantages are all about depth in the identity graph: which role, which object, which order. They are not better and worse at the same job. They are good at different jobs, which is exactly why “use both” is correct and empty. The question that produces an actual decision is which vulnerability classes carry your risk.

Which Vulnerabilities Can Automated Penetration Testing Find, and Which Need Manual Testing?

This is the table the rest of the post rests on. Each row is a class of flaw, and the question is not which method is better at finding it but whether the flaw leaves anything behind for a machine to match. Read down the left column and stop at the rows that describe your own product.

Vulnerability class	Found by automation	Needs a human	Why
Known CVEs in dependencies	Yes	No	Version and signature matching is solved
TLS config, headers, default credentials	Yes	No	Deterministic checks against a known-good state
Reflected XSS and classic injection in discoverable parameters	Mostly	Occasionally	Mechanical payload injection into a crawlable input, with a distinctive response
SSRF and deserialization	Partial	Often	Detection is reliable, confirming reachable impact usually is not
SSO and SAML assertion handling	Partial	Usually	Requires a valid identity provider and a deliberately malformed assertion
IDOR across tenants (CWE-639)	Rarely	Yes	The tool cannot know which object should belong to whom
Cross-role authorization (CWE-863, CWE-284)	No	Yes	Needs 2 valid sessions and a model of what each role should reach
Business logic and workflow abuse (CWE-840)	No	Yes	The bug is the intended function, used in an unintended order
Chained multi-step exploits	No	Yes	Each step is individually low severity and individually correct

The pattern down the table is consistent. Automation wins wherever the vulnerability has a signature, and loses wherever the vulnerability is a valid operation performed by the wrong identity, against the wrong object, or in the wrong order.

Why broken access control has no signature

Broken access control is the largest category in the OWASP Top 10. It moved up from fifth place to first in the 2021 edition, and it accounts for 318,487 occurrences across 34 mapped CWEs, more than any other category in the contributed dataset. The three CWEs in the bottom rows of that table, CWE-639, CWE-863, and CWE-284, all sit inside it.

So the class automation reaches least well is also the class that occurs most. This is the mechanical reason those rows read the way they do.

A request that reaches another tenant’s record returns HTTP 200 and a well-formed body, which is exactly what a correctly authorized request returns. The two responses are indistinguishable on the wire. The flaw exists only in the relationship between the identity holding the session and the object being returned, and that relationship is defined by your business rules.

OWASP makes the same observation about the adjacent class. Its guidance on business logic weaknesses notes that these flaws resist automated discovery precisely because exercising them looks like ordinary, permitted use of the product.

CVE-2026-10753 in Google’s Site Kit for WordPress is this exact flaw. A REST API write endpoint the plugin failed to restrict to administrators, which lower-privileged users who had been granted dashboard sharing access could reach. The upstream fix is in google/site-kit-wp pull request 12349. CWE-863, incorrect authorization. CVSS 2.7, which is low, and we said so in our own writeup at the time.

The severity is not the point. Reaching that endpoint required holding a valid session, knowing the capability behind it was the wrong one for that role, and sending a request that looks entirely legitimate. An unauthenticated scanner cannot get there. An authenticated scanner without a per-role capability model does not know the request was wrong. The gap is not in the tool’s payload library. It is in the tool’s understanding of who should be allowed to do what.

Footnote for anyone cross-referencing: WPScan maps this to A5 Broken Access Control, which reflects an older OWASP edition. OWASP moved the category from fifth place to A01 in the 2021 Top 10.

When to Use Automated Penetration Testing vs Manual Penetration Testing?

The conditions below are meant to be checked rather than weighed. If every item in the first list describes your product, automation on its own is a reasonable place to stop. If any single item in the second list describes it, it is not.

When automated testing is enough on its own

Automated coverage alone is a defensible choice when all of these hold:

The application has one role. No tenancy, no privilege tier, no admin surface reachable from a customer account.
Nothing sensitive sits behind authentication. If the authenticated experience is a settings page and a profile photo, the authenticated layer is not where your risk is.
You need regression coverage between manual tests. This is automation’s best use, not its fallback use.
You are gating pre-production to stop known-bad code from shipping. That is a build-pipeline job and a tool does it better.

When to choose manual penetration testing

Manual testing is the part that covers the gap when any of these are true:

Two or more roles can hold a valid session, including service accounts and support tooling.
One customer’s data can be addressed by an identifier another customer could guess or enumerate.
A multi-step workflow exists where the order matters: checkout, approval chains, refunds, provisioning, anything with a draft state.
A compliance regime requires evidence that a skilled tester attempted to defeat your controls, rather than evidence that a tool ran.
You are about to hand a report to an enterprise customer who will read the scope statement.

If you can only afford one, scan continuously and test manually once a year. Do not do the reverse. Continuous coverage of the easy classes plus one deliberate pass at the hard ones beats an annual pass at everything and nothing in between. That holds regardless of who you hire.

4 questions that settle it for your product

Answerable today, without a vendor call.

How many distinct roles can hold a valid session? Count service accounts and internal support tooling. Two or more means you have role pairs.
Can one customer’s data be addressed by an identifier another could guess? Sequential integers, predictable UUIDs, and object references exposed in URLs or GraphQL queries all qualify.
Is there a workflow where the order of operations matters? Automation tests each step. Only a human tests the sequence.
What did your last report say about authenticated endpoints, specifically? Not the finding count, the scope statement. If the tool was never given credentials for more than one role, the clean result describes one role’s view of your product.

One role, no enumerable references, no stateful workflow: automation is proportionate. Any other combination means the classes carrying your real risk sit outside what automation reaches.

What do SOC 2, PCI DSS, and ISO 27001 Actually Require?

Of these three frameworks, only PCI DSS names penetration testing in its written requirements. SOC 2 and ISO 27001 leave the choice of evidence to you, and in practice auditors expect a penetration test under both. Knowing which framework asks for what lets you plan your evidence before the audit begins.

The distinction worth holding onto as you read the table is between what a framework requires and what an auditor expects. Skip something a framework requires and you have an audit failure. Skip something an auditor merely expects and you have a conversation.

Framework	Names penetration testing?	Where	What it means for you
PCI DSS v4.0.1	Yes, explicitly	Requirement 11.4, with sub-requirements for methodology, internal, external, remediation retest, and segmentation	Internal and external testing at least every 12 months and after significant change. A scanner export with a cover page is not a penetration test
SOC 2	Not in the criteria	Named among the points of focus accompanying CC4.1, as one type of separate evaluation	You may satisfy CC4.1 another way, but you carry the burden of justifying the alternative to your auditor
ISO/IEC 27001:2022	Not in Annex A	Referenced in ISO/IEC 27002:2022 implementation guidance for A.8.8 and A.8.29	Risk-based. The controls expect technical vulnerability identification and security testing, and a test is the evidence auditors recognize

The SOC 2 line is the one most often stated loosely. It is common to read that the Trust Services Criteria never mention penetration testing, and that is not quite right. No criterion requires it. Penetration testing appears in the points of focus accompanying CC4.1, which addresses ongoing and separate evaluations, as an example of the kind of evaluation management may use.

Points of focus are not requirements. That distinction is the whole answer: the framework does not compel a test, and it does name one, which is why auditors ask and why declining costs you a written justification instead of a purchase order.

More depth on the audit side sits in SOC 2 penetration testing, what you should expect before an audit.

What Should You Ask a Vendor Before Commissioning Either?

Before you hire

Four questions that work regardless of who you hire

How many roles will you hold sessions for, and will you test every pair?

3 roles is 6 directional pairs, not 3. Ask which are in scope.

What will you not get to, and how will you tell me?

Every engagement leaves something untested. A vendor who names the boundary is describing a method.

Show me a finding a scanner could not have produced.

Redacted is fine. If nothing in the sample required a second session or a multi-step sequence, you are buying a scan with a narrative.

Who signs the report, and can I talk to them?

A name is accountability. An unnamed report is a document nobody has to defend.

Any vendor worth hiring can answer all four without flinching.

See how we answer these

Additional read: AI penetration testing, what you should know before choosing a vendor covers the oversight and validation model in depth, which is the next question after this one.

FAQs

Seven questions that come up in almost every scoping conversation about manual vs automated penetration testing.

Q1. Which is better, manual or automated penetration testing?

Neither, because thoroughness is the wrong axis to compare them on. Automation is better at every class of flaw that leaves a signature behind, and it is not close: known CVEs, configuration drift, and injection in crawlable inputs.

Manual testing is the only option for anything where the flaw is a valid request sent by the wrong identity, because there is nothing for a tool to match against.

A product with one role and nothing sensitive behind the login is genuinely well served by automation alone. A product with 3 roles, guessable object references, and a refund workflow is not, and no improvement in tool quality changes that. What settles it is which of those two profiles matches your product.

Q2. Can automated penetration testing replace manual penetration testing?

For some products it already has, and for most it cannot, and the dividing line is not tool quality. For replacement to work, a tool would need a model of which identity should legitimately reach which object in your application.

That model exists in your business rules, and somebody has to state it before anything can test against it. Where those rules are simple enough to state exhaustively, automation can enforce them well.

Where they involve several roles, tenancy, and a workflow with order dependencies, stating them is most of the work, and a person is doing that work either way. So the useful version of this question is not whether tools will improve, because they will. It is whether the missing input is something a tool can acquire on its own.

Q3. Is automated penetration testing the same as vulnerability scanning?

Not quite, though the overlap is large enough that the terms get used interchangeably. A vulnerability scan identifies and reports candidate weaknesses. An automated penetration test additionally attempts to exploit some of them and chains a limited set of steps, which reduces false positives and produces evidence of reachability.

That boundary has moved considerably in recent years and continues to move. What has not moved is the class boundary above: both are limited to weaknesses that produce a recognizable signal, and neither holds a model of which identity should legitimately reach which object. The category distinction is covered in pentest vs vulnerability scan.

Q4. Does a vulnerability scan count as a penetration test for SOC 2 or PCI DSS?

Not for PCI DSS, and for SOC 2 it depends on your auditor. PCI DSS Requirement 11.4 expects internal and external penetration testing carried out against a documented methodology, and a scanner export with a cover page does not satisfy it. Vulnerability scanning sits separately under Requirement 11.3, which is the clearest indication that the standard treats the two as different activities with different purposes. SOC 2 is looser. No criterion requires either one, and CC4.1 asks only that you perform evaluations sufficient to establish that your controls are present and functioning. A scan can form part of that evidence. In practice auditors ask for a penetration test, and offering a scan instead means proposing an alternative and carrying the burden of justifying it. ISO 27001 works the same way, since Annex A names neither activity directly.

Q5. How often should each one run?

Automated coverage should run continuously, or at minimum on every production deployment, because its value comes from frequency. Manual testing runs at least annually for most products, and additionally after any change to authentication, authorization, tenancy model, or role definitions. PCI DSS sets an explicit floor of every 12 months plus after significant change under Requirement 11.4. SOC 2 and ISO 27001 set no cadence, and annual is what auditors have settled on in practice. One trigger worth adding to the calendar rule: test manually whenever you ship a new role, because a new role multiplies the pairs that need checking.

Q6. Can AI-led penetration testing close the gap?

Partly, and the honest answer has two halves. Agent-based tools have made real progress on chaining steps and reasoning about application state, which are exactly the capabilities classical scanners lack, and it would be dishonest to describe the gap as fixed in size. The unresolved half is validation. A system that can hypothesize can also hypothesize wrongly, and a finding that has not been reproduced is a claim rather than a result. Our own model is human led, machine assisted: machine reach across the authenticated product, human judgment on what counts as a finding. What you should ask any vendor in this category, including us, is what happens between the tool’s output and your ticket queue.

Q7. What does a manual test find that we would not have found ourselves?

Usually the pair nobody thought to test. Teams test each role against its own permissions, which is a correctness check, and the flaw lives in the direction nobody exercised: what the support role reaches inside a customer tenant, what the read-only integration token can write, what a deactivated account still holds. The value is not exotic technique. It is systematic coverage of every direction between every pair of identities, tedious enough that internal teams rarely finish it and small enough case by case that no scanner flags it.

See what a validated finding looks like. A CredShields researcher will walk you through a reproduced cross role authorization finding, the supporting evidence, and its business impact. Talk to a researcher now.

If you want the format first, the sample pentest report shows how a reproduced finding is documented.