By EJN Labs · 26 Sep 2025 · 3 min
Grey-box penetration testing (also spelt gray-box) is an engagement model in which the tester is given partial information about the target before testing begins. The information typically includes user credentials at different privilege levels, network diagrams, application architecture documents, or limited source code access. Grey-box sits between black-box, where the tester receives no internal information, and white-box, where the tester has full access to documentation and code.
What gets shared
Credentials, architecture diagrams, API documentation, descriptions of custom authentication or authorisation logic, and access to staging environments are the assets typically shared in a grey-box engagement. Low and standard-user accounts are provided so authentication can be tested without the tester spending time on enumeration.
Architecture diagrams stay high level and focus on trust boundaries, while staging or test environment access matters because destructive testing is safe there. Source code is sometimes shared selectively for high-risk components.
When grey-box is the right choice
Choose grey-box for web and mobile application testing whenever tester time is limited and depth matters. It is the most common engagement model for these assessments because it lets the tester spend that limited time on authorisation, business-logic flaws and multi-step exploitation rather than on reconnaissance and account creation.
Grey-box also produces more reliable coverage than black-box, since the tester can exercise every user role rather than only the accounts they happen to discover.
Comparison with other models
Black-box simulates an external attacker with no insider knowledge. It is realistic but inefficient: a significant portion of the engagement is consumed by reconnaissance that an experienced tester could skip given context. Black-box is appropriate when the client wants to model a specific attacker scenario or measure the effectiveness of perimeter detection.
White-box gives full access to source code, design documents, and administrator credentials. It produces the deepest review per hour because the tester can read the code that implements a function instead of inferring behaviour from outputs. It is the right choice for new-build assurance and for high-risk components, but is more expensive because of the broader scope.
Related terms
See also: white-box penetration testing, penetration testing, and penetration tester.




Leave a Reply