Grey Box Pentest Guide 2026: Why It's the Default Choice

Grey box pentesting is the approach in which the security researcher gets credentials and basic documentation about the system before starting. Typically: two test accounts in different tenants (essential for cross-tenant testing), a high-level architecture description, API documentation (Swagger/OpenAPI/GraphQL schema, if available), and a list of the product's critical flows.

It's the balance point among the three approaches — neither the time lost on recon that characterizes black box, nor the code review and environment setup overhead of white box. That's why it accounts for ~60% of the market in a typical split and is the default choice for most serious pentests of B2B SaaS and fintech.

This guide explains in depth what grey box is in 2026, how it works in practice, when to hire it, when NOT to, and how it compares with black box and white box.

What is a grey box pentest? A one-line definition

A grey box pentest is a controlled simulation of an attack by someone who has some legitimate level of access to the system — a regular customer, a former employee whose credentials still work, or an external attacker who obtained leaked or purchased credentials. The researcher gets test accounts and scope documentation, and from there simulates what that attacker profile can do with the privileges it has.

Because grey box starts inside the authenticated perimeter, it covers exactly what black box can't see: everything behind the login. In a typical B2B SaaS, that's 80–90% of the technical complexity and of the real risk surface — because most of the expensive bugs (cross-tenant BOLA, BFLA, race conditions in transactions, broken business logic) only show up with multiple authenticated accounts testing in parallel.

Quick comparison: grey box vs black box vs white box

To anchor where grey box fits on the spectrum of the three approaches:

For the black box deep dive, see Black Box Pentest Guide 2026: When to Use It and When Not To. For the full side-by-side view, which also covers white box, see Black Box vs Grey Box vs White Box Pentest: Which to Choose?.

How grey box works in practice — methodology

The big difference from black box is structural: the researcher doesn't spend time discovering what exists — they're handed the map. That frees up almost the entire hour budget for active exploitation. The 4 phases:

Phase 1 — Credentialed setup and mapping (5–10% of the project)

The researcher gets credentials (ideally two accounts in different tenants, plus an admin account in the main tenant for privilege escalation testing), scope documentation, OpenAPI/Swagger and an architecture diagram. They set up the test environment, confirm the credentials work, and map the universe of authenticated endpoints they'll cover.

• Account validation: confirms the scope (roles, permissions, assigned tenants)
• Authenticated API mapping: enumeration via Swagger + discovery of undocumented endpoints through crawling + analysis of the app's traffic
• HTTP traffic recording setup: Burp Suite, Caido or ZAP running as a proxy for systematic capture
• Parallel account setup: cross-tenant testing requires both identities to be logged in simultaneously, in separate sessions

In black box, this phase would take 40–60% of the project. In grey box, 5–10%. The difference isn't wasted — it goes into deeper exploitation.

Phase 2 — Authorization and tenant isolation testing (30–40%)

This is where grey box shines. With two accounts in different tenants, the researcher systematically tests the authorization of every endpoint:

• Cross-tenant BOLA — for every endpoint that takes an ID/UUID, try to access the other tenant's object by swapping the ID. It shows up in ~85% of the Brazilian B2B SaaS platforms we audit
• BFLA (Broken Function Level Authorization) — try calling admin endpoints with a regular user's token, another tenant's endpoints with cross-tenant privileges, and approval flows while skipping steps
• BOPLA (Broken Object Property Level Authorization) — on endpoints that accept partial updates, try to modify sensitive properties (role, plan, tenant_id, is_admin, billing_status)
• Mass assignment — on create/update endpoints, inject extra fields into the body that the client shouldn't be able to edit
• Vertical privilege escalation — a regular user trying to become an admin by manipulating cookies, JWTs or URL parameters, or by abusing profile management flows
• Horizontal privilege escalation — a user in tenant A managing to read/edit specific data in tenant B (resources, files, contracts, settings)

Together, these patterns represent the top 5 items of the OWASP API Security Top 10 in 2026 — and none of them can be detected by an automated scanner. See the breakdown in BOLA, BOPLA and BFLA: The 3 Flaws That Rule APIs in 2026.

Phase 3 — Exploiting internal business logic (35–45%)

With authorization and isolation validated, the focus shifts to business logic — where the most expensive fintech and B2B SaaS bugs live:

