Permission Is Not Participation: Building a Sustainable Security Researcher Ecosystem

A researcher is unlikely to build a durable relationship with a programme when basic questions remain unclear:

• What may I test?
• Which methods are prohibited?
• Where do I report?
• What happens after submission?
• Will good-faith conduct be treated proportionately?
• How long will the organisation remain silent?
• Will I ever learn whether the issue was actually fixed?

ENISA's work on the economics of vulnerability disclosure describes researcher motivation as multi-factor: profit, prestige and career value, challenge and learning, and ethical or ideological motivations.1

The same work identifies barriers including:

• fear of hostility or punishment;
• legal uncertainty;
• lack of an appropriate reporting avenue;
• insufficient or slow communication from vendors or coordinators.1

So the system is not:

It is closer to:

Even that is not a guarantee.

Researcher attention cannot be legislated into existence.

From the organisation's perspective, CVD may look like an intake workflow.

From the researcher's perspective, the first report is an experiment in whether the relationship is worth continuing.

It quickly answers practical questions:

• Did anyone read the report?
• Did the triager understand the technical issue?
• Was obvious evidence treated fairly?
• Did the programme meet its own response expectations?
• Was the researcher kept informed?
• Were decisions explainable?
• Did closure demonstrate that the work mattered?

A poor answer creates a rational outcome:

I will spend my next research cycle somewhere else.

That is researcher attrition.

No amount of carefully written policy fully compensates for repeatedly bad operational experience.

Before paying rewards, the programme should first be a place where a competent researcher can operate predictably.

In my 2026 working model for researcher participation, I describe this as friction reduction.

It includes:

• clear scope;
• permitted and prohibited methods;
• a predictable reporting route;
• rapid acknowledgement;
• understandable triage;
• meaningful status communication;
• clear disclosure rules;
• understandable duplicate handling;
• traceable policy versions;
• proportionate treatment of good-faith mistakes.

The order matters.

A chaotic programme with a bounty can become an expensive chaotic programme.

Researchers compare programmes.

That makes reputation a genuine allocation signal for scarce research time.

YesWeHack's 2026 survey included 245 hunters. Sixty-eight percent selected programme reputation — including prompt and fair report handling and payment — as a major factor when choosing programmes. High bounty ranges were selected by 51%, private-programme invitations by 50%, and recently added scope by 42%.3

This is a survey of one platform's population, not a representative census of all vulnerability researchers.

The result is still useful for programme design:

Researchers choose not only a target. They choose the organisation they will have to deal with after they find something.

Triage quality and communication are therefore not merely support functions.

They affect whether researcher attention arrives at all.

A programme does not need to pretend that a difficult vulnerability can be analysed in an hour.

It does need to communicate state.

Compare:

Report received. Case 1234. Technical validation is in progress. Next update in three business days.

with:

twenty-seven days of silence.

Researchers generally do not need false certainty.

They need process visibility.

Useful states include:

• received;
• under technical review;
• clarification requested;
• validated;
• duplicate;
• remediation in progress;
• retest requested;
• resolved;
• disclosure pending.

That is why acknowledgement and closure feedback are separate lifecycle controls in Coordinated Vulnerability Disclosure in Practice.

Money is not the only form of value.

Recognition can provide:

• verifiable evidence of work;
• professional reputation;
• portfolio value;
• stronger future programme access;
• career credibility;
• proof that the contribution did not disappear into a private queue.

Recognition mechanisms can include:

• Hall of Fame;
• researcher profiles;
• CVE/EUVD credit where appropriate;
• acknowledgement in an advisory;
• certificates or letters of appreciation;
• professional references;
• special recognition for sustained high-quality contribution.

The UK's NCSC has used both HackerOne reputation points and physical Challenge Coins to thank researchers contributing valid reports through its vulnerability-reporting service.6

A challenge coin does not magically cause good vulnerability research.

The more important lesson is that a public authority can treat researcher recognition as a distinct ecosystem tool.

Latvia's current CERT.LV vulnerability-reporting platform provides a concrete implementation.

The platform terms state that information about reports submitted by each researcher is available in the researcher's platform profile.7

