Black Box vs White Box vs Grey Box Penetration Testing

Every penetration test has to answer one question before it starts: how much does the tester get to know? That single decision — the “box” — shapes what the engagement finds, how long it takes, and what it costs. Here is what black box, white box, and grey box penetration testing actually mean in practice, and how to pick.

Black box penetration testing

In a black box penetration test, the tester starts with what an outside attacker has: essentially nothing. No credentials, no architecture diagrams, no source code — often just a company name or an IP range. The tester has to discover the attack surface the same way a real adversary would: reconnaissance, enumeration, and probing.

What it’s good at. Realism. A black box test answers the question “what could an opportunistic attacker actually do to us from the internet?” It exercises your external visibility: what’s exposed, what’s discoverable, what’s misconfigured in plain sight. It also tests your detection — a black box tester generating recon noise should light up a well-tuned monitoring stack.

What it misses. Depth per dollar. Because the tester spends a large share of the engagement on discovery, less time goes to actually exploiting what’s found. Authenticated attack surface — everything behind a login — is mostly out of reach. A vulnerability that takes insider knowledge to find stays hidden, even though a patient real-world attacker (or a malicious insider) would eventually reach it.

When to choose it. First-ever assessments of your perimeter, testing detection and response, red-team-style objectives, and board-level “how exposed are we, really?” questions.

White box penetration testing

In a white box penetration test (also called crystal box or clear box), the tester gets everything: credentials at multiple privilege levels, architecture documentation, and often source code. Nothing is hidden.

What it’s good at. Coverage and depth. With discovery time near zero, the entire engagement goes into finding and validating vulnerabilities. Business logic flaws, authorization gaps between user roles, subtle injection points several layers deep, insecure defaults in the deployment — the classes of bugs that cause real breaches are far more reliably found white box. If the test exists to make the application safer (rather than to simulate an adversary), white box finds the most issues per day of testing.

What it misses. The attacker’s-eye view. A white box test won’t tell you how discoverable your weaknesses are, and it doesn’t test your monitoring. It can also surface findings a real attacker would be unlikely to reach, which need honest severity ratings so they don’t distort remediation priorities.

When to choose it. Pre-launch application testing, critical systems where a miss is unacceptable, compliance-driven application tests (SOC 2, PCI DSS), and secure development programs pairing testing with source code review.

Grey box penetration testing

Grey box penetration testing sits deliberately in between: the tester gets partial knowledge — typically a standard user account and a scope briefing, but not source code or admin credentials. It models the most common real-world threat: an attacker who has phished one employee’s credentials, or a malicious customer with a legitimate account.

What it’s good at. The best cost-to-coverage ratio for most organizations. Authentication and authorization flaws — can user A read user B’s data, can a basic account reach admin functions — are exactly the bugs that cause most real application breaches, and grey box testing targets them directly while retaining a realistic attacker perspective.

What it misses. The extremes. It has less discovery realism than black box and less total coverage than white box. For most engagements, that’s an acceptable trade — which is why grey box is the default method for the majority of professional penetration tests, including most of ours.

Side-by-side comparison

	Black box	Grey box	White box
Tester knowledge	None	Partial (user accounts, scope)	Full (credentials, docs, code)
Realism	Highest	High	Lower
Coverage per day	Lowest	High	Highest
Finds authenticated flaws	Rarely	Yes — its specialty	Yes, most thoroughly
Tests your detection	Yes	Partially	No
Typical use	Perimeter, red team	Most application and network tests	Critical apps, pre-launch, compliance

How the choice affects cost

Method changes where time goes, not just how much of it there is. A black box engagement spends budget on discovery; a white box engagement spends it on depth. For a fixed budget, expect a white or grey box test to produce meaningfully more findings — which is why “we want the most security value per dollar” almost always points to grey box, while “we want to know what an attacker sees” points black box. Our pricing is fixed-scope either way, so the method conversation is about goals, not billable hours.

How to choose in one minute

1. “What can an outsider do to us?” → Black box, external scope.
2. “Is this application safe for our customers?” → Grey box (or white box if it’s business-critical).
3. “We need maximum coverage before launch / for an audit.” → White box.
4. “Would we notice an attack in progress?” → Black box with a detection objective, or a full red team engagement.

Most real programs mix methods over time: grey box application testing annually, black box external testing to keep the perimeter honest, white box for the crown jewels. The method should follow the question you need answered — not the other way around.

Not sure which fits your situation? Scope your assessment and we’ll recommend the right method with a fixed-scope proposal, or read our overview of the types of penetration testing first.