Bounty tiers allow you to apply different reward structures to different parts of your program scope, enabling more strategic allocation of your security budget. By assigning scope items to specific tiers, you can effectively prioritize critical assets while still maintaining broad coverage.
Key takeaways:
Bounty tiers help you strategically incentivize researchers based on asset importance, complexity, and maturity
You can assign different scope items to tiers 1-5, with higher tiers typically offering larger rewards
"No Bounty" options allow you to include assets without financial rewards
This article is for
Program managers who want to optimize their bug bounty program structure and budget allocation.
When managing a bug bounty program, you'll likely have assets of varying importance, complexity, and maturity levels. Some systems might be business-critical "crown jewels" deserving higher rewards, while others might be newer additions or less critical systems. Bounty tiers solve this challenge by allowing you to create different reward tables and assign them to specific parts of your scope.
Instead of offering the same rewards across all assets or limiting your scope to only high-priority items, bounty tiers enable you to include your entire attack surface while intelligently allocating your security budget where it matters most.
How bounty tiers work
Bounty tiers allow you to create up to five different reward structures (Tiers 1-5) and assign them to specific scope items in your program. When setting up your program, you can indicate in the domains section which bounty tier applies to which part of the scope.
For example, you might assign:
Tier 1: Critical payment systems and user data repositories
Tier 2: Core application functionality
Tier 3: Secondary features and supporting services
Tier 4: Newly added assets still being tested
Tier 5: Marketing websites and non-critical assets
This tiered approach gives researchers clear guidance on where to focus their efforts and what level of reward they can expect for valid findings.
Strategic use cases for bounty tiers
Prioritize by importance
Assign your most critical assets ("crown jewels") such as payment processing modules or user data repositories to higher tiers with larger rewards. This naturally directs more researcher attention to your most important systems.
Varying maturity levels
Newer or less-tested systems often have more easily discovered vulnerabilities. You can place mature, well-tested systems in higher tiers to reflect the increased difficulty in finding new issues, while keeping newer systems in lower tiers until they've undergone sufficient security testing.
Compensate for technical complexity
Some targets require more setup effort or specialized knowledge from researchers. Mobile applications, APIs, or on-premise solutions often have higher barriers to entry compared to web applications. Higher-tier rewards can help incentivize researchers to invest time in these more complex targets.
Different budget priorities
By using all five available tiers, you can create a more granular approach to budget allocation, ensuring you're paying appropriate rewards based on the precise value and priority of each asset.
Best practices for using bounty tiers
Do:
Include all potential attack surfaces in your program, using tiers to manage budget constraints
Consider using a wildcard domain in a lower tier (such as Tier 3, 4, or 5) with lower bounties
Progressively move scope items up the tier ladder as they mature (e.g., from Tier 4 to Tier 2)
Clearly communicate to researchers which assets belong to which tiers
Common approach
Many program owners start newly added scope at Tier 3, 4, or 5, then move it to higher tiers as it matures and the easy-to-find vulnerabilities are addressed.
Don't:
Create overly complex tier structures that might confuse researchers
Keep mature, critical assets in lower tiers to save money
Forget to periodically reassess your tier assignments as your assets evolve
Using the "No Bounty" option
Beyond the five bounty tiers, you can also designate scope as "No Bounty" domains. This special designation means:
Researchers can submit findings on these domains
You welcome these submissions but don't award financial bounties
Researchers can report accidental discoveries without being penalized with "Out of Scope" rejections
This approach is particularly valuable for:
Assets you want visibility into but haven't allocated budget for
Systems undergoing preliminary assessment before being moved into a bounty tier
Low-risk assets where you want coverage without financial commitment
By including these assets as "No Bounty" rather than leaving them completely out of scope, you allow researchers to report findings without negatively affecting their valid submission ratio.
Related resources