• Race conditions in financial endpoints (refunds, withdrawals, transfers, receivables advances, redemptions), single-use coupons, transfer approvals, plan changes, MFA bypass via OTP race
• Multi-step flow manipulation — skipping steps in purchase, sign-up or approval flows; manipulating state to reach final screens without passing the intermediate checks
• Billing abuse — manipulating coupons, discounts and seat counts, downgrading after being charged, double-upgrade races
• Webhooks and callbacks — SSRF on endpoints where the customer configures a webhook URL (the attacker points it at internal metadata, lateral movement)
• JWTs in authenticated use — algorithm confusion, kid path traversal, never-ending sessions because exp is ignored, scope escalation, token reuse across contexts
• Authenticated cache poisoning — flows where a cache shared between tenants or users can be poisoned to serve someone else's data

Phase 4 — Chaining and demonstrating impact (10–20%)

With individual bugs mapped, the researcher chains whatever makes sense to demonstrate maximum impact: BOLA + BFLA together become a full tenant takeover, a refund race + BOPLA on a balance endpoint becomes fund draining, JWT algorithm confusion + scope reuse becomes master admin. This phase is what separates “found a BOLA” from “BOLA + BFLA + balance logic = $X exposed” — context that turns into the right prioritization for the engineering team.

What grey box covers well

1. Authorization between tenants (cross-tenant BOLA)

