ID Verification Required for Bug Bounty Program Submissions
Identity verification is now required for all accounts before submitting reports to Bug Bounty Programs (BBPs). We introduced this requirement in phases throughout August, starting with new accounts, then existing accounts with less than 150 reputation, and finally all remaining accounts.
Vulnerability Disclosure Programs (VDPs) are not affected and remain open without an identity verification requirement.
What We Did
We added identity verification as a requirement for BBP submissions across the platform, including:
Web submissions.
Report assistant submissions.
Hacker API submissions.
We rolled out the requirement in three phases:
August 5: New accounts were required to complete identity verification before submitting to a BBP.
August 14: The requirement expanded to existing accounts with less than 150 reputation.
August 17: The requirement expanded to all remaining accounts.
We also removed the previous requirement to have one valid report before completing identity verification.
When a researcher who has not completed identity verification attempts to submit a report, an in-product banner directs them to verification. Draft reports automatically save so researchers do not lose their work.
For Hacker API submissions, a dedicated error provides the reason the submission was blocked and a link to complete verification instead of returning a generic 403 error.
Why We Did It
Report generation has become faster and less expensive, which has contributed to increased low-signal report volume. Account creation also has little friction, making it easy to replace an account when limits are applied.
Requiring identity verification provides a stronger connection between an account and an individual. We introduced the requirement in phases so we could monitor verification volume and spend as the requirement expanded.
Who It Helps
Bug bounty customers: Requiring identity verification reduces one of the easiest routes for generating low-signal volume through new or replacement accounts.
Researchers: Researchers verify once and can build reputation against a verified identity.
Triage and Vulnerability Response Management (VRM) teams: The requirement helps reduce report volume generated through throwaway accounts.
How to Use It
There is nothing for program teams to configure. The requirement applies automatically to every public and private BBP, whether managed or unmanaged.
Researchers can complete verification from Profile > ID verification + Clear.
VDPs remain open without an identity verification requirement.
Documentation
For more information, see the ID Verification article in the HackerOne Help Center.
Remediation Dashboard
Summary:
A new Remediation dashboard is live in Analytics for all customers. The dashboard shows how valid vulnerabilities move from discovery to fix, how fast remediation happens, and what the unresolved backlog costs in USD. Works on its own for any customer, and complements H1 Remediation for accounts who have it.
What we did:
Shipped a new Remediation dashboard covering the flow from discovery to fix, MTTR trends against history and peers, backlog ageing, and the cost of open exposure risk.
Introduced a new metric, Carrying cost of exposure debt, which connects to. Return on Mitigation. RoM prices the risk that a customer has removed. Carrying costs of exposure debt price in the risk are still sitting in their backlog. Same Annual Loss Expectancy model, same org settings, opposite side of the ledger.
Added Findings flow, the first view tracing every finding through the full funnel in one chart, from all findings through valid, to a remediation plan created, to remediated, coloured by severity. It exposes the gap between a valid finding and a plan to fix it.
Added Days to zero backlog, our first forward-looking metric in Analytics. It turns 90 days of discovery and remediation rates into a timeline to clear the current backlog, with a separate figure for High and Critical.
Corrected MTTR to count valid reports only, and updated the Executive dashboard to match.
Why we did it:
Discovery is no longer the bottleneck, the market finds fast and. Remediation is. Submissions grew 76% year on year, while the unresolved critical backlog grew. Customers had no visibility into how their backlog ages, and no way to put a number on the risk left open. Return on Mitigation demonstrates the value of delivered fixes. Nothing priced the work at an outstanding level, which is the number a CISO needs when asking a board for remediation capacity, and also supports a use case for our new Remediation product.
Who it helps:
CISOs and security leaders who report risk to a board in dollars rather than vulnerability counts.
Program Managers who need evidence remediation keep pace with discovery, and a case for more capacity when the gap widens.
CSMs and AEs in QBRs and renewal conversations. Use this when an account questions the value of Triage spend or Remediation spend,, or asks how their MTTR compares with peers.
How to use it:
Open Analytics -> Remediation.
Read three surfaces together: Discovery to remediation trend for direction, Vulnerabilities by age for the standing backlog, and Days to zero backlog for the timeline.
Use Findings flow to find where valid findings stall before anyone plans a fix.
Use the Carrying cost charts to sequence remediation by money. A handful of critical findings outweigh a large volume of low-severity ones.
Org Admins set the inputs behind the dollar figures in Settings > Return On Mitigation. The same inputs drive Return on Mitigation, so both dashboards stay consistent.
Learn more: Docsite page