Customers can now set a limit on how many trial reports a researcher can have open in their program at one time. The limit can be configured between 1 and 3, with a default of 3, giving customers more control over trial report volume in their programs.

We have received multiple requests in recent months to use a hard-coded workaround that requires engineering effort each time.

Programs with a genuine concentration problem - a limit you can set and see

Ask your representative to enable it, then go to the Security page → Hacker Management → Submission, set the value, and click Update.
​
​Documentation: Signal Requirements

Signal requirements move from four fixed bands to a configurable range of −1.0 to 7.0. Existing programs keep their current value; nothing changes unless a customer edits it.

Replaced the four fixed options: Strict (1.0), Moderate (0.0), Lax (−1.0), and Off, with a configurable signal slider anywhere in the −1.0 to 7.0 range.

As the customer moves the slider, they will see a list of hackers who recently submitted reports, which will then be limited to trial reports, providing a perspective on the impact. The customer can test using the slider and view the affected researchers without applying the setting change.

The program signal will now display in the Program highlights section of the Security page, with researcher change tracking.

Added banners on submission pages to inform researchers as to whether they clear the bar or need to use trial reports to submit to a program.

Left all existing program configuration untouched. A program on Strict stays at 1.0, a program on Moderate stays at 0.0, a program on Lenient stays at -1.0, and programs with a signal of nil or -10.0 remain off.

AI-assisted testing has increased submissions, but customers seeking a tougher gate had no option above Strict. They had to absorb the noise or disable the signal requirements. Of 2,889 live gated programs, 88.7% use Moderate, a weak gate at current volumes. HackerOne also bears the cost: spam still reaches restrictive programs, consuming triage time and intake tokens. Without a solution, backlogs will grow, and triage will slow for HackerOne and customers.

Security page → Hacker Management → Submission. Set any value from −1.0 to 7.0, or turn signal requirements off and select update. No migration is required, and no action is needed for programs that are happy with their current setting.

Documentation: Signal Requirements

Every researcher will have a trial report limit of 3, replacing the tiered, rolling concurrency cap.

The number of available trial reports will return to a maximum of 3 when:

Additionally, if a trial report is closed as a Duplicate of a report marked as Triaged or Resolved, and the original report was not disclosed before submission, the researcher will receive 1 additional trial report, up to the maximum of 3 available trial reports.

We changed how the trial report limit works, replacing the tiered, rolling concurrency cap with a limit of 3 trial reports per researcher.

Researchers receive 3 trial reports, shared across all programs where they do not meet the signal requirement.

The number of available trial reports resets to 3 when any of the following occurs:

Researchers also receive 1 additional trial report, up to the maximum of 3, when all of the following conditions are met:

Withdrawn reports, reports closed by the researcher, and reports closed as Informative do not restore trial reports.

The 90-day pause begins when the researcher submits their third trial report, not when that report is reviewed.

The pause ends after 90 days or immediately when any of the researcher's reports reaches the Triaged or Resolved substate.

The pause only restricts trial report submissions to programs where the researcher does not meet the signal requirement. Researchers can still submit reports to:

Researchers can also continue commenting, participating in mediation, managing disclosure, and receiving payouts for previously submitted trial reports.

We now record whether a submission used a trial report, the program's signal requirement, and the researcher's signal at the time of submission. This allows us to measure trial report volume directly instead of estimating it.

The changes will be rolled out in phases:

Upon migration, all researchers will start with 3 available trial reports. Reports submitted before migration will not count toward this limit.

The previous trial report limit unintentionally encouraged the behavior it was designed to prevent. Only reports identified as valid were removed from the limit, allowing researchers to preserve their submission capacity by closing reports before receiving an unfavorable outcome. Duplicate reports also counted toward moving beyond the limit, even when researchers had not submitted a valid finding.

Low-signal, low-reputation accounts accounted for a disproportionate share of triage volume, while the creation of new low-signal accounts had increased sharply.

By tying trial report availability to Triaged and Resolved reports, we close these loopholes and ensure researchers earn additional submission capacity through valid findings.

Rolling out the change to new accounts first allows us to address the source of much of the triage volume while monitoring its impact before migrating all remaining researchers.

Nothing to configure. Platform-wide, no customer-specific settings. Researchers see the remaining trial report limit on the submission surfaces and in the report assistant. Paused researchers can see their end date and where they can submit reports.

Documentation: Restricted from Submissions (hacker-facing) - Signal Requirements (customer-facing)

The guidance researchers see before starting an ID verification session now covers nine common causes of failure instead of five, and names them in ways that apply to the people actually affected. Fewer researchers should fail a Veriff session for an avoidable reason.

