Bug bounty researcher vetting is a dial, not a switch. You match how much you verify about a researcher to the sensitivity of what they can touch, using four tiers: **badge-only intake** (anyone can report, no identity required), **ID-verified payouts** (pseudonymous reporting, but identity plus tax and sanctions checks before money moves), **trust-gated private** (reputation-earned invitations plus mandatory ID verification), and **background-checked or contracted** (criminal screening and named, contracted testers for crown-jewel scope). The mistake founders make is accepting a marketplace's default instead of choosing the notch their threat model actually needs.

You are about to invite strangers to probe production. The question underneath every vulnerability disclosure program (VDP) is simple and uncomfortable: who exactly am I letting in, and how much do I need to know about them first? This is the answer, tier by tier.

## What "vetting a researcher" actually means

Vetting is not one thing. It is three separate, stackable controls that founders constantly conflate, and the big platforms turn each one on independently.

- **Identity verification (IDV / KYC).** Confirming a real, government-verifiable human is behind the handle, usually a photo ID plus a liveness selfie.
- **Payment and tax KYC.** The tax form, payment method, and sanctions screening you legally need before you can send someone money.
- **Criminal background checks.** A formal records screen, typically with a multi-year lookback.

Most public programs use only the middle control. You can let someone report a bug pseudonymously, then require identity and tax paperwork only when a payout is due. That separation, participation on one side and money on the other, is the hinge the entire trust model turns on. Once you see vetting as three dials instead of one switch, the tiering falls out naturally.

## How lightly do HackerOne and Bugcrowd actually vet?

The mainstream marketplaces vet deliberately lightly by default, because their whole pitch is scale. HackerOne's registered community runs well over a million, largely pseudonymous accounts, and the economic argument for open bug bounty is many eyes at low friction.

On HackerOne, researchers can participate **pseudonymously**. A legal identity is required only to get paid: ID verification runs through Veriff, stays valid for 12 months, and only becomes available after a researcher submits at least one valid report. To actually receive a reward, a researcher also needs an approved tax form and a payment method. Criminal background checks are **optional** and gate only the enhanced **HackerOne Clear** tier, run by Checkr with a 7-year lookback, repeated every two years, and reserved for researchers who clear conduct and reputation thresholds (including $15,000 in lifetime bounties). Roughly 20 countries prohibit the check entirely.

Bugcrowd has moved a notch stricter. It now **requires** identity verification, a live selfie plus a government-issued ID, before a researcher can submit to a Managed Bug Bounty program, public or private. Background checks, however, remain an invitation-only add-on for a small, highly trusted cohort. So the two marketplaces are not identical: HackerOne is pseudonym-first with payout-gated KYC, while Bugcrowd gates participation itself behind IDV.

Both then layer a **trust journey** on top. Bugcrowd's researchers unlock public, then private, then restricted engagements as their reputation grows. HackerOne builds toward the same idea through its Pentester program, where testers must be Clear-verified, hold 3-plus years of experience and top certifications, pass a criminal screen, and serve a probation of their first three pentests. Even the "light" platforms build a ladder toward high-assurance work.

## The heavy end: Synack's closed, contracted red team

Synack sits at the opposite pole and vets heavily, up front, before anyone touches a customer. It runs its own **Synack Red Team (SRT)** of **1,500-plus** researchers, and every member clears a **five-step vetting process** designed to assess both skill and trustworthiness. Historically, **fewer than 10%** of applicants are accepted, and the onboarding is reportedly a months-long process.

The load-bearing difference is not the acceptance rate. It is that SRT members are **contracted talent, not random pseudonyms**. U.S. members are paid as **1099 independent contractors** (non-U.S. members via a W-8BEN), earning from missions, valid submissions, patch verification, and mentoring. Synack continuously monitors members' online behavior and removes them when warranted. This is the closed, vetted crowd that government and heavily regulated enterprises buy, and it is expensive precisely because vetting that hard collapses the funnel.

That trade is the whole point. Heavy vetting is a tax on your pool, your speed, and your budget. Over-vetting a public marketing site is as much a mismatch as under-vetting a payments core. Which is why the answer is never "vet maximally," it is "vet to scope."

## The four-tier vetting ladder, and how to pick yours

