Black Box vs Grey Box vs White Box Pentest: Which to Choose?

Black box, grey box and white box are the three pentest approaches, defined by how much access and knowledge the researcher gets about the system before the work starts. Black box starts from zero (like a real external attacker); grey box comes with credentials and basic documentation; white box comes with full access (code, database, infrastructure).

The choice between them directly affects coverage, technical depth, execution time and price. This guide explains each approach in depth, compares them dimension by dimension, and shows exactly when to choose each one — with specific recommendations by company size and industry (B2B SaaS, fintech, e-commerce, healthtech).

Executive summary — a quick comparison

Black box pentesting

What it is

In a black box pentest, the researcher gets absolutely nothing. They start from zero, the way a real external attacker would: with just a domain name, an IP address or a public URL. No credentials, no documentation, no infrastructure access, no code.

How it works in practice

• The researcher runs full recon: subdomain discovery, mapping of public endpoints, analysis of exposed JavaScript bundles, technology fingerprinting, OSINT
• Tries to create an account as a regular user (if the application allows public sign-up)
• Attacks only what's publicly exposed
• Looks for exposed misconfigurations (public S3 buckets, permissive CORS, missing headers, forgotten v1/v2/staging endpoints)

What black box finds well

• Externally reachable vulnerabilities
• Exposed infrastructure misconfigurations
• Flaws in authentication, sign-up and password recovery
• Pre-authentication attacks (SSRF on public endpoints, NoSQL injection on login)
• Information leakage in responses (stack traces, debug headers)

What black box does NOT find well

• Internal application bugs (deep post-login)
• Business logic in private areas
• Flaws in admin workflows
• Bugs in internal APIs that weren't discovered during recon
• Cross-tenant BOLA (requires 2+ accounts in different tenants)
• Internal race conditions

When to choose black box

• A faithful simulation of an external attacker — when the client wants to see exactly “how an attacker sees us from the outside”
• A first pentest with a new vendor — there's no trust yet, and black box makes it clear what the vendor can uncover on its own
• Attack surface validation — checking what has been exposed by accident
• Compliance with a specific requirement — some regulatory frameworks require “unassisted” testing

Grey box pentesting ⭐ The most common approach

What it is

In a grey box pentest, the researcher gets valid credentials for different roles (for example: 1 admin, 1 regular user, 1 viewer) and basic system documentation — usually the API's Swagger/Postman collection, a list of the main URLs and high-level diagrams. No access to the source code.

How it works in practice

• The researcher is logged in to multiple accounts in parallel
• Maps post-authentication flows quickly (no time lost on recon)
• Tests cross-tenant access — customer A accessing customer B's data — which is only possible with 2+ accounts
• Tests privilege escalation — a viewer turning into an admin
• Covers the full OWASP API Top 10
• Assesses business logic abuse in legitimate flows (price manipulation, coupon race conditions, anti-fraud bypass)

What grey box finds very well