Monetary reward is not automatic in the national CVD process. It applies when the resource owner has explicitly included bounty terms in its own programme.8

Separately, CERT.LV states that researchers with confirmed medium-, high- or critical-impact reports may receive:

• a letter of appreciation;
• and/or recognition awards.8

The FAQ also states that, at the researcher's request, CERT.LV can prepare a PDF letter of appreciation within 30 days.8

This is a useful example of participation architecture that is broader than bounty:

Those are distinct tools.

There is an important boundary.

If a programme promises money for a qualifying finding, it should not later replace that obligation with:

We will put your name in our Hall of Fame.

Recognition is valuable when it is:

• genuine;
• predictable;
• proportionate;
• useful to the researcher.

It is not a universal substitute for compensation.

Financial and non-financial incentives can coexist.

Participation can also create future capability.

A programme can give researchers access to:

• more complex scopes;
• private invitations;
• specialist campaigns;
• cyber ranges;
• mentoring;
• meaningful technical feedback;
• collaborative research;
• grants or funded research in suitable contexts.

This creates a different ecosystem effect.

The programme is not merely consuming existing expertise.

It can increase the future supply of expertise.

At national scale, that becomes a cybersecurity-capacity question.

A researcher with a history of:

• valid reports;
• scope discipline;
• careful data handling;
• coordinated disclosure;
• reproducible evidence

may reasonably be trusted with more sensitive opportunities.

For example:

But this progression model should not mutate into:

No certificate, no right to report.

The ability to submit a vulnerability and the privilege to perform higher-risk testing are separate.

Reputation is evidence of history.

It is not a professional licence and not proof that a new finding is true.

Bug bounty is powerful, but not universal.

Money can:

• attract attention;
• compensate opportunity cost;
• support professional researchers;
• direct effort toward selected assets;
• make sustained security research economically viable.

But bounty requires operational preparation.

Before opening one, an organisation needs:

• current scope;
• triage capacity;
• remediation owners;
• incident escalation;
• clear reward rules;
• duplicate rules;
• budget;
• dispute handling;
• payment operations.

Without those controls, the financial incentive can increase submission volume faster than the organisation can process the resulting security work.

For that design problem, see Bug Bounty & Crowdsourced Security: What a Good Programme Actually Optimises.

A programme can announce:

500 hackers participated this year.

That may sound impressive.

For long-term programme health, another question may be more revealing:

How many useful researchers returned?

Returning researchers accumulate system-specific knowledge:

HackerOne's 2026 analytics explicitly separate participation measures including unique researchers, active researchers, valid submissions and returning hackers versus submissions.45

That is one platform's analytics model, not a universal industry standard.

The underlying point remains useful:

Researcher participation is a programme resource that can be observed over time.

Over-optimising for known researchers also has costs.

It can:

• make entry difficult for new talent;
• create reputational lock-in;
• reduce diversity of techniques;
• privilege familiar hunting styles.

A healthy programme therefore needs both:

New researchers need a fair way to establish credibility.

Experienced researchers need a reason to continue growing with the programme.

A strong response can teach the researcher something.

For example:

Your SSRF finding was valid, but the demonstrated impact was limited by egress controls. During remediation we found a variant in another worker class and moved the outbound restriction into a shared policy.

That feedback has professional value.

It also demonstrates that the organisation understood the finding rather than merely changing a status field.

This can strengthen trust.

But technical feedback is not a substitute for a promised bounty.

Researchers often receive:

Thanks, fixed.

Better closure can communicate:

• validated status;
• root cause remediated;
• affected version or deployment fixed;
• retest result;
• disclosure state;
• credit decision.

That creates visible causality:

my work changed a real system.

For researchers motivated partly by public benefit, that matters.

Duplicates are normal.

They become corrosive when:

• the organisation cannot substantiate an earlier report;
• the issue has remained unfixed for a very long time;
• the new report actually identifies a different root cause;
• no explanation is given;
• “duplicate” becomes a convenient reward-avoidance category.

A defensible policy explains:

• what counts as the same root cause;
• what counts as the same fix;
• how variants are treated;
• what happens to long-unresolved duplicates;
• how disputes are handled.