**How much should you vet bug bounty researchers?** Match vetting rigor to the sensitivity of what is in scope, using four tiers: (1) **badge-only intake**, where anyone can report and no identity is required, for public, low-sensitivity assets; (2) **ID-verified payouts**, where reporting is pseudonymous but identity, tax, and sanctions KYC are required before payment, the mainstream default; (3) **trust-gated private**, where reputation earns an invitation and ID verification is mandatory; and (4) **background-checked or contracted**, with criminal screening and named, contracted testers for crown-jewel, regulated, or classified scope.

Here is the ladder as an operational decision table.

| Tier | Who can report | Vetting before access | Vetting before payout | Best fit |
|---|---|---|---|---|
| **0: Badge-only intake (VDP)** | Anyone | None | None or payout-KYC only | Public, low-sensitivity assets; marketing sites; "see something, say something" |
| **1: ID-verified payouts** | Anyone (pseudonymous) | None | Identity + tax + sanctions KYC | The mainstream default for a SaaS with real but not crown-jewel data |
| **2: Trust-gated private** | Invited, reputation-earned | Mandatory ID verification | Full payout-KYC | Sensitive data; you want a curated, known-identity pool |
| **3: Background-checked / contracted** | Screened, contracted testers | Criminal background check and/or 1099 contract | Contractual | Crown-jewel, regulated (fintech/health), or classified scope |

Read the table by blast radius, not by prestige. Ask one question per asset: if a bad actor operated inside this scope, how bad is the worst credible day? A pseudonymous reporter poking your public docs site is a Tier 0 problem. A stranger with a path toward your production payments core is not, and no bounty payout is worth skipping identity there.

Two practical notes. First, most startups run **more than one tier at once**: a broad Tier 1 public program for the perimeter and a Tier 2 or 3 invite for anything near sensitive data. Second, tiers are a progression, not a life sentence. A researcher who reports well at Tier 1 is exactly who you promote into your Tier 2 private pool. Reputation is how good-faith strangers earn their way toward trust.

## What vetting has to do with staying legal: the Sullivan lesson

Here is the part founders miss. Vetting is not only a security control; it is how you prove, after the fact, that a given actor was operating inside an authorized scope. And in 2026 that proof carries real legal weight.

In *United States v. Sullivan*, the Ninth Circuit (opinion filed **March 13, 2025**) affirmed the conviction of Uber's former chief security officer and held that under the Computer Fraud and Abuse Act (CFAA), "without authorization" is judged **at the moment of access**. Post-hoc paperwork, in that case an NDA dressed up as a bug bounty, **cannot retroactively cleanse** access that was unauthorized when it happened. The underlying facts are a cautionary tale on their own: a 2016 breach exposed data on 57 million users and 600,000 driver's-license numbers, with a $100,000 payment routed through the bug-bounty program, and Sullivan was ultimately convicted of obstruction and misprision of a felony.

The lesson for a program owner is precise. Authorization has to be established **up front, in writing, and tied to a known party**. Light vetting does not create CFAA liability by itself, but it makes it harder to demonstrate later that a specific actor was inside a good-faith, authorized scope. Safe-harbor language plus knowing *who* your researcher is are the two halves of the same "was this access legitimate?" answer. This is why your scope document, safe-harbor terms, and your vetting tier are one decision, not three. (For the drafting side of that, see our guide to [safe harbor and legal threats to security researchers](/blog/safe-harbor-legal-threats-security-researchers-vdp), and the broader [EU Cyber Resilience Act disclosure mandate](/blog/eu-cyber-resilience-act-mandatory-vulnerability-disclosure) if you sell into Europe.)

None of this is legal advice. Kit gives you the place to put authorization and scope language; have counsel review the final policy text.

## Researcher vetting is contractor vetting by another name

The cleanest mental model a founder already has is the contractor one. An external researcher with a path to production access is the security equivalent of a contractor you are letting into your systems. And you almost certainly already scale contractor scrutiny by role sensitivity: a designer touching a Figma file gets a lighter check than an engineer with production credentials.

Apply the same graduated logic. Identity, reputation or references, and background checks scaled to what the person can reach maps almost one-to-one from your hiring policy onto researcher tiers. Treating "who can touch prod" as a deliberate policy decision, rather than an afterthought, is the entire discipline. It is also why identity fraud in the talent supply chain, like the wave of [North Korean IT worker hiring fraud](/blog/north-korean-it-worker-hiring-fraud), belongs in the same conversation: a fake contractor and a sanctioned pseudonymous "researcher" are the same KYC failure wearing different hats.

