Manual penetration testing is a security assessment in which human experts, not automated tools, attack a system with the owner's authorization to find and prove exploitable vulnerabilities. The pentester chains flaws together, abuses business logic and reasons about what the application is for, which is the part a scanner cannot do.
In Fluid Attacks' December 2023 benchmark of 36 third-party AppSec tools against a dataset of 1,201 vulnerabilities across 105 CWE categories, a single pentester found 1,076 of them: 89.6% recall at 100% precision. Of those, 743 vulnerabilities, 61.9% of the dataset, were found by the pentester alone and by no automated tool.
This page covers what manual penetration testing is and is not, why it matters, how it differs from automated scanning, the black, white and gray box approaches, the five phases of an engagement, and how Fluid Attacks runs it continuously instead of once a year.
What is manual penetration testing?
Manual penetration testing is an authorized, simulated attack carried out by security experts who use the same tools and techniques as a real adversary to identify, exploit and report vulnerabilities in a system. The word "manual" is a clarification, not a category: pentesting is human work by definition, and the term exists because vendors began marketing automated scanning as "automated pentesting."
A pentester does use tools. The distinction is not whether software is involved but who decides what to attack next. In a scan, that decision is a fixed ruleset. In a pentest, it is a person who has just learned something about the target and changes plan accordingly.
What manual penetration testing is not: it is not a vulnerability scan, it is not a compliance checkbox, and it is not a one-time event. A report that lists findings nobody attempted to exploit is a scan with a cover page.
Why is manual penetration testing important?
Automated tools tell you where a weakness might be. A pentester tells you what an attacker can actually do with it, and that gap is where most real risk lives.
It proves exploitability, it does not guess it
The NIST Technical Guide to Information Security Testing and Assessment (SP 800-115, 2008) draws the same line: automated techniques identify candidate weaknesses, and manual validation is what confirms whether those candidates are real and reachable. Without that step, a team spends its remediation budget on findings that no attacker could have used.
The severity difference is measurable. In Fluid Attacks' State of Attacks 2026 report, covering all systems assessed between January 1 and December 31, 2025, findings reported by pentesters averaged 93.2 CVSSF units each, against 15.5 CVSSF units for findings reported by automated tools: roughly six times the risk per finding.
It finds what has no signature
Business logic flaws, broken access control and abuse of legitimate functionality have no pattern to match. The OWASP Web Security Testing Guide treats business logic testing as a manual discipline for this reason: a scanner can confirm that an endpoint requires a token, but it does not know that a user of role A should never be able to approve their own transaction.
This is also where the attacker's objective matters more than the individual bug. As Daniel Yepes, Security Analyst at Fluid Attacks, put it about a red team work:
"It also helps to reinforce the idea that obtaining Domain Admin is not the primary objective but part of the way to achieve a final goal."
A scanner has no final goal. A pentester does, and so does the adversary.
Manual and automated testing are not alternatives
The useful question is not which one to buy. It is what each one is good at, and what happens when you skip the other.
Automated tools cover breadth and speed: they run on every commit, across the whole codebase, at a cost per scan close to zero. Manual testing covers depth: fewer findings, far more severe, and reachable only by someone who understands the application.
Measure | Automated tools | Pentesters |
Share of total risk exposure detected | 55.8% | 44.2% |
Share of all vulnerabilities reported | 88.4% | 11.6% |
Average severity per finding (CVSSF) | 15.5 | 93.2 |
Share of critical-severity vulnerabilities | 13% | 87% |
Read the last two rows together. Pentesters reported roughly one vulnerability in nine, and those few accounted for 87% of the critical-severity vulnerabilities reported that year. Breadth without depth leaves the worst issues in production.
Fluid Attacks' comparison of breach and attack simulation, pentesting and red teaming reaches the same conclusion from the cost side: relying on automation alone can be more expensive over time than sustaining continuous manual assessment, because the gap between a new attack technique becoming public and a tool learning to detect it is a window of false negatives that nobody is covering. The same analysis notes that organizations should request testing for every system continuously rather than on an annual cycle.
Go deeper: BAS vs. pentesting vs. red teaming and Types of penetration testing.
Manual penetration testing at Fluid Attacks
We run manual penetration testing as a continuous service alongside our own scanners and AI, not as a separate annual engagement. It is part of the Advanced plan, and what follows is how it works, including where it falls short.
What we test, and under what rules
Every engagement starts from written authorization and a defined scope: which applications, which environments, which techniques are in and out. Nothing is tested that the owner has not agreed to.
Our pentesting is delivered as Pentesting as a Service (PTaaS), and the practice is externally accredited: Fluid Attacks is a CREST-accredited supplier for Penetration Testing and a signatory of the CREST AI Charter. Our pentesters hold OSCP, OSEP, OSEE, OSCE3, OSWE and OSED among more than 60 offensive security certifications across the team.
Findings are not described in free text. Each one is mapped to an entry in our open vulnerability database, where every testing criterion is documented and cross-referenced to CWE and to the standards the client reports against. Two pentesters reporting the same issue on different systems report it the same way.
When the same work turns up a flaw in third-party software rather than in a client's own code, it goes through coordinated disclosure and ends up in our public security advisories.
What it looks like in practice
The engagement does not end with a PDF. A finding moves through a fixed sequence, each step leaving evidence on the platform.
Step | What the pentester produces | What the development team gets |
Report | Proof of exploitation, affected location, severity in CVSSF | A reproducible finding, not a warning |
Classify | Mapping to the vulnerability database entry and to CWE | Compliant-code examples for that exact weakness |
Consult | A 30-minute call on the most complex issues | Direct access to the person who broke it, via Talk to a Pentester |
Reattack | Re-exploitation attempt after the fix | Confirmation that the fix holds, or a reopened finding |
A manually reported finding in the Fluid Attacks platform. The Technique column shows it came from a pentester, not a scanner, and the same view offers the reattack and a call with the pentester who reported it.
The reattack is the part teams underestimate. A fix that was never re-exploited is an assumption.
Exploitation evidence attached by the pentester to the same finding: a recording of the attack and the code behind it. This is what separates a vulnerability that was proven from one that was only flagged.
What the pentester finds that the scanner does not
In the December 2023 benchmark, the pentester detected 99.8% of the dataset's risk exposure measured in CVSSF, against 8.8% for the best-performing third-party tool. On the F1 score weighted by CVSSF, the pentester reached 99.5% and the top automated third-party tool 16.2%.
The 743 vulnerabilities that only the pentester found were not exotic. They were the issues that require understanding what the application is supposed to do before you can tell that it is doing something else.
Go deeper: Benchmarking top AppSec tools and pentesting.
What these numbers do not say
Two things about those numbers that a vendor page would leave out.
First, the benchmark ran against a controlled dataset of 1,201 known vulnerabilities, not a production application with unknown unknowns. A recall figure means "of the vulnerabilities we planted, this share was found." It does not promise the same share of everything that exists in your system.
Second, the automated scanner with the best recall in that benchmark is our own, not a third party's. The fair comparison for a buyer is the one stated above: pentester against the best third-party tool available.
And the structural limit: a pentest does not scale to every commit. A human cannot re-test an application forty times a day, which is exactly what automation is for. Anyone selling manual testing as a replacement for scanning is selling you a coverage gap.
The practice that decides the rest
Finding vulnerabilities is the easy half. The number that moves risk is the share that gets fixed, and the single practice that changes it most is breaking the build on insecure code.
In the State of Attacks 2026 data, systems using our CI Gate reached a 72.2% remediation rate by year's end with a median time to remediate of 22 days. Systems without it reached 58%, with a median of 30 days.
Black box, white box and gray box pentesting
These three terms describe how much the pentester knows about the target before starting. They are not quality tiers; they simulate different attackers.
Approach | What the pentester is given | Attacker it simulates | Main limitation |
Black box | Nothing beyond what is publicly reachable | An outsider with no prior access | Time is spent on reconnaissance instead of depth; internal paths may go untested |
White box | Source code, architecture, credentials, documentation | An adversary with full inside knowledge | Least realistic as an external scenario, but the highest coverage per hour |
Gray box | Partial knowledge: a user account, some documentation | A malicious user, or an attacker who already phished a credential | Coverage depends on which slice of knowledge was shared |
Black box pentesting
The pentester receives no internal information and works only from what is exposed. It reflects the position of an external attacker, and it is the approach that best answers "what can someone reach from the internet?" The cost is time: hours spent mapping the target are hours not spent exploiting it.
White box pentesting
The pentester gets source code, architecture diagrams, credentials and documentation. Coverage per hour is the highest of the three because nothing has to be inferred, and it is the approach that pairs naturally with secure code review. It answers "what is wrong in here?" rather than "what can an outsider do?"
Gray box pentesting
The pentester starts with partial knowledge, typically a low-privilege account. This is the most common real scenario: most breaches begin with some level of legitimate access, whether stolen, purchased or granted. It tests privilege escalation and lateral movement, which black box testing often never reaches.
The five phases of a manual penetration test
The sequence below is the working shape of an engagement. It maps onto the seven phases of the Penetration Testing Execution Standard (PTES), the industry reference that formalized this structure, with threat modeling folded into planning and post-exploitation into the exploitation phase.
Phase here | Corresponding PTES phase |
Planning | Pre-engagement Interactions · Threat Modeling |
Reconnaissance | Intelligence Gathering |
Vulnerability assessment | Vulnerability Analysis |
Exploitation | Exploitation · Post-Exploitation |
Reporting | Reporting |
Planning
Scope, rules of engagement, objectives and authorization are agreed in writing. This is also where the team decides what a successful attack would look like for this specific business, which is what turns a list of bugs into a risk narrative.
Reconnaissance
The pentester gathers everything available about the target: exposed services, technologies, subdomains, employee information, public code repositories. Passive collection comes first, then active probing. The quality of this phase sets the ceiling for everything after it.
Vulnerability assessment
Candidate weaknesses are identified, using automated tools as an accelerator and manual analysis to interpret them. This is where false positives get discarded and where issues that no tool flagged start to appear, because the pentester is now reasoning about how the application's own features can be turned against it.
Exploitation
The pentester attempts to exploit the candidates, chaining them where possible, and then explores what the foothold makes reachable: other systems, other data, higher privileges. A vulnerability that was rated medium in isolation often turns critical here, once it is shown to be the first step of a chain.
Reporting
Each finding is documented with evidence, reproduction steps, severity and remediation guidance, written for the developers who will fix it. In a continuous model, the report is not the end of the engagement; the reattack is.
Conclusions
Manual penetration testing is the part of security testing that no tool has replaced: a human who understands the business attacks the system the way an adversary would, proves what is exploitable, and chains the flaws that look harmless on their own.
The data says the two approaches are complementary, not competing. Automated tools reported 88.4% of vulnerabilities in 2025 but pentesters reported 87% of the critical-severity ones. Teams that run only scanners get volume without depth; teams that run only an annual pentest get depth on a snapshot that is obsolete within weeks. The combination, run continuously and backed by a gate that blocks insecure builds, is what moved remediation from 58% to 72.2%.
Frequently asked questions
How is manual penetration testing different from a vulnerability scan?
A scan flags known vulnerability patterns automatically; a manual pentest has a human expert actively exploit the system and chain flaws a scanner cannot recognize. In Fluid Attacks' 2025 data, pentesters reported 11.6% of all vulnerabilities but 44.2% of total risk exposure, because the issues they find are far more severe: 93.2 CVSSF per finding against 15.5 for automated findings.
What is the difference between black box, white box and gray box testing?
Black box gives the pentester no internal knowledge, white box gives full access to source code and architecture, and gray box gives partial knowledge such as a user account. They simulate different attackers: an outsider, an insider with full visibility, and a malicious or compromised user respectively.
How long does a manual penetration test take?
It depends on scope, but the more useful question is frequency rather than duration. A single engagement on a defined scope typically runs from days to a few weeks; testing integrated continuously into development catches issues while they are cheap to fix, instead of surfacing a year's worth at once.
Can AI tools replace manual penetration testing?
Not today. Fluid Attacks' review of empirical research on generative AI in pentesting found real gains in speed and coverage of routine steps, but concluded that human oversight remains indispensable to validate what the model produces and to decide what to pursue next. See our analysis of GenAI in pentesting.
Does Fluid Attacks do manual penetration testing?
Yes, continuously, as part of a combined approach with AI and our own scanners. Fluid Attacks is a CREST-accredited supplier for Penetration Testing, and every manual finding is reported on the platform with its evidence, mapped to our open vulnerability database, open to a 30-minute call with the pentester who found it, and verified by reattack once fixed.
Put a pentester on it, not once a year
Scanners tell you where to look; our pentesters show you what an attacker would do once they get there, and then try it. Start free trial · Contact us.
