At Bugcrowd, our highest operational priority is ensuring that high-value, validated research receives the fast turnaround times and attention it deserves. We’ve heard the concerns from the research community about extended triage times. The current triage queue is experiencing an 388% median increase in submission volume. This situation is not unique to Bugcrowd; the entire industry is experiencing this shift. We know this is frustrating for customers, researchers, and triagers alike, and we’re committed to continuously improve Platform guardrails to improve user experience.

Stated simply, unverified AI-powered submissions from new researchers are extremely high in volume and often very low in accuracy. While we welcome all good-faith researchers in partnering to increase customer resilience, the sheer volume of inaccurate AI-generated submissions are negatively impacting the experience of the established research community, customers, and our triage teams alike. In our ongoing effort to combat this problem, we’re continuously reviewing Platform mechanics to safeguard triage capacity, uphold signal quality across all engagements, and improve the experience for everyone.  

Earlier this year, we introduced mandatory identity verification and baseline throttling controls for Managed Bug Bounty programs. Today, we are further refining two of those enhancements:

  1. Updated submission accuracy metrics 
  2. Adjusted throttling rules. 

These changes are designed to minimize triage friction, protect our triage team’s ability to validate bugs swiftly and accurately, and ensure our community of dedicated researchers experiences faster turnaround times.

Updating the Submission Accuracy metric

To better align Platform metrics with operational efficiency, we have updated how submission accuracy is calculated:

  • N/A outcomes count as rejections—Submissions that result in an “N/A” outcome will now be factored in as rejections within the accuracy rate calculation.
  • Informational outcomes excluded—Reports marked as “informational” will no longer negatively or positively impact your overall accuracy metric.
  • Removal of payout threshold—Submission accuracy is now evaluated across all submissions regardless of payout eligibility or bounty thresholds.

Note: As Platform dynamics and AI-assisted workflows continue to evolve, we reserve the right to further refine these metrics in the future to maintain an optimal balance between accessibility and signal quality.

For complete details on how performance metrics are calculated, please refer to our accuracy documentation.

Enhanced throttling rules for Managed Bug Bounty programs

Alongside our updated accuracy calculation, we are adjusting how submission throttling is enforced across bug bounty programs:

  • Throttling trigger—Any account that submits 10 submissions in a 90 day period will be evaluated for throttling. 
    • If at least 5 of these submissions have been judged in that period, your 90-day submission accuracy must remain above 50% or you will enter the throttled state. 
    • If less than 5 have been judged in that period, your lifetime submission accuracy must be > 50% or you will enter the throttled state.
  • 7-day minimum enforcement—Once throttled, an account remains throttled for a minimum of 7 consecutive days, even if subsequent activity causes the 90-day accuracy rate to rise back above 50% during that window.
  • New throttling limit—Throttled accounts are capped at 6 submissions per week (replacing the previous limit of 5 pending submissions).
  • New accounts—All newly created accounts are throttled by default (minimum 7 days and 10 submissions) upon onboarding until they demonstrate consistent report quality and achieve the required accuracy threshold.
  • Returning accounts—Accounts that have not submitted a report within the last 90 days will have their lifetime acceptance rate evaluated instead of the 90-day trailing rate.

** Please note: Reports currently in the triage queue will continue being processed as-is without interruption; these changes strictly apply to incoming submission limits.

To learn more about managing active limits and maintaining good account standing, please visit our submission limit documentation and identity verification guide.

How this will impact you

For customers and program owners, these changes are expected to bring faster triage and response times, meaning you’ll get actionable vulnerability insight faster. As we work through the queue, you can also expect higher report quality as low-performing accounts are filtered out, reducing noise. 

For many hackers, these changes should pass un-noticed, as their acceptance rate is already above the updated 50% threshold. For some hackers, these changes will result in immediate throttling, limiting the number of submissions you can publish per week. If you fall within this set, please take this opportunity to focus on ensuring your submissions are accurate, reproducible, and describe real impact to the customer. If you are using AI tooling, make sure you’re confirming everything your agent writes and validating that there is a real, impactful Proof of Concept in the submission.

For our triage team, we expect these changes (and some other forthcoming capabilities) to reduce the size of the triage queue and bring triage times back within expected norms. This should allow our triagers to spend more time with individual submissions, improving both SLA adherence and outcomes.

Guidance for throttled accounts

Bugcrowd is actively managing a standard for accuracy and professional excellence, but we also expect a standard of excellence and professionalism from the hackers we work with. Reaching out to a customer or filing tickets does not improve or alter those outcomes. Please take the time to review your submission writeups for clarity, succinctly and directly articulating the finding’s impact, and triple checking the accuracy of the POC for reproducibility. This is the only path to removing the throttled status.

Looking ahead: More granular outcomes

While these controls help mitigate volume overload today, we recognize that not all invalid submissions are created equal. Moving forward, we will be expanding Platform outcome categories to more granularly distinguish between well-intentioned mistakes, unvalidated “sloptimism,” and unprofessional or deceitful behavior.

Our goal is to ensure that genuine learning curves are treated fairly while high-volume speculative reporting is curbed.

We remain committed to supporting quality-driven security research and maintaining a high-signal Platform for researchers and customers alike.

Tags: