Unmanaged / self-managed bug bounty
Unmanaged bug bounty. Self-managed, with clear responsibilities.
An unmanaged bug bounty puts your organization in charge of program operations. Also called self-managed bug bounty, it suits teams prepared to validate reports, communicate with researchers, make reward decisions, and drive remediation. Understand the workload before choosing how much external support you need.
Your team at the controls
THE RIGHT MODEL FOR YOUR TEAM
What is an unmanaged bug bounty program?
In an unmanaged or self-managed bug bounty program, the customer runs the operational process rather than handing report validation and researcher coordination to a managed service. A reporting platform can centralize submissions and conversations, while tools can assist reproduction and analysis. Accountable validation, impact assessment, and disclosure decisions still need an assigned owner. Your team provides the people, authority, and process behind those decisions.
Self-managed does not mean public or free. Your team can invite selected researchers or accept broader participation. Platform access, payment administration, integrations, and specialist support depend on the agreement. With Hackrate, confirm which tasks your team retains and which support is included before deciding how the program should operate.
Explore the Hackrate platformDirect control of decisions
Your team applies its product knowledge to report validation, severity, reward decisions, and exceptions. This can work well when experienced application security staff already have an established process and decision-making authority.
Direct researcher relationships
Internal staff manage clarification and status updates themselves. Researchers can benefit from access to the people who understand the product, provided those people have time and a clear communication routine.
A workflow aligned to your team
Build triage and escalation around existing engineering ownership and release processes. Decide how findings enter your backlog and what evidence is needed before a report can progress to remediation.
A deliberate support choice
Assess which tasks your team can sustain internally and where external help is valuable. Separating platform needs from operational needs makes a discussion about managed services more specific and easier to scope.
FROM SCOPE TO REMEDIATION
What your team needs to run
Publish a workable program policy
Write authorized scope, exclusions, rewards, reporting requirements, and disclosure expectations. Confirm ownership of listed targets and define what researchers should do when a test could affect real users or availability.
Triage and reproduce submissions
Read incoming reports, request missing details, check scope and duplicates, reproduce safely, and assess impact. Assign backup capacity so important reports do not wait whenever one specialist is unavailable.
Communicate and decide rewards
Acknowledge reports, provide useful updates, explain decisions, and handle disagreements consistently. Apply the published reward criteria and maintain a reliable approval and payment process under the agreed arrangement.
Connect findings to verified fixes
Assign an engineering owner, prioritize the work, and keep the report linked to remediation. Coordinate any retesting and disclosure timing, then capture closure evidence and lessons for future program changes.
TWO DECISIONS. FOUR COMBINATIONS.
Who runs it.
Who takes part.
Managed and unmanaged describe operational responsibility. Private and public describe researcher participation. Choose one from each dimension to shape a program around your team.
A private program can be managed by Hackrate. A public program can be operated by your own team. Access controls and operating responsibilities should be agreed separately.
| Program model | Private | Public |
|---|---|---|
| ManagedProvider-led operations | Invited researchers. Managed coordination and validation. | Broader participation. Managed coordination and validation. |
| UnmanagedCustomer-led operations | Invited researchers. Your team runs the agreed workflow. | Broader participation. Your team runs the agreed workflow. |
Public participation does not automatically make vulnerability reports public. Disclosure follows the program’s agreed rules.
MAKE AN INFORMED START
Choose self-management for capacity, not just control
A good fit when…
- An experienced application security team can reproduce findings and assess business impact.
- Named staff can maintain researcher communication alongside their other responsibilities.
- Your organization already has reward approval, escalation, and remediation processes.
Have these foundations ready.
- Triage has a primary owner, backup cover, and a route for urgent reports.
- Staff can handle duplicates, incomplete evidence, disputes, and disclosure requests consistently.
- Engineering owners and a reward budget are available before researchers begin work.
CLEAR OWNERSHIP. ACTIONABLE FINDINGS.
The hidden workload is usually between the reports
A submitted report is the beginning of an operational task. Some findings require a suitable test account, several exchanges with the researcher, an explanation of an unusual business workflow, or coordination across engineering teams. Other submissions may be duplicates or lack enough evidence to validate. Consistent handling depends on the time and judgment of the people running the program, even when reporting and status tracking are centralized.
Agree a process for unexpected absence, release pressure, and urgent vulnerability reports. Set communication expectations that your team can maintain and review whether reports are progressing toward decisions and fixes. If the backlog grows or researcher conversations lose ownership, reconsider the support allocation. Moving selected tasks to a managed arrangement is an operating decision to discuss, with the new responsibilities documented before they change.
PLAN THE FULL INVESTMENT
Unmanaged does not mean there is no operating cost
Compare total effort across the models. A self-managed program still needs a reward pool, any agreed platform services, internal security time, payment administration, and engineering capacity. Experienced staff may spend significant time clarifying or reproducing reports. Treat that capacity as part of the budget rather than comparing only the visible platform or management charge.
Start with a scope and participation level your team can support. Review report complexity, communication effort, remediation progress, and reward use before expanding. A smaller invited program can make the initial workload easier to observe, but neither a private scope nor a self-managed model guarantees a predictable submission rate or a lower overall cost.
CUSTOMER STORIES
See how companies put
security testing to work.
Different products and priorities. A practical approach to understanding and addressing security risk.
Preparing for managed bug bounty.
Explore SEON’s approach to a prepared testing environment and researcher-driven security testing.
Read the SEON story
From a pentest to ongoing feedback.
See how XUND followed an initial PTaaS engagement with a private bug bounty program for its API.
Read the XUND story
Making testing activity visible.
Learn how Lensing used crowdsourced testing and HackGATE while preparing for its SOC 2 audit.
Read the Lensing storyYOUR QUESTIONS, ANSWERED
Unmanaged Bug Bounty: Self-Managed Programs FAQs.
Understand the model, the responsibilities, and the next step for your team.
Ask us a questionLooking for programs to join?
Browse the program catalog
Is unmanaged bug bounty the same as self-managed bug bounty?
The terms usually describe a program whose customer handles operational tasks such as triage, researcher communication, and reward decisions. Providers may divide tasks differently, so compare the responsibilities in the actual proposal rather than relying on the label alone.
Can an unmanaged program be private?
Yes. Participation and operations are independent choices. Your own team can operate a program limited to invited researchers, or run a public program under published rules. In either case, the customer needs enough capacity to handle the resulting reports and conversations.
What expertise does our internal triage team need?
It needs to understand the application, reproduce reports safely, distinguish duplicates and out-of-scope findings, and assess technical and business impact. Staff also need a consistent communication process and access to engineering owners who can answer questions and implement fixes.
Does using a platform include managed report validation?
A platform and a managed service are different parts of an engagement. Reporting, tracking, and communication features do not establish who validates a finding. Confirm the validation owner, support coverage, reward administration, and other operational tasks explicitly in the agreement.
Can Hackrate help us compare managed and self-managed operations?
Yes. Bring your proposed scope, internal staffing, existing workflow, and expected support needs to the discussion. Agree which responsibilities your organization will retain and what Hackrate services are available for the engagement before deciding how the program should operate.
Is self-managed bug bounty cheaper than a managed program?
It can reduce some external service requirements, but it also creates internal work. Compare platform charges, rewards, staff time, operational cover, and engineering effort. The appropriate choice depends on your team and scope; a lower visible fee does not establish a lower total cost.
When should we reconsider the operating model?
Review it when triage loses ownership, researcher updates are delayed, report complexity exceeds available expertise, or the scope grows faster than staffing. Agree any new support and responsibility allocation before expanding. A program should grow with the capacity to act on its findings.
EXPLORE BUG BOUNTY PROGRAMS
Choose how your program works.
Decide who runs the program and who can take part. A managed program can be private or public.
OPERATING MODEL
Managed bug bounty
Hackrate coordinates researchers and validates reports so your team can focus on risk decisions and remediation.
Explore Managed bug bountyOPERATING MODEL
Unmanaged bug bounty
Understand the people, processes, and ongoing responsibilities behind a self-managed bug bounty program.
You’re exploring this modelPARTICIPATION MODEL
Private bug bounty
Start with invited researchers, an agreed scope, and a controlled approach to researcher participation.
Explore Private bug bountyPARTICIPATION MODEL
Public bug bounty
Open defined assets to a broader researcher community with clear rules, rewards, and a prepared response team.
Explore Public bug bountyREADY TO EXPLORE YOUR OPTIONS?
Choose the work your team should own.
Walk through your scope, staffing, and reporting process with Hackrate. We will help you discuss the operating responsibilities and support that fit your organization.
Discuss Your Operating Model
Hackrate
Our platform helps companies to identify software vulnerabilities in a cost-efficient way. It provides a secure and centralized view of ethical hacking projects for your company.
US Patent Applied for HackGATE #63/645,845
Products
From the Blog
-
Hackrate Ranked 1st in Hungary and 22nd Globally at Hack The Box’s Global Cyber Skills Benchmark 2026
May 29 • 13 min read
-
Press release: Hackrate becomes Hungary’s first CVE Numbering Authority
Jan 13 • 5 min read ★
-
Let 2026 be the year bug bounty becomes part of how you build and operate
Jan 05 • 4 min read
Numbering Authority