The classic grey box use case. With two accounts in different tenants running in parallel, the researcher tests every API endpoint systematically by swapping IDs between the accounts. Scanners don't do this (it takes multiple coordinated sessions), black box can't (it covers just one account), and checklist audits miss it (they don't simulate the attack). Grey box is practically the only way to validate this adversarially.

2. Authenticated internal business logic

Every authenticated financial flow — refunds, withdrawals, receivables advances, transfers, billing, coupons — falls under grey box. Even an external researcher testing as a real customer can find race conditions, parameter manipulation and downgrade attacks. White box catches these bugs by reading code, but grey box catches them by running the system the way a real attacker does — including bugs that appear in production but aren't visible in the source (infrastructure, configuration and timing issues).

3. Internal APIs and undocumented endpoints

In a typical B2B SaaS, the documentation covers 60–70% of the endpoints. The rest: internal endpoints for the frontend, forgotten admin endpoints, parallel v1/v2 endpoints, background job endpoints. Grey box discovers these endpoints through traffic analysis (Burp as a proxy for the authenticated frontend) and tests each one. Black box doesn't get there. White box sees them in the code but may not evaluate their runtime behavior.

4. Horizontal and vertical privilege escalation

Testing whether a regular user can become an admin (vertical) and whether a user in tenant A can access tenant B's resources (horizontal) requires running authenticated flows with multiple identities — exactly what grey box sets up. This is where many black box pentests stop at the surface and give the impression of a “clean” result, while grey box reveals the real problems.

5. Credentialed chaining

Internal chains — combining BOLA + BFLA + a race in a financial flow to demonstrate chained impact — come naturally in grey box, because the researcher has the context needed to build the sequence. This is the kind of finding that drives the right prioritization in the engineering team: each link is “medium” on its own, but the full chain is critical.

What grey box does NOT cover

Deep external recon

Forgotten subdomains, exposed staging instances, legacy admin panels at undocumented addresses, leaks on GitHub, public S3 buckets — all of this is black box territory, not grey box. The client provides the scope, and the researcher respects it. If something important is outside the documented scope, grey box won't find it.

Bugs that require reading code

Classic patterns that can only be detected with access to the source: a subtle race condition in a non-obvious part of the code, insecure deserialization in internal parsers, PHP Object Injection, exploitation gadgets in loaded libraries, problematic ORM usage patterns (queries without tenant_id), TOCTOU in approval flows. White box catches all of this. Grey box only catches what manifests as externally observable behavior.

Infrastructure configuration

Excessive IAM permissions, misconfigured S3 buckets (that aren't publicly exposed), container security, internal network segmentation, secrets in environment variables — all of this requires direct access to the infrastructure. Grey box only sees what's behind the authenticated API, not the layer underneath.

Full coverage for formal audits

For SOC 2 Type II, ISO 27001, PCI DSS Level 1 and the requirements of Brazil's Central Bank (BACEN), formal audits usually call for a combination of grey box + white box on critical areas. Grey box alone isn't enough. For this category, schedule both approaches at least once a year.

When to hire a grey box pentest

1. An established B2B SaaS in production

This is the use case par excellence. A B2B SaaS with an active customer base, multiple tenants and rich authenticated flows — grey box is the choice that delivers the most effective coverage per dollar spent. If you're running in production and haven't had a grey box pentest yet, it's the first one to hire.

2. A fintech with internal financial flows

All of a fintech's financial complexity (cards, digital accounts, transfers, receivables advances, redemptions, billing, coupons, vouchers) is authenticated and lives behind the login. Grey box is practically the only way to validate these flows adversarially. For fintech, grey box is close to mandatory before every major release.

3. Multi-tenant authorization auditing

When the specific goal is to validate tenant isolation — before closing a large enterprise contract, before a customer audit, before announcing a multi-organization feature — a grey box focused on BOLA/BFLA is the model. It can be a dedicated 40–60h engagement, cheaper and more direct than a broad grey box.

4. Pre-due diligence and M&A

When a company is being sold or raising a Series A or later, investors require evidence of a serious pentest. Grey box produces a technical report dense enough to satisfy due diligence without having to open up the code (which many companies prefer to avoid before signing a term sheet).

5. After major architectural changes

Migrating from a monolith to microservices, switching the auth stack (moving from sessions to JWT or vice versa), implementing a new RBAC model, changing the tenancy model — any change that alters authorization boundaries calls for a focused grey box. New bugs appear during these transitions.

When NOT to hire a grey box pentest

1. When the goal is to validate the pure external surface

Deep recon, discovery of forgotten subdomains, validation of external exposure — black box is structurally better for that. Grey box starts from the documented scope and doesn't look outside it.

2. When you have the budget for maximum technical depth

If the budget allows, white box delivers 85–95% coverage at a price only ~40% above grey box. For critical areas — the financial transactions module, core auth, the billing API — white box is mathematically more efficient in bugs per dollar spent, as long as you're comfortable sharing code.

3. When you need a heavyweight formal certification

SOC 2 Type II, ISO 27001, PCI DSS Level 1, BACEN requirements for payment institutions — grey box alone usually falls below the evidence threshold the auditor requires. Combine it with white box on critical areas to build the complete evidence package.

How much does a grey box pentest cost in 2026?

For small and mid-size B2B SaaS and fintech companies in the Brazilian market:

• Focused grey box (40–60h): R$ 14,000 – R$ 22,000 — a specific scope (e.g., only cross-tenant BOLA, only the billing flow, only one critical API). Suitable for targeted validations or a post-fix retest.
• Standard grey box (60–80h): R$ 20,000 – R$ 34,000 — the broad scope of a typical B2B SaaS, covering authorization + business logic + financial flows + authenticated APIs, with a technical + executive report. This is the standard engagement for most serious pentests.
• Extended grey box (120h+): R$ 36,000 – R$ 58,000+ — fintechs with complex flows, multi-product SaaS, platforms with multiple roles and layered tenants, or a broad annual grey box covering the entire application.

For price ranges by company size and industry, see How Much Does a Pentest Cost in Brazil? 2026 Price Ranges and Pentest Cost by B2B SaaS Size in 2026.

Combining grey box with black box and white box

The typical combination we see at mature Brazilian B2B SaaS companies:

• Annual: a full white box covering critical modules (core auth, financial, billing)
• Quarterly: a broad grey box focused on authorization + business logic (this is the standard cadence for most companies)
• Monthly or every other month: a light black box on the external surface (to catch surface drift over time)

This cadence reaches ~85% effective coverage over the year at a combined cost significantly lower than 4 quarterly white box pentests. The key point: grey box is the backbone of a continuous pentest program, not a one-off event. White box is the periodic in-depth pass. Black box catches what changes between cycles.

What to do now

1. Measure what percentage of your application sits behind auth. If it's > 60% (typical of B2B SaaS/fintech), grey box delivers more ROI than black box.
2. List the roles and tenants you want covered. The more varied they are, the more value a well-run grey box delivers (multi-tenant + multiple roles = more chains to test).
3. Confirm you have a dedicated staging environment for the pentest. Grey box in production is feasible but riskier; ideally, use an equivalent, isolated environment.
4. Consider the cadence: a recurring grey box is significantly more valuable than a single annual one. Quarterly is the most common cadence at mature companies.

For the full security roadmap for SaaS, see SaaS security. For the specific technical scope of a pentest, see SaaS penetration testing. For fintech, see fintech penetration testing.

Other guides in this series: Black box pentesting and the comparison of all three approaches, which also covers white box.

Ready to get started? Request a pentest. Mutual NDA within 24h.