• Cross-tenant BOLA (data leaking between customers) — #1 on the OWASP API Top 10 and the most devastating bug in B2B SaaS
• BFLA (accessing admin endpoints as a regular user)
• BOPLA / mass assignment (changing private fields via PATCH)
• Business logic abuse (price manipulation, coupon race conditions, double refunds)
• OAuth ATO in post-login flows (state confusion, scope escalation — see OAuth account takeover in B2B SaaS)
• Race conditions in financial endpoints (see Race conditions in Pix, Brazil's instant payment system)

What grey box does NOT find as well

• Bugs in deep layers of the code (internal race conditions in queries)
• Internal infrastructure misconfigurations (permissive IAM, network policies)
• Secrets hardcoded in the code or in Git history
• Vulnerabilities in dependencies (specific CVEs in libraries)
• Architectural design flaws

When to choose grey box

• The default for most B2B SaaS and modern fintech pentests — the best value for money
• Annual pentest renewal — the standard approach for regular coverage
• Sprint-aligned pentesting (PTaaS) — in recurring models, grey box is the standard
• SOC 2 / ISO 27001 readiness — satisfies the auditor without inflating the cost
• When time is limited — skips recon and goes straight to where the payoff is

White box pentesting

What it is

In a white box pentest, the researcher gets FULL access to the system: everything from grey box plus the complete source code (Git repository), database access (schema + data), infrastructure access (AWS console, Kubernetes, logs), complete architecture documentation and time with the engineering team (collaborative threat modeling).

How it works in practice

• The researcher combines code analysis (static) with active exploitation (dynamic)
• Maps critical flows through the code before attacking
• Identifies vulnerabilities that are “invisible” from the outside (race conditions in internal queries, dead code that turns into a backdoor, secrets in old commits)
• Performs an architecture review and identifies design problems (not just implementation issues)
• Can run static analysis tools (SAST) and manually validate the findings
• Analyzes cloud misconfigurations in depth (IAM, S3 policies, network ACLs)

What white box finds exceptionally well

• Complex race conditions
• Deserialization vulnerabilities
• SQL injection in internal queries
• Secrets leaked in code or Git history (API keys, hardcoded credentials, OAuth tokens)
• Vulnerabilities in dependencies (specific CVEs)
• Design flaws (not just implementation flaws)
• Accidental backdoors left behind by developers
• Deep cloud misconfigurations (permissive IAM, bucket policies)
• Verification of cryptographic properties (key management, rotation)

Where white box doesn't make sense

• Recon (it already has all the information)
• Simulating a “blind external attacker” (that misses the point — use black box for that)

When to choose white box

• Before launching a critical feature — a financial product, a payment flow, a regulated integration
• SOC 2 Type II or ISO 27001 readiness — the auditor asks for white box to validate technical controls
• An in-depth initial assessment at a company that has never had a serious pentest
• Technical due diligence in M&A
• Pre-architecture threat modeling of a critical system before go-live
• Regulated industries (fintechs supervised by Brazil's Central Bank (BACEN), healthtech under Art. 11 of the LGPD, Brazil's data protection law) — in-depth auditing

Detailed comparison — dimension by dimension

How the market actually uses them in 2026

Typical split of approaches across Brazilian pentests in 2026:

• ~60% grey box — the best ROI for the typical client (B2B SaaS, early-stage fintech, e-commerce, marketplaces)
• ~25% black box — when the client wants a faithful simulation, or it's their first pentest and they don't trust the vendor yet
• ~15% white box — when there's heavy regulation (BACEN Resolution 4,893, PCI DSS 4.0, SOC 2 Type II) or the client is already mature in security

Decision tree — which one fits your situation

For B2B SaaS

Grey box is the default. Full coverage of multi-tenancy, OAuth, BOLA and business logic without inflating the cost. See SaaS penetration testing.

For early-stage fintech

Grey box for the annual pentest + a white box module on critical financial flows (Pix, reconciliation, anti-fraud). As the company matures, move to a full white box. See Fintech penetration testing.

For digital banks / enterprise fintech

White box is mandatory in any formal engagement. The Brazilian Central Bank's rules — BACEN Resolution 4,893 and BCB Resolution 85 — expect that depth. See Payments penetration testing.

For e-commerce / marketplaces

Grey box by default. Black box is useful for validating the external exposure of a new feature. See E-commerce penetration testing and Marketplace penetration testing.

For healthtech / digital clinics

Grey box + a white box module on medical record and prescription flows (LGPD Art. 11 — sensitive data). See Healthtech penetration testing.

For SOC 2 Type II or ISO 27001 readiness

White box is recommended. Neither standard requires it, but auditors often value the broader coverage it provides.

For early-stage startups (pre-revenue / MVP)

Black box as the first pentest. It validates the external surface on a limited budget. As you grow, move to an annual grey box.

The hybrid model — what every serious fintech is doing

In practice, a mature fintech in 2026 doesn't pick a single approach. It combines:

• 1 annual white box — a complete, in-depth review with maximum coverage that feeds the regulatory dossier
• 2–4 quarterly grey box pentests — agile coverage of new features
• Sprint-aligned pentesting (PTaaS) with grey box — recurring monthly; every feature goes through adversarial validation before it reaches production
• One-off black box when an externally exposed feature launches (a new public SDK, a new third-party integration)

What to consider when deciding

1. Current security maturity

No previous pentest at all = start with grey box or white box to get a real baseline. Black box in an immature organization underestimates exposure.

2. Applicable regulation

Regulated industries (BACEN, PCI DSS, SOC 2, ISO 27001) expect progressively more depth. White box unlocks certifications.

3. Release frequency

A product team that deploys weekly needs recurring, sprint-aligned grey box. A once-a-year pentest becomes obsolete within weeks.

4. Available budget

Black box is cheaper and white box more expensive (for the same total hours). Grey box is usually the sweet spot for value for money.

5. Internal availability

White box requires access to the code and infrastructure — if the team is restrictive about that, grey box may be the only viable path.

Frequently asked questions

Is black box always cheaper?

Per hour, yes. But the total number of hours can be higher, because a significant amount of time goes into recon. On a small project (up to 50 endpoints), grey box usually costs about the same as black box, with twice the coverage.

Is white box worth the extra investment?

For an immature SaaS or a critical pre-launch — yes. Bugs that only show up in the code (internal race conditions, hardcoded secrets, vulnerable dependencies) can cost millions in a later breach. For a mature SaaS that already runs recurring grey box pentests, the coverage delta is harder to justify.

Does grey box satisfy SOC 2 and ISO 27001?

Yes, with a caveat. Auditors accept grey box in a regular cycle if there's a complementary annual white box. Grey box alone, with no white box, may be questioned in a rigorous SOC 2 Type II.

Can I start with black box and move up?

Yes — it's common practice with new vendors. A first black box pentest builds trust. The second one moves to grey box. The third to white box, once the relationship is established.

Is black box more “realistic” than grey box?

For simulating an external attacker WITHOUT credentials, yes. But most successful real-world attacks start from compromised credentials (phishing, leaks, insiders). Grey box simulates that post-credential-compromise reality — which matters more in practice.

How long does each approach take?

On a comparable project: black box ~3 weeks (a lot of time on recon), grey box ~2 weeks (focused on exploitation), white box ~3–4 weeks (more coverage per hour, but the scope naturally grows).

Conclusion — how to choose today

In 99% of cases, grey box is the right answer for B2B SaaS, early-stage fintech, e-commerce, marketplaces and healthtech. It combines broad coverage (60–75%), moderate cost and speed of execution.

Use black box when you need to simulate pure external exposure or it's your first engagement with a new vendor. Use white box when you need maximum depth — heavy compliance preparation, a critical pre-launch, technical due diligence, or a regulated industry.

And above all: combine approaches over time. A serious company in 2026 doesn't stick to a single model. Annual grey box + semiannual white box for critical areas + one-off black box when you launch an externally exposed feature = a mature security posture.

To talk through which approach makes the most sense for your situation, see No Vuln's offering or the guide to pentest pricing in Brazil by company size. To compare No Vuln with other Brazilian pentest companies, see our comparison of 10 companies.