What is black box penetration testing?

Black box penetration testing is a test in which the tester receives no information or credentials beyond a target name, domain or IP range and must discover everything else as an anonymous attacker would. It is the most realistic simulation of an opportunistic outsider and the least thorough for anything behind authentication, because a tester with a fixed time budget cannot reach what a real attacker might reach given months.

What is grey box penetration testing?

Grey box penetration testing gives the tester partial knowledge: working credentials for each user role, an architecture overview and documentation, but not the source code. It simulates an authenticated user, an insider or an attacker who has already compromised one account, and finds the most vulnerabilities per testing day for most applications and networks. It is the default knowledge level for compliance-driven testing.

What is white box penetration testing, and is crystal box the same thing?

White box penetration testing gives the tester full knowledge: credentials, documentation, source code, configuration and infrastructure-as-code, and combines code review with dynamic testing. Crystal box, glass box and clear box are synonyms for white box. It finds the deepest defects, such as weak cryptography, hard-coded secrets and injection in rarely used code paths, and is the right choice for critical modules and code review obligations.

Which approach is the most realistic?

Black box is the most realistic simulation of an anonymous outsider at the perimeter, and grey box is the most realistic simulation of the attacker behind most breaches: someone with a valid account obtained through phishing or leaked credentials. Realism should not be confused with thoroughness. A real attacker has unlimited time and a tester does not, so giving the tester information compensates for the time budget.

Which approach finds the most vulnerabilities?

Grey box finds the most per testing day for the majority of web applications, APIs, mobile apps and internal networks, because the budget goes to testing rather than discovery and because authorisation and business-logic flaws are only reachable with accounts. White box finds the most in absolute terms when the scope includes source code, at the cost of reading time.

Does the knowledge level change the duration or cost of a penetration test?

It changes how the days are spent more than how many days there are. Black box rarely saves days; it spends them on reconnaissance and returns fewer findings. White box adds preparation on the client side and reading time on the tester side. HackersHub quotes every test on a written scope that states the knowledge level, the day count and the material to be provided.

Which knowledge level do auditors and regulators accept?

All three, provided the scope, methodology and tester qualifications are documented. ISO 27001, SOC 2 and NIS2 do not prescribe a knowledge level, but auditors expect application and internal tests to be authenticated, which means grey box. PCI DSS Requirement 11.4 accepts any industry-accepted methodology, while Requirement 6.2.3 and DORA Article 25 add code review, which implies white box access for the code in question.

Can we combine black box, grey box and white box in one engagement?

Yes, and it is often the best scoping. A staged test starts with one or two unauthenticated days, continues with credentials per role, and adds targeted code access for the modules where a root cause needs confirming. The report labels each finding with the knowledge level at which it was found.

1 November 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)

Black box, grey box or white box penetration testing: what each one finds, what it misses, and which one to choose

The knowledge level you give a tester is the single scoping decision that most changes what a penetration test finds per day. This guide defines the three levels, puts the same web application through all three, and explains why grey box is our default and when it should not be.

Scope a penetration test

Three knowledge levels, one question: what does the tester know on day one?

Black box, grey box and white box describe how much information and access the organisation gives the penetration tester before testing starts. Nothing else changes: the target, the methodology (PTES, OWASP WSTG, NIST SP 800-115) and the reporting are the same. What changes is where the tester's days go. In a black box test the tester starts with a company name, a domain or an IP range and has to discover everything else, exactly as an anonymous attacker would. In a grey box test the tester receives working credentials for each user role, an architecture overview and whatever documentation exists, and spends the days on testing rather than on discovery. In a white box test the tester also receives source code, infrastructure configuration and design documents, and can read how a control is implemented instead of inferring it from the outside.

The terms come from software testing, where a black box is a system you can only observe through its inputs and outputs and a white box is one whose internals you can inspect. You will also see white box called crystal box, glass box or clear box; those are synonyms, although some vendors use crystal box to signal a fully collaborative test in which developers sit with the tester. Grey box is also written gray box or greybox. OWASP's Web Security Testing Guide notes that a pure black box approach limits what a web application test can cover and recommends giving testers accounts and documentation; that recommendation is the reason grey box has become the default for application testing.

The knowledge level is independent of the two other scoping axes, position (external, internal, assumed breach) and target (network, web application, API, mobile, cloud). An external black box perimeter test and an internal grey box Active Directory test are both common; so is a white box review of a payment module inside an otherwise grey box application test. For the full taxonomy see our guide to all types of penetration testing; this article stays on the knowledge axis.

The three levels at a glance

What the tester receives, whom the test simulates, and what it can and cannot reach.

Black box: zero knowledge

The tester receives a target name, domain or IP range and nothing else. Reconnaissance, enumeration and discovery are part of the test. Simulates an opportunistic external attacker with a fixed time budget. Finds what is exposed and exploitable without credentials; sees nothing behind authentication unless it breaks in.

