Bug Bounty

HackerOne caps low-signal hunters at three trial reports

HackerOne now limits researchers below a programme’s signal bar to three trial reports, with a 90-day pause. What it means for UK programmes.

Bug icon with the headline HackerOne rations reports for unproven hunters

HackerOne has put every researcher on its platform onto a single allowance of three trial reports for programmes whose quality bar they have not yet cleared, with a 90-day pause for anyone who uses all three without a valid finding. It is the clearest sign yet that the big bounty platforms are rationing access to deal with the flood of AI-assisted submissions.

What happened

Monday 19 October 2026 was the date HackerOne set for moving all remaining researcher accounts to a new trial report regime. Accounts created on or after 14 October were due to move first and everyone else on 19 October, with every account starting on migration with three trial reports.

A trial report is spent whenever a hunter submits to a programme whose signal requirement (HackerOne’s reputation score, calculated over the previous 365 days) they do not meet. The three are pooled across every such programme, not granted per programme.

The allowance only refills quickly when a researcher’s work holds up. If any of their reports, on any bug bounty or vulnerability disclosure programme (VDP), reaches Triaged or is closed as Resolved, they go straight back to three. A trial report closed as a duplicate of an earlier, undisclosed report that was itself triaged or resolved gives one back. If none of that happens, the researcher is paused for 90 days, counted from the moment they submit their third trial report rather than from when it is reviewed.

HackerOne’s October changelog also gives programme owners new controls. The four fixed signal bands (Strict at 1.0, Moderate at 0.0, Lax at -1.0, and Off) have been replaced by a slider running from -1.0 to 7.0. Through their customer success manager, programmes can also limit how many trial reports one researcher may have open with them at once, to one or two instead of the default three.

The detail

The old system was a tiered, rolling cap that released one slot every 30 days whatever the quality of the reports. HackerOne says it backfired. Only reports judged valid came off the limit, so researchers could protect their capacity by closing a weak report before it was marked down, and duplicates helped them climb past the cap without any original finding. It also says low-signal accounts were consuming a disproportionate share of triage effort.

The new rules shut those gaps. Withdrawn or self-closed reports earn nothing back, nor does anything dismissed as Informative, Not Applicable or Spam without first being triaged. HackerOne will also now log whether each submission used a trial report, so it can measure trial volume directly.

HackerOne’s case for the wider signal range rests on its own figures. It says that of 2,889 live programmes using a signal gate, 88.7% sat on Moderate, which it calls a weak gate at current submission volumes.

The pause has limits. It does not touch VDPs, programmes without a signal requirement, programmes where the researcher already clears the bar, or pentests they are part of. HackerOne also stresses that this is separate from its requirement for ID verification before anyone submits to a paid bug bounty programme. Both checks can apply to the same report.

HackerOne is not alone. Bugcrowd changed its rules on 8 October. Not Applicable outcomes now count as rejections in its accuracy score, any account filing ten reports in 90 days is assessed for throttling against a 50% accuracy threshold, and throttled accounts are capped at six submissions a week for at least seven days. A week later Intigriti described an industry-wide move to require ID verification before a submission can even be created on paid programmes. Earlier this month, according to SecurityWeek, Google temporarily closed its open source reward programme to new product vulnerability reports after a surge of mostly invalid automated submissions.

Flow diagram showing HackerOne's trial report rules: three shared reports, refilled by triaged or resolved findings, otherwise a 90-day pause

Why it matters for UK organisations

Many UK businesses, public bodies and software suppliers run public programmes or VDPs on these platforms, and the changes affect them in two ways. Programme owners now have a much finer tool for cutting volume, and they will be tempted to push the slider up. A higher threshold shuts out newcomers, and some of them find exactly the issues your regulars have stopped looking for.

The second effect is on the edges of the system. HackerOne’s pause leaves VDPs open, and Intigriti is openly advising companies to provide an anonymous, unrewarded route alongside their paid programme. Organisations should expect that reports which can no longer get into a gated bounty will arrive by other routes: the VDP inbox, security.txt contacts, or a general support address. If those routes are not watched with the same discipline, a genuine finding can sit unread.

For UK-based researchers starting out, three speculative reports followed by a three-month pause makes careless submission expensive. VDPs and ungated programmes are now the obvious place to build signal.

Expert view

I think HackerOne has diagnosed this correctly. The old 30-day drip rewarded patience, not accuracy, and the loophole of closing a doomed report before triage was well known among hunters. Linking the allowance to triaged or resolved outcomes is fair: anyone landing real bugs will barely notice the limit, and HackerOne itself describes such researchers as unlimited in practice.

My worry is concentration. When we test client estates, some of the most valuable findings come from people looking at a target for the first time without assumptions. If 2,889 programmes start drifting towards high thresholds, bounty work could narrow to a small group of established names. That brings fewer duplicates and also fewer fresh perspectives. Rationing access by reputation is a sensible answer to AI noise, but it weakens the old argument that crowdsourcing works because the crowd is big.

Buyers should also note that each platform is building its own gates, from signal to accuracy throttles and identity checks. Reputation does not travel between them, which ties good hunters to whichever platform they have invested in.

What to do now

  1. Review your signal setting before changing it. Use HackerOne’s preview to see which recent submitters a higher threshold would affect, and check whether any of them sent you valid findings.
  2. Staff the side doors. Make sure your VDP mailbox, security.txt contact and support routes have named owners and response targets. This supports the security update management control in Cyber Essentials, because a report you never read is a patch you never apply.
  3. Say clearly what anonymous reports get. If you offer an unrewarded path, state in the policy that it carries no bounty or reputation, so researchers are not left guessing and nobody disputes it later.
  4. Measure the effect. Track duplicate rates, time to triage and valid findings over the next quarter, and tune the threshold accordingly.
  5. Researchers: build signal on VDPs first. One resolved report anywhere resets your trial allowance, so submit only findings you can prove.

Bottom line

HackerOne’s three-report cap, along with similar moves at Bugcrowd and Intigriti, marks a clear move away from open-door bug bounty on the major platforms. Programme owners gain a strong filter against AI-generated noise, but they should use it carefully and make sure the reports it turns away still have somewhere to land.

Sources

Related Posts