What is bug bounty: programs, platforms and rewards 2026

A bug bounty program is an ongoing initiative through which an organization offers financial reward to external researchers for discovering and responsibly reporting security vulnerabilities. Unlike a point in time audit, the program stays open over time and turns the exposed surface of the company into a permanent target for testing by a broad, specialized and diverse community. The first modern program dates back to 1995 (Netscape), but the category consolidated as an industry with the appearance of platforms like HackerOne and Bugcrowd from 2012 onwards, and spread across public administration, banking, retail and technology over the following decade.

Key points

• Bug bounty pays external researchers for responsibly reporting vulnerabilities on a continuous basis.
• The most used platforms in 2026 are HackerOne, Bugcrowd, Yeswehack, Intigriti, Yogosha and Open Bug Bounty.
• Three models coexist: public (open), private (invite only) and VDP (formal channel without reward).
• Payout ranges depend on severity and program reputation, not on the internal cost of fixing.
• Launching a program requires prior security maturity, an IR runbook, a safe harbor policy and a solid triage process.

Bug bounty versus pentesting, red team and VDP

These four activities are often confused, but they serve different purposes and coexist in a mature security strategy.

Bug bounty does not replace pentesting: it complements an already audited base. An organization with no prior pentest that opens a public program receives a flood of trivial findings that saturate the team and damage the relationship with the community. The reasonable order is initial audit, remediation, controlled private program and, only once the flow is stable, public opening.

Main platforms active in 2026

HackerOne is the global reference platform by program volume and community size. It hosts everything from small programs to the largest in the sector (defense, banking, hyperscalers). Its managed triage offering offloads the client from the first validation phase. It is strongest in the North American market and prices at the premium end.

Bugcrowd competes directly with HackerOne for global share. It is very common in Fortune programs and US administration. Its severity rubric (VRT) is a reference used even outside the platform.

Yeswehack is the European platform with the strongest regional footprint. It has particular strength in France, Benelux and the regulated European market. It is the preferred option when a company wants to keep program data under European jurisdiction for NIS2, sectorial sensitivity or sovereignty reasons.

Intigriti is the second relevant European platform, headquartered in Belgium with sustained growth. It has gained traction among European mid-market companies, fintech and administrations that value proximity and local language support.

Yogosha operates mainly in the French and French speaking markets, focused on curated private programs. Its model prioritizes community quality over volume, which fits well in highly regulated sectors.

Open Bug Bounty is a separate case. It is a non profit platform focused exclusively on non intrusive web vulnerabilities (XSS, open redirects) reported to identified owners. It does not handle payments: it acts as a mediator to coordinate disclosure. It is useful for researchers who find bugs in sites without a formal program, but its coverage is limited.

Program models: public, private and VDP

Public (open): any researcher can register, read the rules and submit reports. It maximizes reach but also noise. It requires a properly sized triage team and very clear rules. It is the model associated with large technology brands and a good part of the public sector. The sense of exposure is high, which is compensated by reputation and visibility toward customers.

Private (invite only): the platform selects or the client curates a list of vetted researchers. Report volume is much lower, average quality higher and confidentiality on the brand is preserved. This is the usual entry point into bug bounty for companies opening a program for the first time. Many platforms allow scaling from private to public once operations are running smoothly.

Vulnerability Disclosure Program (VDP): no financial reward, only a formally documented channel for any researcher to report vulnerabilities. It is the minimum that many regulations expect from a serious organization. The security.txt document (RFC 9116) at the domain root advertises the channel and reduces friction for those who want to report. NIS2 and the upcoming CRA push every essential or important entity to have at least a functional VDP.

The operational difference between a VDP and a bug bounty is not just the reward. A VDP signals willingness to receive reports; a bug bounty assumes the cost of actively incentivizing search. The investment and internal requirements change significantly.

Scope: what is included and what is excluded

Defining scope with precision is what separates a working program from one that drowns in noise. There are technical and business decisions that must be resolved before publication.

Assets in scope: production domains, public APIs, mobile apps published in official stores, internet exposed infrastructure. Listed explicitly with clear notation (wildcards only when impact is understood).

Assets out of scope: staging and non productive development environments, third party infrastructure (even if used by the company), vendor SaaS, corporate domains with informational only content, recent acquisitions until full integration.

Tests not allowed: denial of service attacks, social engineering against employees or customers, physical attacks, massive fuzzing that affects availability, access to real data of other users.

Time boxing: some programs limit windows (for example, no testing during critical commercial events). Others apply specific rate limits to avoid saturating logs and alerts.

Mobile: when included, it is worth defining accepted versions, policy on reverse engineering, rooted or jailbroken devices, and handling of data extracted during testing.

Third party and subprocessors: never in scope without explicit authorization from the third party. Reports arriving on third party assets are rejected and redirected.

Payout structure and 2026 market ranges

Ranges vary across platforms and programs, depend on asset reputation, team maturity and sectorial competitiveness. As qualitative guidance for 2026:

Critical (pre auth RCE, mass account takeover, cross tenant data exposure): typical ranges from 5,000 USD in mid market programs up to 50,000 USD or more at hyperscalers. Exceptional cases at large technology firms or defense have exceeded six figures.

High (auth bypass, SSRF to cloud metadata, IDOR with sensitive data): between 2,000 and 10,000 USD in competitive programs.

Medium (XSS with impact, CSRF on sensitive endpoints, limited data disclosure): between 500 and 2,500 USD.

Low (XSS without material impact, open redirects, minor information disclosure): between 100 and 500 USD when accepted.

Informational: no reward, but may count for in program reputation.

A frequent mistake is setting payouts based on the internal cost of fixing. The correct reference is the opportunity cost of the researcher compared to other programs. A Critical paid at 1,000 USD discourages serious submissions: the researcher would rather report the same bug to another program paying ten times more. The consequence is not that the bug goes undiscovered, but that it gets discovered outside the program.

Triage process step by step

The typical path of a report follows a clear sequence and must be documented from the program page itself.

1. Report submission: the researcher completes the template with title, description, reproduction steps, impact, proof of concept and evidence. Serious platforms reject reports without reproducibility.

2. Platform triage: the platform team (or the client if running its own triage) validates that the bug exists, fits the scope and is not a duplicate of a previous report.

3. Internal vendor validation: the client security team confirms the bug, assigns initial severity and opens a ticket in the vulnerability management system.

4. Severity discussion: if the researcher disagrees with the assigned severity, they open a dispute. The program rubric acts as reference. Platforms like Bugcrowd publish their VRT to reduce disagreements.

5. Payout: once severity is confirmed, payment is processed according to the published ranges. A reasonable timeline is between 7 and 30 days from validation.

6. Remediation: the security team coordinates the fix with development or with the external vendor. The researcher may request a retest once the patch is deployed.

7. Disclosure: when the bug is mitigated, the researcher and the program agree whether to publish a summary, keep it confidential indefinitely or publish after an embargo period. Some programs have a transparency policy that publishes every resolved report.

The metric the community watches most is time from submission to first human response and from validation to payout. A program that takes weeks at each step loses researchers quickly.

How to set up your own program

Before opening a program, several internal pieces must be in place. Skipping this step creates operational chaos and damages the relationship with the community from the first week.

Minimum security maturity: the organization has already gone through at least one recent pentest, has remediated critical findings and maintains a basic vulnerability management program. Opening bug bounty against a non audited surface guarantees saturation.

Active IR runbook: the team knows how to escalate a Critical out of hours, has a channel into development and can deploy an emergency fix. Otherwise, receiving a Critical on Friday at 8 pm will be a bigger problem than the vulnerability itself.

Legal framework and safe harbor: an explicit clause that protects the researcher from legal action when acting within program rules. Without safe harbor, good researchers do not participate. The specific wording varies by jurisdiction and should be reviewed by a specialized lawyer.

Platform choice: the main criteria are data jurisdiction, community available in the product language, triage model the company is willing to assume and a realistic annual budget (platform fee plus payouts plus internal time).

Communication policy: initial response within a defined window (24 to 72 hours), bilingual communication if the product operates in different markets, transparency about bug status and willingness to explain severity decisions.

Budget: a modest private program can run on between 30,000 and 80,000 USD per year counting platform and payouts. Public programs at mid sized companies move between 150,000 and 500,000 USD per year. Technology giants pay millions every year.

Common mistakes that kill programs

Scope too restrictive: limiting the program to two secondary subdomains creates the sense that the company does not really want bugs found. Good researchers rotate to more generous programs.