Fairness affects future participation.

Research communities exchange experience.

Programmes acquire reputations such as:

• they never respond;
• they always downrate severity;
• payouts are slow;
• reports are closed without explanation;
• triage is technically strong;
• decisions are fair;
• it is worth returning.

A written policy can be excellent.

The lived programme reputation can be different.

Ecosystem management therefore has to measure not only what the organisation says, but what the researcher experiences.

Two stereotypes are common.

The first:

A real ethical hacker should not care about money.

The second:

Researchers participate only for bounty.

Both are simplistic.

ENISA's analysis describes motivation as multi-factor.1

The same person can participate:

• for money in one programme;
• for reputation in another;
• for public benefit in a third;
• for technical challenge in a fourth.

Programme design does not need to discover the researcher's “true” motivation.

It needs to avoid pretending that one motivation applies to everyone.

I would retain a simple model.

1. Friction reduction

Make participation unnecessarily difficult as little as possible.

2. Recognition

Give high-quality contributions verifiable professional value.

3. Progression

Allow demonstrated quality to open more advanced scopes and development opportunities.

4. Financial incentive

Where appropriate, compensate researcher time and security value monetarily.

These are not four mandatory sequential maturity levels.

Not every CVD programme needs a bounty.

Not every researcher wants public credit.

Not every asset should support private progression.

But a policy that stops at “you may report” leaves much of participation dynamics undesigned.

I would look beyond raw report count.

Useful signals include:

• unique researchers;
• returning researchers;
• first-valid-report to second-valid-report conversion;
• acknowledgement time;
• triage time;
• percentage receiving closure feedback;
• valid-report ratio;
• duplicate ratio;
• out-of-scope ratio;
• dispute rate;
• researcher-initiated withdrawal;
• recognition uptake;
• private-invite acceptance;
• payment timeliness where bounty exists;
• recurring root-cause rate;
• direct researcher feedback about programme quality.

One particularly useful signal may be:

It should not become the single KPI.

It is one indicator of whether the relationship is functioning.

Participation analytics can be overused.

Reducing every researcher to one ranking score can:

• penalise difficult low-volume research;
• structurally disadvantage newcomers;
• turn early mistakes into lasting reputational debt;
• incentivise submission volume for ranking purposes.

Engagement metrics should primarily measure programme health.

Not human worth.

ENISA's 2022 CVD work recommended developing incentives for active researcher participation, including possible national or European bug-bounty programmes and cybersecurity training.2

That does not imply that every Member State needs one central bounty fund.

National participation policy can combine:

• legal clarity;
• national CVD coordination;
• researcher recognition;
• profiles or contribution history;
• training;
• cyber ranges;
• targeted public pilots;
• organisation-specific bounties;
• private or vetted programmes for higher-risk environments.

Latvia's CERT.LV platform already implements several pieces of this architecture.78

The next policy question therefore does not have to be:

When will the state pay every researcher a bounty?

A better question can be:

How do we create a clear, safe and professionally valuable path from a researcher's first report to sustained high-quality participation?

I would model it like this:

A researcher can leave at every transition.

A bounty affects only part of the journey.

The right to report vulnerabilities matters.

A safe CVD route matters.

Legal clarity matters.

None of those things automatically creates an active security-research community.

Participation becomes more likely when researchers encounter:

• clear rules;
• professional communication;
• technically fair decisions;
• demonstrable security impact;
• reputation or development value;
• and, where offered, fair financial compensation.

The long-term CVD question is therefore not only:

Do we allow the researcher to knock on the door?

It is:

What happens after they knock — and will the experience make them want to return?

Permission opens the door.

Participation determines whether an ecosystem forms behind it.

Sources checked on 25 September 2026. The four-layer participation architecture, researcher-journey model and proposed retention metrics are the author's analytical framework. They develop the principle in the author's 2026 working paper Researcher Participation and Incentive Model: a legally clear ability to report is necessary, but is not always sufficient for regular, high-quality independent researcher participation.

This article analyses CVD ecosystem and researcher-participation design. It does not promise legal protection or reward under any particular programme.