What ID verification changes mean for public bug bounty programs at Intigriti
By Chris Holt
October 15, 2026
Table of contents
Across the bug bounty ecosystem, providers are moving ID verification on platforms earlier in the researcher journey. This is an industry-wide change. ID verification was historically a payout requirement, but it has now shifted to a submission requirement for programs that offer monetary rewards.
What has changed
Researchers who have completed ID verification tend to produce a higher signal ratio than researchers who have not. Moving verification before submission introduces friction at the point where platforms and triage teams are currently seeing the most pressure: new accounts, low-confidence submissions, AI-assisted noise, and repeat submitters who have not yet established trust. For platforms, this shifts some burden away from triage queues and toward the ID verification process.
But this change is narrower than it may first appear. It does not…
Impact private programs where researchers are invited, ID verified, or already known.
Impact existing verified researchers who are already submitting and being paid.
Prevent researchers from viewing public program details (the gate is at submission creation, not program visibility).
The most affected group is the long tail of new, unverified, or anonymous researchers submitting to public bug bounty programs that offer rewards.
What does this mean for researchers?
In practical terms, if a researcher is likely to be paid, that researcher is either already verified, willing to complete verification, or confident enough in the report to go through the process.
The affected individuals are mostly the wide segment of the community funnel, such as new recruits, speculative AI-assisted submitters, and people who want to disclose without attaching their identity to the report.
Legitimate reasons to avoid ID verification
Some researchers have legitimate reasons to avoid ID verification. They may be:
Operating from sensitive regions.
Reporting on employers or governments.
Dealing with legal uncertainty.
Or simply have lower trust, but still want a responsible path to disclosure.
A healthy public vulnerability intake strategy needs to preserve a path for those reports.
Why public bug bounty programs need to be deliberate.
For companies, a common reaction to this development is to pair a public bug bounty program (BBP) with a public vulnerability disclosure program (VDP) and use the VDP as the “anonymous” or “unverified” intake route.
A Bug Bounty Program (BBP) offers monetary rewards, while a Vulnerability Disclosure Program (VDP) does not. Both programs involve external security researchers. Both programs involve companies seeking to improve their products, applications, infrastructure, and/or IT security.
That can work, but it is not always ideal. If the VDP and the public bounty program have the same scope and policy, researchers will self-sort in predictable ways.
Confident researchers will likely jump through the ID verification hoop and submit to the bounty program.
Less confident researchers will submit to the VDP.
That can increase lower-quality volume in the VDP queue and risk hiding genuinely important reports in a larger pile of noise.
Intentional intake paths
A better model is to define intentional intake paths:
Keep the public bounty program as the rewarded, high-signal path. Make it clear that submissions eligible for monetary reward require ID verification. This aligns the submission requirement with the existing payout requirement: if a researcher wants to be paid, identity verification is part of the process.
Offer an anonymous vulnerability submission path. For researchers who cannot or will not verify identity, provide a clearly linked anonymous reporting option. Intigriti’s embedded submission form can support this pattern by allowing companies to receive vulnerability reports through their own website without requiring an Intigriti account. This can also be shared as a direct link, not only as an embedded website form, making it a practical workaround for public bounty programs affected by the change.
Be explicit about expectations and eligibility. Anonymous submissions should be framed as responsible disclosure, not as a parallel bounty route. Anonymous reports are not eligible for bounties, reputation, or later claim. If the organization wants a path for follow-up, the researcher must provide an optional contact method while still avoiding platform account creation.
Avoid duplicating the same policy across multiple doors. A BBP, a VDP, and an anonymous form should each have a purpose. The bounty program is for reward-eligible findings. The VDP can be a broad safe harbor or a non-rewarded disclosure route. The anonymous form should exist for researchers who need to report without identity, account creation, or platform terms becoming a blocker.
Next steps
ID verification before submission is a significant shift, but the programs that handle it best will be the ones that communicate plainly: rewarded submissions require verification, but responsible disclosure remains welcome. That preserves signal, reduces avoidable noise, and keeps the ecosystem open to the people who may still have something important to report.
For more information on Intigriti’s researcher verification process, visit our ID verification page.
Author
Chris Holt
Chris Holt is a seasoned bug bounty program leader with over 15 years of experience in application and product security. Certified by GAIC, NTISSI, Guinness, PADI, and the USSF, he has spent the last 8 years building and scaling some of the industry's most respected bug bounty programs. His expertise spans the full spectrum of vulnerability management—from offensive security and researcher engagement to program operations and strategic growth.
You may also like
Security teams have more ways than ever to map assets, scan infrastructure, and track vulnerabilities. Yet one question often remains difficult to answer: what does a skilled researcher consider worth exploring? That question matters because external exposure is not only a list of internet-facing as
September 21, 2026
From sceptic to supercharged. How AI changed my day as a QA Engineer
When the push came to start weaving AI into our everyday work, I had doubts at the start. But I have since come around, and here's why. I'm on the engineering team at Intigriti, but my role is Quality Assurance (QA), so I'm the one writing the tests, running the tests, and then collaborating with th
September 8, 2026
How AI has changed the way I think, build, and work. A day in the life of an Intigriti Engineer
When I wake up in the morning, as a Senior Software Engineer at Intigriti, the first thing I do is make coffee. The second thing I do is pick up exactly where I left off the day before, usually mid-conversation with an AI. That probably sounds a bit strange. And, depending on who you're asking, mayb
