Do You Need a Bug Bounty Program? Start With PSIRT Maturity

Maybe you have a quote from a managed bug bounty platform on your desk. It arrived because someone read that the Cyber Resilience Act (or some other impending regulation) requires a coordinated vulnerability disclosure program or because a researcher reached your company the hard way last quarter and a quick search led you to various platform options.

Many organizations equate 'coordinated vulnerability disclosure' to 'bug bounty' or some resemblance of public recognitions and rewards. These two are not the same thing, however, and one strongly depends on the other. If your vulnerability management process is mature, can handle volume, and your organization is ready for a more publicly advertised vulnerability disclosure program, then a managed platform may be the next step. In most cases, however, a managed platform should be the last purchase in a disclosure program, not the first.

There is a basic vulnerability handling maturity that must exist first, and a coordinated vulnerability disclosure program can, in some cases, be as simple as having a dedicated email and some pre-approved communication templates from legal.

FIRST, the Forum of Incident Response and Security Teams, publishes a PSIRT Maturity Document that describes three levels of maturity for a product security incident response team (PSIRT), and it is the place to learn more about each one. FIRST's three levels, taken in order, show where a managed platform fits.

FIRST PSIRT Level 1: the CVD policy and contact address the CRA requires

FIRST's PSIRT Level 1 is a place for researchers to send reports and a process for answering them, and it covers the two CRA requirements that put the quote on your desk in the first place: a coordinated vulnerability disclosure policy and a contact address. FIRST calls this level Basic, under the heading "The Beginning is a very fine place to start." A PSIRT at this level takes in and reviews vulnerability reports, then works with the teams who own the affected product to produce a security update. It answers finders from prepared communication templates and acknowledges the people who reported.

In the CRA, those two requirements are points (5) and (6) of Annex I Part II: a policy on coordinated vulnerability disclosure, and a contact address for reporting vulnerabilities in the product. Article 14 is a separate duty that has applied since 11 September 2026, under which manufacturers notify actively exploited vulnerabilities and severe incidents to their designated CSIRT and to ENISA. Whether a given product falls under the CRA at all is decided product by product, which we worked through in CRA reporting starts September 11, 2026.

The address itself is small. RFC 9116 defines a security.txt file served at /.well-known/security.txt, so a researcher or an automated tool finds your contact without navigating your site. The file points to a dedicated email address, ideally published with a PGP key for encrypted reports, and every report that arrives there becomes a ticket with a named owner.

Most of the work sits behind the address, and it has to exist before anyone can safely answer a researcher's first email. The company needs a written procedure with response timelines and pre-approved message templates, along with rules on what an employee may say to an outsider. It also needs technical controls on that inbox, because a researcher's proof-of-concept attachment is itself an inbound attack vector. None of these pieces is the security team's call alone: each needs legal and PR at the table, with leadership behind them. How far legal safe harbor extends and what the company says in public stay with your own legal and communications teams.

A manufacturer with a large product portfolio found out what a missing address costs. A researcher found a vulnerability in one of its products and could not find anyone to tell: the website listed no security contact, and a LinkedIn search for plausible titles turned up nobody. The researcher reported it to CISA, and CISA contacted the company's leadership directly. We had just started building that company's product monitoring process and that incident validated a lot of the work we were doing by starting at the policy and process level, maturing internally before joining a platform. Had a large influx of reports come in, they would have had serious problems. The end state was an email address and a reporting form on every company website, both feeding a ticket tracker where each report had an owner. This was easy and matched their current capabilities.

After that intake went live, reports did not measurably increase. A form on your own website has no distribution, because nobody browses a manufacturer's security page looking for work, and the researchers who were going to examine your product are already examining it. The address changes where their findings land, which is why it costs almost nothing to publish and still contributes greatly to compliance efforts.

FIRST PSIRT Level 2: knowing which products a report touches

FIRST's PSIRT Level 2 is where a team learns what it ships, because a report is only useful once you know which products it touches. FIRST calls this level Intermediate, under the heading "I am reactive, but I've trained for it!" A PSIRT at this level accepts reports and invests in a product manifest or bill of materials, so the team knows what to watch. The CRA asks for overlapping work in point (1) of Annex I Part II, which requires manufacturers to identify and document vulnerabilities and components contained in their products, including by drawing up a software bill of materials covering at least the top-level dependencies.

This level is where most outside bug-bounty platforms struggles. Without knowing your product architecture, it has great difficulty judging whether a reported vulnerability applies to you. For product security in embedded systems, an outside platform often equates more to spam filtering, because it only has a high-level understanding of the product.

In fact, many internal security teams do not hold that architectural knowledge yet either. Ask one how a single library is used across several components, or which components ship in which models, and few can answer from records they already hold.

That gap becomes the hardest part of a disclosure program, and it shows up while stress testing the vulnerability handling process. A researcher tells you what they could do to one product, and the engineering team then has to find every other product carrying the same issue. The deeper the supply chain, the more difficult the search becomes.

FIRST PSIRT Level 3: where a managed bug bounty platform starts to pay

FIRST's PSIRT Level 3 is where a managed bug bounty platform pays off, because the team works proactively and can absorb the extra reports a platform brings. FIRST calls this level Advanced, under the heading "Proactive...we're ready for anything (mostly)." A PSIRT at this level manages security risk in third-party components and actively monitors outside sources, such as social media and conference papers, for vulnerability reports. It also knows the researchers who work in its area, and some of them have a track record that earns their reports priority.

What a managed platform sells is distribution. It markets your program to a standing pool of researchers who already hold credibility and awards on the platform, so it generates inbound reports your own website never would. Choosing a platform is choosing to ask for more reports, and a Level 3 team is the one that can use them, since it already watches outside sources and its manifest tells it quickly which products a new report affects. Before that point, the same contract mostly buys reports your team cannot yet triage.

FIRST's document does not mention bug bounties. Placing the platform at Level 3 is our reading of the path and why we opt for simpler solutions (such as form inputs directly into VSEC Core or self-building a simple email pipeline with existing vulnerability tracking) unless there is already a strong foundation of cybersecurity vulnerability management currently existing.

Two questions that tell you whether you need a bug bounty program

Two questions place your program on FIRST's PSIRT maturity levels, and the answers tell you whether the quote on your desk has arrived early.

The first tests Level 1. If you spent five minutes on your company's website as an outsider, could you work out how to report a security concern in one of your products? If you could not, neither can a researcher with a finding, and that report will keep traveling until somebody listens: a regulator, a customer or a conference audience.

The second tests Level 2. If a researcher reports a vulnerability in one specific version of a component, could your team name every product and model that ships that version by the end of the day?

The second one is much trickier and while we think we've built a great foundation achieve this in our own product -- VSEC, the viability of any solution will depend on the development pipeline of you and your suppliers.

If either answer is no, build that level before you sign anything. If both are yes, the foundation is in place, and the platform earns its price once your team also watches outside sources for reports and wants more than your own address brings in. To work out which level your program sits at and what the next one takes, talk to us about your disclosure program and the last report that reached you the hard way.

‍