Coordinated vulnerability disclosure for small teams: why, safe harbour, the first 24 hours, and what not to promise

Sooner or later someone outside your company will find a security flaw in your product: a student, a hobbyist with a logic analyser, a professional researcher, a customer's security team. What happens next depends on whether you gave them a door to knock on. This guide is for a one- or two-person hardware team that has never run a disclosure process: why the policy exists, what "safe harbour" means, what to do in the first day, and what not to promise. It is a documentation aid, not legal advice.

When you are ready to write the policy itself, our security.txt and disclosure policy tool drafts both. This guide explains the thinking behind them, not their text.

Why a disclosure policy exists

The Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) makes it a duty. Annex I, Part II(5) says manufacturers shall "put in place and enforce a policy on coordinated vulnerability disclosure". Annex I, Part II(6) adds measures to make it easy to tell you about vulnerabilities, "including by providing a contact address for the reporting of the vulnerabilities". Article 13(8) requires policies and procedures to process and fix vulnerabilities "reported from internal or external sources".

The idea behind the duty is in recital 76 (recitals explain the articles; they do not impose duties of their own): the policy should set out "a structured process through which vulnerabilities are reported to a manufacturer in a manner allowing the manufacturer to diagnose and remedy such vulnerabilities before detailed vulnerability information is disclosed to third parties or to the public."

That last part is the practical reason, law or no law. A researcher who finds a flaw has several choices: tell you, tell a national authority, publish it, or say nothing. "Coordinated" means you and the finder agree on when the details go public, so a fix can exist first. Without a published route, finders guess. CERT/CC's guide to coordinated vulnerability disclosure warns that if reporters are kept out of the loop, "they may seek out a third-party coordinator or even publish their report without notice."

A small team gains the most from this (argument). You have no security department to absorb a surprise publication; a report that reaches you first, with time attached, is the cheapest way to learn about a flaw.

The other door: your national CSIRT

You are not the only place a report can go. Under the NIS2 Directive (Directive (EU) 2022/2555), Article 12(1), every Member State designates a CSIRT (a national computer security incident response team) "as a coordinator for the purposes of coordinated vulnerability disclosure". It acts "as a trusted intermediary" between the reporter and the manufacturer, can negotiate disclosure timelines, and must let people report anonymously. CRA recital 76 expects manufacturers' policies to allow reports "either directly to the manufacturer or indirectly, and where requested anonymously, via CSIRTs designated as coordinators".

So a researcher who does not trust you, or cannot reach you, has a route that ends at your door anyway, with a public authority in the conversation. Better that they use yours.

What safe harbour buys a researcher, and you

Finding a vulnerability often means doing something a lawyer could describe as unauthorised access or circumventing a protection. Researchers know this. ENISA's 2022 study of disclosure policies in the EU found that "in most EU countries, the legal framework has not been updated to provide for researchers' legal protections", and that most Member States it consulted see criminal law as the most pressing legal challenge.

A safe harbour clause is your written promise not to use those laws against good-faith research. The open disclose.io terms put it as research being "authorized concerning any applicable anti-hacking laws", with a commitment that "we will not initiate or support legal action against you for accidental, good-faith violations of this policy", and a similar line for anti-circumvention laws.

What it buys the researcher: a reason to report rather than stay silent or publish anonymously. What it buys you (argument): more reports arriving at your address instead of on a conference stage, and a clear boundary, because the clause covers research done under your policy's rules, such as not touching other people's data and not degrading service.

Know its limit. The same terms say safe harbour "applies only to legal claims under the control of the organization participating in this policy, and that the policy does not bind independent third parties." You can promise what you will do; you cannot promise what a chip vendor, a cloud provider or a prosecutor will do. Write it that way.

The first 24 hours after a report

You do not need a fix in a day. You need to show the reporter they reached a human, and to find out whether the clock in Article 14 has started.

1. Acknowledge. CERT/CC notes that "an acknowledgement timeframe of 24-48 hours is common". A short reply that you have the report, who will handle it, and when you will next write is enough.
2. Ask about timing. CERT/CC calls expected disclosure timing "an important question to ask whenever a report is received." Ask whether the reporter plans to publish, and when.
3. Check whether it is being exploited. If there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission, it is an actively exploited vulnerability (Article 3(42)), and Article 14(1) and (2)(a) require an early warning to the CSIRT designated as coordinator and ENISA within 24 hours of you becoming aware of it. See our guide "Article 14, step by step".
4. Reproduce and scope it. Which products, which firmware versions, which hardware revisions. Your SBOM is where you find whether a third-party component is involved.
5. If the flaw is in someone else's component, tell them. Article 13(6) requires a manufacturer that identifies a vulnerability in an integrated component, open source included, to report it "to the person or entity manufacturing or maintaining the component".
6. Write down what you did and when. The timeline is your evidence later.

What not to promise

A fix date you cannot keep. Researchers commonly work to a disclosure deadline: Google's Project Zero gives vendors 90 days, or 7 days if a flaw is being exploited in the wild; CERT/CC's own default is 45 days. CERT/CC advises treating "policy-declared disclosure timeframes as the starting point of a negotiation process rather than a hard deadline". Publish a window you can meet with the people you have, say what happens if you need longer, and keep the reporter updated. A missed promise costs more trust than a modest one kept.

A bounty you will not pay. Recital 76 says manufacturers "should be able to use" incentive programmes, "so-called 'bug bounty programmes'". It does not require one. If you offer thanks or credit rather than money, say so.

Legal cover you do not control, as above.

Silence forever. Once a security update is out, Annex I, Part II(4) requires you to publicly disclose information about the fixed vulnerability, including its impact and severity. It allows a delay, in duly justified cases, until users have had the chance to apply the patch. Your policy should say that advisories will be published.

Where security.txt fits

security.txt (RFC 9116) is a small text file served at /.well-known/security.txt on your website, over HTTPS. It is how researchers find your door. It must contain a Contact line and an Expires line, and its Policy field "indicates a link to where the vulnerability disclosure policy is located." It is a voluntary IETF specification, published for information rather than as an Internet Standard, and not a CRA requirement in itself, but it is the usual way to publish the contact address that Annex I, Part II(6) asks for. Put the same address in your product documentation and on the product page.

A minimum setup for a team of two

1. A shared mailbox such as security@, read by both of you, never one person's inbox.
2. A one-page policy: what is covered, how to report, when you acknowledge, your disclosure window, safe harbour, and that advisories follow fixes.
3. A security.txt pointing at both.
4. A calendar reminder to renew the Expires date.
5. Your ENISA reporting accounts set up before you need them.

What is settled and what is not

Settled (evidence): the CRA duties in Annex I, Part II(4) to (6) and Article 13(6); the national CSIRT role in NIS2 Article 12; the RFC 9116 fields.

Not settled: how market surveillance authorities will judge whether a policy is "enforced", and what a reasonable disclosure window is, are not defined in the CRA. The timeframes above are common practice, not law. We update this guide when guidance appears.