Expanded the "What not to do?" list in the pre-session ID verification modal from 5 to 9 items. New guidance covers iCloud Private Relay, privacy and script-blocking browser behavior, private/incognito mode, emulators and simulators, submitting a screenshot or printout instead of photographing the physical document, obscuring the photo on the ID, verifying more than one profile, and using a third party to complete verification.

Since ID verification became a prerequisite for submitting to bug bounty programs, the VRM team has been reviewing many more Veriff sessions. They identified specific, avoidable actions behind a large share of failures that the old five-item list did not warn about. Every failed session costs a Veriff session fee, generates a support ticket from a frustrated researcher, and adds manual review work for VRM.

Security researchers who receive clearer instructions before they start are less likely to fail and have to reapply.

Nothing to enable or configure! Researchers see the updated guidance automatically the next time they open the ID verification modal, whether in the ID Verification section of their profile or in the payout setup flow.

Documentation: Docsite page

Text typed into the Request Mediation box is now saved as a draft, so closing the modal by accident no longer loses the request. Report comments already worked this way; mediation now matches.

Both mediation forms, the hacker’s Request Mediation form and the team’s Report abuse → Request mediation form, now autosave the message as they type. Drafts are saved to the user’s account rather than in the browser tab, so the text survives closing the modal, reloading the page, or returning later. Each form has its own draft, which is cleared once the request is submitted.

Clicking outside the mediation modal discarded everything typed in it, with no warning and no recovery. Mediation requests are long and carefully written; the article on requesting mediation asks for evidence, references to scope and a clear desired outcome, so this was an expensive thing to lose.

Nothing to enable. Type into the mediation message box and reopen the form; your text is still there.

Documentation: Hacker Mediation docsite page, Escalating Code of Conduct Concerns docsite page

Hackers can now filter their own report inbox by asset type, making it far easier to navigate a large submission history.

We added an Asset type filter to the hacker inbox (“My reports”).

Hackers could already filter their inbox by state, severity, weakness, and program, but not by the type of asset they’d tested. Prolific hackers with hundreds of reports across many programs had no way to pull up “everything I’ve reported against mobile apps” or “all my source code findings”. Program teams have had asset filtering in their inbox for some time; this closes the gap on the hacker side and brings the hacker inbox in line with asset type filtering that already exists everywhere else hackers work.

High-volume researchers who submit across many programs and asset classes, and anyone who specializes in a particular asset type (mobile, smart contracts, source code, AI models), and wants to review their own track record in that area. There is no change to the program or organization inbox, so no action is needed from customer security teams.

Users with only custom inbox access now go straight to Findings when they sign in or click the HackerOne logo. The Home item no longer appears in their navigation.

We changed the default destinations for users with custom inbox access and no program access so that they land on the Findings page instead of the Home page. Home is not blocked. Anyone can still open it by URL or bookmark.

Home's metrics are built from program access. Custom-inbox-only users saw no open submissions and blank widgets, which users found confusing, thinking that they had no actions to take when, in fact, there were open reports.

Users who have access only through a custom inbox.

Nothing to enable. Affected users sign in and land on Findings, where their custom inbox reports appear. The logic is program-specific, so if a user has access to a custom inbox for only one program but full program access for a second program, they will be taken to the relevant view for that specific program.

Customer credential revocation notifications now fire consistently across all scenarios in which a researcher loses access to a program, including voluntary departure, program/org ban, and platform ban.

Program, organization, and platform bans now trigger the same workflow as a voluntary departure: claimed credentials are marked as revoked in HackerOne, and customer program admins are emailed to revoke that access in their own systems. Previously, a program ban revoked credentials only in our UI, and a platform ban did neither, leaving customer-side credentials live. With a backfill to be completed on October 7, 2026.

Marking a credential revoked in our UI hides the secret from the researcher, but it does nothing to the credential itself. The credentials keep working against the customer's systems until the customer disables them. Our docs place that step with the customer, but we weren't consistently telling customers when to take action.

Customers using asset-based credential management. Their offboarding is now driven by a notification rather than by noticing.

Nothing to enable. Program admins receive the notification automatically; credentials are managed under Program Settings → Credentials. A backfill for researchers who left before September 17, 2026, when this change was released, will be completed on October 7, 2026. CSMs have been contacted with potentially impacted customers.

Documentation: Asset-based credential management

Programs can now invite up to 50 hackers to a spot check, up from the previous cap of 15.

Raised the maximum number of hackers that can be invited to a single spot check from 15 to 50.

The 15-hacker cap was hardcoded, but some programs routinely want to run spot check with ~40 hackers. Every one of those required a one-off engineering escalation to override the limit, a recurring support cost that didn't scale.

Any program running spot checks at scale and the Support/Engineering teams fielding override requests. Immediate relief for AWS, who drove the original ask.

No action needed. When creating a spot check, the hacker-count field now accepts any value between 1 and 50.

Documentation: Docsite page