Grey box: partial knowledge

The tester receives credentials for each role, an architecture overview, API documentation and a contact who can answer questions. Simulates a customer, partner, employee, or an attacker who has already phished one account. Finds authorisation flaws, business-logic abuse and privilege escalation that black box never reaches.

White box: full knowledge

The tester receives everything grey box provides plus source code, infrastructure-as-code, configuration and design documents, and combines dynamic testing with code review. Finds the deepest classes of defect: weak cryptography, hard-coded secrets, injection in rarely used paths, logic errors that only show in code. Also called crystal box, glass box or clear box.

Black box vs grey box vs white box: side by side

The criteria buyers ask about during scoping, answered per knowledge level.

Criterion	Black box	Grey box	White box
Information given	Target name, domain or IP range	Credentials per role, architecture overview, documentation, a contact	Grey box plus source code, configuration, infrastructure-as-code, design documents
Attacker simulated	Anonymous outsider with a time limit	Authenticated user, insider, or attacker after a successful phish	Insider with code access, or a long-term adversary who has studied the system
Realism	Highest for the external perimeter; lowest for anything behind login	High for the threats behind most breaches: account misuse, authorisation flaws	Lowest as an attack simulation, highest as an assurance exercise
Coverage per testing day	Lowest: the first days go to discovery	Highest for most applications and networks	High, but preparation and reading time compete with testing time
Missed issues (false negatives)	Many: everything behind authentication and anything discovery did not surface	Few at the application layer; defects visible only in code remain	Fewest; limited to production-only configuration and runtime behaviour
Preparation on your side	Minimal: a target list and a letter of authorisation	Test accounts per role, test data, allowlisting, a point of contact	Grey box plus read-only repository access, build instructions, an NDA covering source code
Compliance fit	Accepted as perimeter evidence (ISO 27001 A.8.8, PCI DSS 11.4.3 external)	What most auditors expect for application and internal tests (ISO 27001 A.8.29, PCI DSS 11.4.2, DORA Art. 25)	Required where code review is mandated (PCI DSS 6.2.3, DORA Art. 25 source code reviews, higher OWASP ASVS levels)

One web application, tested three ways

A claims portal for an insurer: customers file claims, brokers manage their customers' claims, administrators approve payouts. A REST API serves the web frontend and a mobile app, and a nightly job exports approved claims to the finance system. Five testing days per approach. Here is what each approach would realistically find and miss.

Black box: the perimeter and the login page

Days one and two go to discovery: enumerating subdomains, identifying the technology stack, mapping every unauthenticated page and API endpoint. Days three to five test what is reachable without an account: the login and password-reset flows, rate limiting, session handling, TLS configuration, exposed administrative paths, verbose error messages and outdated JavaScript libraries. Likely findings: user enumeration through the password-reset response, missing rate limiting on login, a staging host left reachable from the internet, two libraries with published CVEs. Missed entirely: every authorisation flaw between customers and brokers, the privilege escalation to administrator, the mass-assignment issue on the profile endpoint, the server-side request forgery in the webhook feature and the stored cross-site scripting in claim notes, because none of them is reachable without a valid account.

Grey box: every role, every workflow

With one account per role, the architecture diagram and the API documentation, day one is spent mapping the application per role and reading how the API authorises requests. Days two to five test each workflow as each role, swap identifiers between accounts, tamper with request parameters and chain what is found. Likely findings: customers can read other customers' claims by changing a sequential identifier (broken object level authorisation), brokers can list customers of other brokers through an unvalidated filter parameter, a customer can set their own account to verified through mass assignment, the webhook URL field accepts internal addresses and reaches the cloud metadata service, and claim notes render unescaped in the administrator view. Missed: a predictable seed in the password-reset token generator, string concatenation in a rarely used reporting query, a hard-coded API key for the document-signing provider, and a race condition in the two-step payout approval.

White box: the code shows what the runtime hides

With read-only access to the repositories and the infrastructure-as-code, the tester reads the authentication, authorisation and payment modules first and uses the running application to confirm what the code suggests. Likely findings: everything grey box found, plus the predictable reset token (visible within minutes in the token generator), the SQL concatenation in the reporting module, the hard-coded signing key, a full dependency analysis, the missing authorisation check on the export route hidden behind a feature flag, and an overly permissive IAM role in the deployment templates. Missed or weaker: production-only behaviour such as the web application firewall rule that actually blocks a payload the code would accept, a load balancer header that bypasses IP allowlisting, and, as a simulation, any sense of how long a real attacker would need to find all this from outside. White box also costs reading time: of five days, roughly two go to code before the first dynamic test.

When to choose black box, grey box or white box

Choose by the question you need answered, not by which approach sounds most rigorous.

Choose black box when the outsider's view is the question

