Black Box vs Grey Box vs White Box Penetration Testing

White box penetration testing gives the tester full knowledge of the target, black box penetration testing gives them none, and grey box sits in between. The choice decides where the tester’s time goes: with no information, days go on reconnaissance; with full information, they go on finding and proving flaws. For most web applications, APIs and internal networks, grey or white box gives the most assurance for the budget. Black box is worth choosing when the question is specifically what an outsider can find and do without help.

This page compares tests by how much the tester is told. To compare them by what is tested (networks, web applications, cloud, mobile and so on), see the types of penetration testing.

What is black box penetration testing?

A black box penetration test starts with no inside knowledge. The tester receives a company name, a web address or an IP range, plus written authorisation and the rules of engagement, and nothing else: no credentials, no diagrams, no documentation. It is also called closed box or zero-knowledge testing.

The tester works like an outside attacker: mapping what is publicly visible, identifying the software and services in use and trying to exploit anything reachable without an account.

What black box does well:

• Shows what your public footprint gives away, including forgotten subdomains, old test sites and exposed admin pages.
• Tests the unauthenticated attack surface exactly as an outsider sees it.
• Gives an unbiased view, because the tester has no assumptions from your documentation.

Where it falls short:

• An attacker can spend months on reconnaissance; a tester has days, and every day spent rediscovering your systems is a day not spent testing them.
• Anything behind a login stays out of reach unless the tester can register an account or break in first.
• A clean black box report does not mean a system is secure. It means nothing was found from that starting point in the time available.

What is grey box penetration testing?

A grey box penetration test (gray box in US spelling) gives the tester partial knowledge. For an application, that usually means test accounts for each user role and API documentation, such as an OpenAPI specification. For an internal network, it usually means a standard domain user account and a laptop built like your staff devices. Because credentials are the most common thing the tester is given, grey box work is often described as authenticated testing.

Grey box models the attackers most organisations actually face: a customer who wants to see other customers’ data, a phished employee whose account is now in someone else’s hands, or a compromised supplier login. Many of the most serious application flaws, such as broken access control and business logic abuse, only appear after login, which is why grey box is the usual default for application and internal network testing.

What is white box penetration testing?

A white box penetration test gives the tester full knowledge: architecture diagrams, configuration files, accounts for every role including administrators, access to developers and usually the source code. It is also called clear box, glass box or crystal box testing.

With the code and design in hand, the tester can go straight to the riskiest areas, such as authentication, session handling, payment logic and cryptography, and trace a suspicious behaviour back to the line of code that causes it. That makes white box the most thorough option per day of testing, and it suits high-risk systems where you need confidence rather than a sample.

The trade-offs are preparation and scope. You need to share code and documentation securely, and a large codebase needs a clear focus or the review will run long. White box testing combines naturally with a secure source code review. In tool terms, static analysis (SAST) is the automated white box approach and dynamic scanning (DAST) the automated black box one; neither replaces a skilled tester.

How is a white box penetration test carried out?

A white box penetration test combines a review of the design and code with hands-on testing of the running system, so every suspected flaw found in the code is confirmed in practice. It usually runs in six stages:

Agree in advance how code and credentials will be transferred, stored and deleted, because they are among the most sensitive things you will share with a supplier. A threat modelling exercise before the test helps a large codebase keep its focus on the functions that matter most.

How do black, grey and white box testing compare?

Which is better, white box or black box testing?

Neither is better in every case, because they answer different questions. If the question is “how secure is this system?”, white box gives the most complete answer for the money. If the question is “what can a stranger on the internet find and do without help?”, only black box answers it directly.

The NCSC’s penetration testing guidance treats a penetration test as a way of gaining assurance in your vulnerability management, not as the main way of finding vulnerabilities. Assurance comes from coverage, and coverage comes from knowledge, so giving the tester information is not cheating. It lets a few days of testing reach what an attacker with months to spare would eventually find.

Choose black box when:

• You want to test what your public footprint reveals before an attacker looks.
• You run a third-party product and have no code or documentation for it.
• A customer, contract or threat scenario asks specifically for an unaided external view.

Choose white box when:

• The system handles payments, personal data or authentication for other systems.
• You are about to launch or have made major changes, and need depth rather than a sample.
• Previous grey box tests have come back clean and you want to know what they could not reach.

If the goal is to test whether your team can detect and respond to a real attack, you need a red team exercise rather than a black box pen test; see red teaming vs penetration testing for the differences.

Which approach suits web applications, internal networks and PCI DSS?

For web application penetration testing, credentials for each role let the tester check whether one customer can read another’s records, which is invisible from outside. For internal penetration testing, a short unauthenticated phase shows what a rogue device could do, then a standard user account shows how far a successful phishing email could take an attacker.

PCI DSS v4.0.1 does not require black, grey or white box testing by name, but its methodology requirement makes the choice for you. Requirement 11.4.1, in the standard available from the PCI SSC document library, expects testing of the entire cardholder data environment perimeter and critical systems, from inside and outside the network, application-layer testing for at least the vulnerabilities listed in Requirement 6.2.4, and testing to validate segmentation and scope-reduction controls. A tester cannot prove segmentation without knowing which networks are meant to be out of scope. Our PCI DSS penetration testing is scoped with that information from the start.

What does each approach find in practice?

Take one online shop tested three ways. The findings below are illustrative, not client data.

• Black box: with only the shop’s domain, the tester searches certificate transparency logs, finds a forgotten staging subdomain running an older version of the site and logs in to its admin page with a default password.
• Grey box: with two customer accounts, the tester changes an order number in a request and sees the other customer’s name, address and order history, a classic insecure direct object reference that no scanner would flag.
• White box: reading the password reset code, the tester sees that reset tokens are generated from a predictable value and shows that an attacker could take over any account.

Each approach found something the others might have missed. That is why many tests are staged: a short black box phase to see what is exposed, a grey box phase for depth, and a targeted code review of the riskiest functions.

How does the choice affect cost?

The price of a penetration test follows the number of tester-days, and the box type changes what those days achieve. Black box testing spends paid days on discovery you could hand over in an email. White box adds time to read code and design, but finds more per day. Grey box usually gives the best balance. Our penetration testing cost guide explains the other drivers, from the number of user roles to retesting.

Why Sovereign Secure

• A PCI SSC Qualified Security Assessor company, also approved as a Qualified PIN Assessor and Card Production Security Assessor, and a member of the PCI SSC Global Executive Assessor Roundtable for 2026 to 2028, so PCI tests are scoped to the evidence an assessor expects.
• Black, grey and white box testing of web applications, APIs, networks, cloud, mobile, hardware and IoT, wireless and AI and LLM applications, plus source code review, social engineering and red teaming.
• ISO 27001 certified, so the code, credentials and documentation you share are handled under a certified information security management system.

Next step

Tell us what you want to test and what you want to learn from it, and we will recommend black, grey or white box (or a staged mix) and send a fixed-price proposal. Use the penetration testing quote form or call +44 161 523 5276.