Non competitive payouts: paying below market average pushes out the senior profile. The program fills with informational reports and low quality duplicates.

Slow triage: taking three weeks to respond to the first report kills researcher motivation. The community publishes metrics and programs with bad reputation feel it in the inflow.

Recurring severity disputes: if triagers systematically downgrade severity to lower payout, trust breaks. The rubric must be explicit, public and applied consistently.

No hall of fame or recognition: financial reward matters, but visibility matters too. Programs without public recognition lose out against programs that highlight their top contributors.

Unilateral rule changes: modifying scope, ranges or policy without prior notice retroactively damages the relationship. Changes must be announced and must respect reports already in flight.

Forgetting the baseline VDP: launching bounty without a clearly accessible VDP leaves out anyone who discovers a bug without wanting to join the formal program. The security.txt file is the reasonable minimum.

Regulatory fit: NIS2, ENS and EU CRA

NIS2 does not formally require a bug bounty, but the Spanish transposition and most European ones require coordinated vulnerability disclosure policies for essential and important entities. A VDP covers the requirement; a bug bounty goes further. ENISA publishes guidance that treats bug bounty as an advanced vulnerability management tool.

ENS (Spanish National Security Framework) at its high level requires documented vulnerability management processes. Having a formal disclosure channel and, optionally, a reward program, reinforces compliance and provides audit evidence.

EU Cyber Resilience Act (CRA) introduces specific obligations for manufacturers of products with digital components. The articles on vulnerability handling require coordinated disclosure policy, reporting channel and processes to notify exploited vulnerabilities. The regulation enters application progressively from late 2026, with full deadlines toward 2027 for most obligations.

Other references: ISO/IEC 29147 on vulnerability disclosure and ISO/IEC 30111 on vulnerability handling are the international references for designing the internal process.

Frequently asked questions

Does it make sense for an SMB to launch bug bounty? In most cases, not as a first measure. The reasonable order is initial pentest, remediation, VDP with security.txt and, if the surface is significant and there is internal maturity, a curated private program. Skipping steps creates more cost than value.

Is my annual pentest enough without bug bounty? For many profiles, yes. Pentest covers point in time auditing with methodology and a formal deliverable. Bug bounty covers continuous pressure between audits. If the surface changes little and the release cycle is quarterly, pentest may be enough. If there are weekly deployments and growing surface, bug bounty adds coverage between audits.

Is making a living from bug bounty as a freelance realistic? For a minority yes, for most not as a single income source. Consistent full time hunters in global programs generate income comparable to a senior security profile. The learning curve is long, competition is high and income is irregular. The norm is to combine it with consulting, training or full time employment.

Yeswehack versus HackerOne for European companies? Yeswehack offers European jurisdiction, local support and a comfortable fit with NIS2 and ENS. HackerOne has a larger global community and a richer set of managed services. The choice depends on the priority between global reach and regulatory proximity. Many European companies pick Yeswehack or Intigriti for the main program and keep a presence on HackerOne for specific cases.

Does GDPR apply to data handled by researchers? Yes. When a researcher inadvertently accesses personal data during testing, they must stop, not exfiltrate, report and delete. The program must document this flow. The data controller remains the company, not the platform or the researcher.

Is safe harbor mandatory? Not by law, but without safe harbor the program attracts less talent and serious researchers avoid it. It is a standard piece in any program with ambition. The specific wording should be reviewed per jurisdiction.

Related resources

• AI bug bounty: programs and AI vulnerability rewards for the specific case of AI models.
• What is pentesting: business guide if you need the audit baseline before bug bounty.
• What is a CVE to understand how a reported vulnerability is cataloged and identified.
• What is ethical hacking to place bug bounty within the legal offensive security ecosystem.
• What is red team: business guide if you need a directed exercise instead of a continuous program.
• Cracker versus hacker: differences to clarify terminology when communicating the program internally.

Bug bounty program with Secra

Launching a bug bounty requires a solid foundation before the first report. At Secra we help prepare the organization for the program: prior audit, scope definition, rules and safe harbor policy drafting, triage sizing and platform choice based on jurisdiction and maturity. We also operate managed triage for private programs when the internal team cannot absorb the initial load. If you are evaluating opening a program or need to professionalize an active one, contact Secra and we will design the full path together.