A first look at an acquisition target's perimeter when you cannot yet request credentials. Confirming that an internet-facing system exposes nothing without authentication. A staged first phase of one or two days before credentials are handed over. Black box is not a choice for compliance evidence on application security, and it is not a way to save days: a black box test of an authenticated system usually takes as long as a grey box test and finds less.

Choose grey box when you need the most findings per day

Annual compliance testing for ISO 27001, NIS2, DORA Article 25 and PCI DSS Requirement 11.4. Any application with user roles or multi-tenancy. Internal network tests as assumed breach from a standard user account. Mobile apps and APIs, which are almost entirely authenticated surface. A first test of any system that holds customer data. This is the default we scope, for the reasons set out below.

Choose white box when the defects you fear live in the code

Payment, cryptographic and authentication modules. Software you sell to customers who will test it themselves. Code review obligations under PCI DSS Requirement 6.2.3 or DORA Article 25. Pre-release testing of a new platform, where fixing is least disruptive. High-assurance systems such as medical devices, industrial controllers and identity providers. Combine it with dynamic testing: code review on its own misses deployment and runtime issues.

Time, depth and budget: the trade-off in words

Every penetration test is a fixed number of consultant days. The knowledge level decides how those days are spent. In black box, the first part of the budget pays for reconnaissance that you could have handed over for free. In grey box, that budget moves into testing, which is why grey box finds more per day and why its findings cluster in the categories that cause real breaches: broken access control, which has headed the OWASP Top 10 since 2021, and business-logic abuse. In white box, part of the budget moves into reading code, which finds the deepest defects but delays the first dynamic finding and requires testers who are at home in your language and framework.

Realism and thoroughness are different goals. A real attacker is not limited to five days; a tester is. Giving the tester the information an attacker would eventually obtain is how you simulate the attacker's eventual position within the time you are paying for. White box asks more preparation of you (repository access, NDAs, build instructions) and more reading time of us, and returns the most complete picture; whether that is worth it depends on how critical the code is and whether a code review obligation applies.

A staged approach captures most of the benefit of each level: one or two days black box to record the unauthenticated view and the discovery results, then credentials for the remaining days, with targeted code access for the modules where the grey box phase found something that needs a root cause. The report then states, per finding, at which knowledge level it was found. That tells you which findings an anonymous attacker could reach today and which require an account or an insider position.

What to have ready for a grey box or white box test

The preparation that turns handed-over knowledge into testing days.

One test account per user role, including the highest-privilege role, and at least two accounts per role so horizontal authorisation can be tested
Representative test data, or a staging environment that mirrors production configuration; if production is tested, agreed exclusions and a rollback contact
An architecture overview: components, trust boundaries, third-party integrations, authentication provider
API documentation (OpenAPI, GraphQL schema or a request collection) and the mobile builds if in scope
Allowlisting of the tester's source addresses in the web application firewall and rate limiter, or an explicit decision to test with them active
A named technical contact who can answer questions within the day and unlock accounts
For white box: read-only repository access, build and deployment instructions, infrastructure-as-code, and an NDA that covers source code
A letter of authorisation that names the targets, the window, the knowledge level and the escalation path for critical findings

How HackersHub scopes the knowledge level: grey box by default

We scope grey box as the default for application, API, mobile, cloud and internal network tests because it yields the most findings per consultant day, mirrors the attacker position behind most breaches (a valid account obtained through phishing or credential stuffing), and produces the per-role evidence auditors ask for under ISO 27001 A.8.29, PCI DSS Requirement 11.4 and DORA Article 25. Every grey box engagement begins with a short unauthenticated phase, so the report also records what an anonymous outsider sees.

We recommend black box as a standalone level for external perimeter tests, for pre-acquisition reconnaissance where credentials cannot yet be requested, and when a client specifically wants to measure the outsider's view. We recommend white box, as a combined code review and dynamic test, for payment, cryptographic and authentication code, for software before its first release, and wherever a code review obligation applies. In every case the scope statement names the knowledge level, the accounts and material to be provided, and the methodology followed (PTES, OWASP WSTG and MASTG, NIST SP 800-115).

Reports contain an executive summary, CVSS-scored findings with evidence, an attack narrative that shows how findings chain, and prioritised remediation. A verification retest of medium and higher findings within 90 days is included. Every tester holds at least OSCP; OSWE-certified testers lead white box engagements, because reading code for vulnerabilities is a different skill from exploiting a running system. Lead tester Michael van Mameren reviews every scope. HackersHub has delivered offensive security from Amsterdam for more than ten years and is rated 4.9/5 across 127 reviews.

Frequently asked questions

Related guides and services

Not sure which knowledge level fits your system?

A 20-minute scoping call settles black, grey or white box per target, lists the accounts and material we need, and gives you a written scope with the day count and the named lead tester. Talk to an expert.

Scope a penetration test Talk to an expert