I’m often asked by skeptical information security practitioners: Why would we give you any information at all, or add you to an allowlist? Shouldn’t you have the same access an attacker would?
Fair question, and it comes from the right instinct. There are three basic approaches to penetration testing, and all three are legitimate. They answer different questions, and the one you choose determines which categories of vulnerability you are able to find at all.
The Three Approaches
Black box means the tester gets nothing beyond the targets in scope. No credentials, no source code, no architecture documents. The penetration tester will look at your environment from an outside perspective, the same way an anonymous attacker on the internet would approach it.
White box is the opposite. Full access to source code, architecture documentation, and privileged credentials. Nothing is hidden.
Grey box sits between them. You give the vendor some knowledge of the environment and a set of credentials. We start inside the door instead of spending the engagement looking for a way in.
Black Box Penetration Testing
Black box testing validates your perimeter. If you want to know whether your firewall rules, WAF configuration and exposed services are doing their job, this is the test that tells you.
Some organizations are explicit about wanting exactly that. They won’t hand over access, because the thing they want validated is that their controls are functioning as expected and nothing more.
The limitation is coverage. Anything behind a login is largely out of reach, unless the tester finds their own way in. Privilege escalation, business logic flaws, broken access controls between user roles: none of it surfaces if the tester never authenticates.
White Box Penetration Testing
White box has the potential to uncover findings the other two approaches cannot. If a vulnerability sits in a code path no interface will ever trigger, source-level review is how it gets found. Root cause is easier to determine, since a finding traces straight back to the line that caused it. That depth comes at a cost.
The first is realism. Imagine hiring someone to test your apartment’s security, then handing over your door key, your weekly schedule, your alarm code, your garage code, and the combination to your safe. They’ll get in, and they’ll find weaknesses along the way. What you won’t learn is which of those weaknesses a real burglar could actually reach.
A door key is the kind of thing a burglar can plausibly get. The safe combination typically isn’t, and the white box approach requires it. That’s a valid worst case (a leaked repository, a malicious insider), just rarely the one organizations are trying to measure.
The second is practical. Sharing source code and architecture documentation is a procurement and legal problem before it’s a technical one.
The Case for Grey Box Penetration Testing
In apartment terms, grey box is a simulated burglary with a door key. We start where any user starts, and where an attacker starts once a password has been phished or reused.
Edgescan’s 2026 Vulnerability Statistics Report looks at the critical-severity vulnerabilities our team found in 2025 that automation alone typically misses. Five categories make up 59% of them. The largest is API access without authentication or with weak authentication (16%), followed by access restriction bypass (14%), business logic weaknesses (11%), broken access control logic (10%) and account hijack (8%). The common thread is control over who can do what, and in what order.
Most of those vulnerabilities depend on understanding how the application behaves for an authenticated user. Even an unauthenticated API flaw is usually found by comparing what an endpoint returns with and without a valid session.
Which brings us back to the original question. Giving access is not about making it easier for penetration testers. Often it’s the only way to reach the part of your application where critical findings might live.
As for the allowlist, a WAF or IPS can block or throttle much of a penetration tester’s traffic. That tells you the preventative control works, but it hides what sits behind it. Allowlisting takes your preventative controls out of the path so we can test the target itself. If you also want preventative controls validated, test with and without the allowlist.
Grey box pen testing is also efficient. Recon on a black box engagement eats a meaningful share of the available time. Start with credentials and that time goes into authenticated attack paths instead.
What Grey Box Misses
Grey box doesn’t examine your source code. We test the running application, which means there’s no guarantee your code is clean. The reasoning is straightforward. We test the paths an attacker with the same access would realistically take, within the engagement window. A flaw that can only be reached by reading the source requires the attacker to have the source too.
If source-level assurance is a compliance requirement, that is a different type of testing and should be scoped as such.
Choosing an Approach
Ask what you’re trying to prove.
If the question is whether your perimeter holds, run black box. If an auditor requires source-level review, you need white box testing or source code review and should plan for the access and internal lift it demands. If the question is what happens to us when an attacker gets in, run grey box.
Most organizations are asking the third question. They just don’t always put it in those terms.
Talk to us about which model fits your environment..