## Where crypto programs make the money lever obvious

Web3 programs surface the payment-KYC dial most sharply, because the payouts are large enough that the money question dominates. Immunefi does not require KYC by default; each project sets its own policy. When KYC is required, it is collected through Onfido **only once a bug report is confirmed valid**, right before a payout that can run into six or seven figures.

That is the entire principle in one sentence: **KYC gates the money, not the participation.** You can keep intake wide open and still refuse to move a single dollar until you know exactly who is receiving it and that you are legally allowed to pay them. Separating "can report" from "can be paid" is the design pattern, whether your bounties are $500 or $5 million.

## Standing up your chosen tier without enterprise overhead

Every incumbent has an incentive to push you toward *their* notch. The marketplaces sell light-and-scaled; Synack sells heavy-and-closed. Nobody neutral publishes a scope-driven "how much vetting does *your* program actually need" framework, then hands you the tooling to run whichever tier you pick. That gap is where Kit's CSIRT vertical sits.

Kit is self-hosted infrastructure, not a managed crowd. It does not supply vetted researchers the way Synack does. What it gives you is the controls to run any tier and to encode the trust decisions yourself:

- **Configure the program with scope and safe-harbor up front**, so "good faith" is defined *before* access, the Sullivan lesson made operational. Scope validation keeps reports inside the boundary you published.
- **Separate "can report" from "can be paid."** Researcher profiles and a ledgered payout flow let you keep intake open (Tier 0/1) while gating money behind identity and approval.
- **Run an earn-your-way-in trust journey.** Researcher karma and reputation signals let you promote strong Tier 1 reporters into a curated Tier 2 private scope.
- **Restrict a higher-assurance cohort.** Program-level access controls route sensitive, crown-jewel scope to a private, screened group (Tier 3).
- **Triage consistently regardless of who reported.** Standardized assessment, severity suggestions, and duplicate checks mean a pseudonym and a named contractor get the same rigorous handling.

Because Kit also owns a Hiring vertical, it is uniquely placed to treat researcher vetting as the external-hacker sibling of contractor background-check policy, one identity discipline across everyone who can touch your systems.

<div class="blog-inline-cta">
  <p><strong>Decide your vetting tier this afternoon, then stand up the program that enforces it.</strong> Kit's CSIRT module lets you configure scope, safe-harbor, researcher profiles, and a ledgered payout flow so identity and authorization are encoded from day one, not bolted on after an incident.</p>
  <p><a href="/users/sign_up">Start your free trial</a></p>
</div>

## A founder's day-one vetting checklist

Copy this, adjust for your scope, and you have a defensible starting position.

1. **Inventory scope by blast radius.** List every asset in your program and mark the worst credible day if a bad actor operated inside it. That mark is your tier.
2. **Default the perimeter to Tier 1.** Public, non-crown-jewel assets get pseudonymous reporting with identity, tax, and sanctions KYC before any payout.
3. **Ring-fence the crown jewels at Tier 2 or 3.** Anything near payments, PII, PHI, or infrastructure keys goes to an invite-only, ID-verified, or background-checked pool.
4. **Write authorization up front.** Publish scope and safe-harbor language before you invite anyone, and tie authorization to a known party. Have counsel review it.
5. **Gate the money, not the intake.** Never send a payout until identity, tax form, and sanctions screening clear. Record every approve, reduce, and decline in a ledger.
6. **Build a promotion path.** Let strong Tier 1 reporters earn their way into your private pool on reputation, so your trusted cohort grows from proven behavior.

Vetting is a dial. Set it to the sensitivity of what is in scope, encode identity and authorization tightly enough to survive a "was this access legitimate?" question, and you get the good-faith reporters without the legal exposure. Pick your notch, publish your terms, and run the program that enforces both. For the setup mechanics, start with [how to set up a vulnerability disclosure program](/blog/how-to-set-up-vulnerability-disclosure-program) and our take on [bug bounty reward tiers and researcher trust](/blog/bug-bounty-reward-tiers-researchers-trust-hackerone-cuts).