Microsoft's bug bounty numbers for July 2025 to June 2026: more than $20 million awarded, across 2,531 eligible reports, from 562 researchers.
Three numbers, and the arithmetic between them says more than any of them alone.
The averages
| Measure | Figure |
|---|---|
| Total awarded | $20m+ |
| Eligible reports | 2,531 |
| Researchers paid | 562 |
| Average per report | ~$7,900 |
| Average per researcher | ~$35,600 |
| Average reports per researcher | ~4.5 |
Averages hide distributions, and bug bounty distributions are famously skewed — a handful of researchers will account for a disproportionate share of both reports and payouts, and a long tail will have submitted one thing that landed.
But even taking the averages at face value, the picture is specific: $35,600 a year is not a salary in most of the markets these researchers live in, and 4.5 eligible reports a year is not a full-time output.
For the overwhelming majority of the 562, this is not a job. It is a supplement.
What the per-report figure tells you
~$7,900 per eligible report is a genuinely high average by industry standards, and it reflects Microsoft's scope: the programme covers products where a serious vulnerability has consequences at national-infrastructure scale, and the top awards run far above the average.
That number is also the recruitment mechanism. A researcher choosing where to spend a weekend is comparing expected value, and a programme paying an average approaching five figures per accepted report competes well against the alternatives — including the ones that are not bug bounty programmes.
That comparison is the part vendors think about most. The market for a working exploit has other buyers, and they pay more. A bounty programme does not have to beat them to be worth running; it has to be a good enough option for enough researchers that a meaningful share of findings arrive through the front door.
What 2,531 reports means operationally
Set aside the money for a moment. Someone triaged 2,531 eligible reports in a year — roughly ten per working day, and that is only the ones that qualified. The volume of submissions that did not qualify is not in this figure and is invariably much larger.
Bug bounty programmes are often discussed as a cheap alternative to hiring. The triage load is the reason that framing is wrong. Every report needs a human to reproduce it, assess it, decide whether it is in scope and route it, and the marginal cost of a bad report falls entirely on the vendor.
Running a programme at this scale is a staffed function, and the $20m is the visible part of the cost.
For anyone building a security business
Two observations that generalise past Microsoft.
The talent pool is broad and part-time. 562 people found something worth paying for in a year, at an average of 4.5 findings each. That is a large, distributed, mostly non-professional workforce — which is exactly the shape that suits crowdsourced models and does not suit a hiring plan.
Trust is the moat. Researchers submit where they expect to be paid fairly, quickly, and credited. Programmes that dispute severity, downgrade aggressively or move slowly lose access to the same pool. That reputation compounds in both directions and is very hard to rebuild.
The number that is not here
What none of these figures show is how many serious vulnerabilities were found and not reported — sold, kept, or used.
That number does not exist in any dataset, which is precisely why bounty programmes are structured as a competing offer rather than a complete solution. $20 million buys visibility into the portion of the market that chose to sell to the vendor. It says nothing measurable about the rest.
