Microsoft has scrapped its sliding scale of report quality and now judges every bounty submission as either Complete or Not Complete, and on its Azure programme a Not Complete rating cuts the award to a tenth. The change, live since 20 October, is driven in part by the growth in AI-assisted findings and could set a template for other programmes.
What happened
On 20 October 2026 Microsoft’s security response team (MSRC) announced that reports reaching its bounty programmes from 8am Pacific Time that day onwards are assessed under a simple two-state test. A submission is either Complete, meaning it carries everything engineers need to understand, reproduce and evaluate the issue, or Not Complete, meaning at least one required element or artefact is missing. Anything filed before the cut-off is still handled under the old multi-level quality rules.
Completeness now feeds directly into the award. MSRC is careful to say it does not decide severity, scope or eligibility, which are still weighed separately. But the Azure bounty page, updated the same day, shows how sharp the gap is. A critical remote code execution or elevation of privilege finding with a Complete report is listed at $40,000; the same bug written up as Not Complete is listed at $4,000. The pattern holds down the table: critical information disclosure drops from $12,000 to $1,200, and important-rated spoofing or tampering from $4,000 to $400. Moderate and low issues earn nothing either way, and the Azure programme range runs from $400 to $60,000, with discretion to go higher.
Microsoft links the change in part to AI. Its announcement says AI-assisted research makes it easier to find and file possible issues at scale, and that while the company encourages researchers to use these tools, every report must still describe the technical analysis accurately and carry real evidence.
The detail
The minimum for a Complete rating is a set of things any experienced triager would recognise: reliable reproduction steps, a minimised proof of concept, the vulnerability class, root cause analysis where possible, the affected environment and version, the attacker’s position and prerequisites, and a clear statement of impact. On top of that sits evidence specific to the bug type and product area.
MSRC gives examples. Memory corruption and denial of service reports against on-premises products may need crash information, call stacks and the source code for a proof of concept. File redirection bugs may need a Process Monitor log. NTLM coercion and relay findings may need a packet capture. Web application reports may call for a video demonstration and scripts, and some reports may need to explain how information is returned to the attacker. Crash dumps and Time Travel Debugging traces also appear on the list. Reports on AI systems still follow Microsoft’s separate AI vulnerability guidelines.
Two procedural points matter more than they first appear. First, the rating is based on the initial submission. MSRC may ask follow-up questions, but GBHackers and Cyber Press both note that researchers cannot rely on later clarification to upgrade a report. Second, reproduction steps, proof-of-concept detail and impact must be typed into the Researcher Portal fields themselves. A polished write-up attached to a thin form is no substitute. MSRC also offers a self-check: could an engineer new to the issue reproduce it from the report alone?
Why it matters for UK organisations
Three UK groups should pay attention. The first is the domestic research community. UK hunters, many of them freelancers or consultants doing bounty work alongside day jobs, now face a payout structure where presentation is worth as much as discovery. A strong finding filed in a hurry could be worth a tenth of what it would earn with a proper write-up.
The second is every UK business that depends on Azure, Microsoft 365 and Windows estates, which is most of them. Microsoft’s stated aim is faster assessment and fewer back-and-forth requests. If that works, genuine flaws should move from report to fix more quickly, and vendor triage time stops being spent on speculative, machine-generated claims that cannot be reproduced.
The third is any UK organisation running its own vulnerability disclosure policy or bounty, from fintechs to public bodies. Most have far smaller triage teams than Microsoft and face the same AI-generated volume. One of the world’s biggest software vendors has just published a workable definition of a usable report, mapped to bug classes, and tied money to it. Copying the principle, if not the dollar figures, is an obvious next step. It also fits neatly with the wider UK conversation about protecting good-faith research under Computer Misuse Act reform: clear rules of engagement and clear evidence standards help separate legitimate researchers from noise.
Expert view
In my experience, the quality of a finding and the quality of a report are two different skills, and the industry has quietly rewarded the first while tolerating poor versions of the second. Microsoft is now pricing that gap openly. I think that is broadly the right call.
The risk is at the edges. Some genuinely serious issues are hard to reduce to a tidy proof of concept, particularly logic flaws in cloud services, race conditions and multi-tenant problems where the researcher is deliberately constrained by testing rules. A binary test applied strictly could punish exactly the careful hunter who stopped short of overstepping scope. Microsoft says it may still ask for more information, and how generously triagers apply the Not Complete label in borderline cases will decide whether this feels fair. Judging the first submission should also discourage the habit of filing early to claim priority and enriching later.
When we test for clients, the deliverable that gets a flaw fixed is never the clever exploit. It is the clear reproduction, the version detail and the impact statement a developer can act on without phoning us. Bounty hunters are now being paid to work the same way, and AI tools that generate volume without that rigour will simply earn less.
What to do now
- Researchers: read the product-specific guidance before filing. Check the evidence list for your bug class and programme, not a generic template, and enter steps and proof of concept directly in the portal fields.
- Researchers: run the reproducibility check. Ask whether a stranger could reproduce the issue from your report alone. If you used AI to help, verify every technical claim yourself.
- Researchers: stay inside the rules of engagement. Do not push further than permitted to “prove” impact; describe the theoretical consequence and the conditions instead.
- Programme owners: publish your own completeness standard. Define mandatory fields and bug-class evidence in your VDP or bounty brief, and link reward levels to them.
- Security teams: keep patching quickly. Faster vendor triage only helps if fixes are applied. Cyber Essentials expects high and critical updates within 14 days of release under the security update management control.
Bottom line
Microsoft has put a price on report quality: on its Azure table, a Not Complete write-up of a critical bug earns a tenth of a Complete one. It is a pragmatic response to AI-driven volume that rewards the discipline good testers already practise, and UK programme owners would do well to borrow the idea before their own triage queues buckle.
Sources
- Microsoft Security Response Center: Introducing Complete and Not Complete report assessments across Microsoft bounty programs
- Microsoft Security Response Center: Microsoft Azure Bounty
- GBHackers: Microsoft Introduces New Bug Bounty Rules That Could Affect Security Researchers’ Rewards
- Cyber Press: Microsoft Changes Bug Bounty Rules, Requires Detailed Proof of Concept for Higher Rewards
