At 02:00 a link lands in a channel your product-security team watches. It points to a public GitHub gist: working proof-of-concept code against the web interface of one of your programmable controllers, an authentication bypass, a screenshot of a root shell. No email reached you first. No ninety-day clock counted down. A researcher you have never spoken to went straight to publication.
The reflex in the room is a cease-and-desist and a call to the platform's abuse team. Resist it. Under the Cyber Resilience Act, how you answer that gist is not a public-relations decision. It is evidence of whether you met a cybersecurity requirement you were already carrying, and the researcher who embarrassed you may be the only reason a fix ships before the exploit does.
The drop happens before you're ready, because you built no earlier door
The uncomfortable read on that midnight gist is short. If the researcher had nowhere obvious to send the bug, publication was the rational move, and part of the failure is yours.
The CRA closed that excuse. Two clauses of Annex I, Part II attach to every product with digital elements the moment it is placed on the market. Clause (5) requires the manufacturer to "put in place and enforce a policy on coordinated vulnerability disclosure." Clause (6) requires you to "take measures to facilitate the sharing of information about potential vulnerabilities," including "by providing a contact address for the reporting of the vulnerabilities discovered" in the product. Separately, Article 13(17) requires a "single point of contact to enable users to communicate directly and rapidly" with you, one that must let people choose how they reach you and cannot be a chatbot dead end.
Before any specific bug exists, then, the statute has already told you to publish a policy and staff a mailbox. A researcher who can find neither is not the villain of the story.
What coordinated vulnerability disclosure actually is
Coordinated vulnerability disclosure (CVD) is the process by which a manufacturer receives a vulnerability report from an outside finder, works a fix privately, and releases public details on a timeline agreed between them, so users can patch before attackers weaponize the flaw. It is a relationship with a clock, not a favor. The CRA does not invent the practice; it makes the manufacturer's half of it mandatory.
Two international standards define the mechanics: ISO/IEC 29147 (how to receive and publish disclosures) and ISO/IEC 30111 (how to triage and handle them internally). Neither is CRA law. They are the field's reference playbooks, and Europe's harmonized standards will eventually point to the same practices, but you comply with the regulation by meeting Annex I, not by citing an ISO number in a policy PDF.
Mandate versus good practice: keep the line clean
Legal counsel gets into trouble by promising the business that a
security.txt| What the CRA mandates | Where | Good practice, not law |
|---|---|---|
| A published CVD policy | Annex I Part II(5) | A |
| A contact address for reporting vulnerabilities | Annex I Part II(6) | Legal safe-harbor terms for good-faith researchers |
| A single, easily found point of contact | Art 13(17) | A paid bug-bounty program |
| Public disclosure of fixed vulnerabilities (with a delay lever) | Annex I Part II(4) | Following ISO/IEC 29147 and 30111 to the letter |
The right column is how you make the left column work. A safe-harbor promise costs nothing and turns adversaries into reporters; a
security.txtThe one lever that turns a zero-day into a managed fix
Coordination sounds like it depends on the researcher's goodwill. Legally, it rests on a single clause. Annex I, Part II(4) requires you to share and publicly disclose information about a fixed vulnerability once the update is available. Then it grants the exception that makes timing negotiable: "in duly justified cases, where manufacturers consider the security risks of publication to outweigh the security benefits, they may delay making public information regarding a fixed vulnerability until after users have been given the possibility to apply the relevant patch."
Read what that does and does not give you. It lets you hold back the public write-up of a fixed flaw until your operators have had a real chance to install the patch. That is the legal basis for asking a researcher to coordinate a release date. It does not let you sit on the fix, and it says nothing about silencing the finder. The window is measured from "once a security update has been made available," so the clock that matters is your own remediation speed, not the researcher's patience.
You cannot delay what is already public
Return to the 02:00 gist, where the details are already out. The delay lever in clause (4) is gone for that vulnerability; there is no non-public state left to protect. What remains is clause (2): "address and remediate vulnerabilities without delay, including by providing security updates." The posture flips from negotiating a date to shipping a patch and telling users how to protect themselves in the meantime.
If the flaw is being actively exploited, a second obligation lands on top: the 24-hour early-warning duty that starts in September 2026, a different clock with its own machinery (see the 24-hour early warning). The lesson for the relationship is blunt. The value of a good CVD channel is entirely front-loaded. It exists to make the private path more attractive than the gist, before anyone chooses.
Turning hostile into coordinated is your job, not the statute's
Be honest with the board about the limit of the law here. The CRA mandates the policy and the contact address. It does not hand you a script for talking to an angry twenty-three-year-old who is convinced your company ignored three emails.
That script is yours to write, and it is mostly restraint. Acknowledge receipt fast, in hours not weeks. Do not open with legal threats against good-faith research; a public safe-harbor statement, promising you will not pursue researchers who act in good faith and give you time to fix, is the highest-return sentence you can publish, and it is exactly the thing the statute leaves to you. Offer credit in the advisory if the finder wants it. Agree a disclosure date and hold to it, because the fastest way to manufacture your next zero-day drop is to miss the date you asked for.
The safe-harbor promise does not need lawyers to draft a treaty. Two sentences at your reporting address do the work:
We will not pursue legal action against researchers who report vulnerabilities in good faith, avoid privacy violations and service disruption, and give us reasonable time to remediate before public disclosure. Report to [contact address]; we will acknowledge within one business day and agree a coordinated disclosure date with you.
Publish that beside the contact your CVD policy already obliges you to staff, and the midnight gist becomes the exception rather than the default.
None of that is in Annex I. All of it decides whether the next researcher emails your contact address or opens a browser tab to GitHub.
The question Annex I leaves unanswered
The regulation is precise about your obligations and silent about the researcher's. You must build the policy, staff the contact, and disclose the fix. The finder owes you nothing: no notice, no embargo, no patience. The CRA can compel a manufacturer to open a door. It cannot compel anyone to walk through it instead of publishing.
So here is what the statute leaves sitting on the table, the thing your safe-harbor language is really trying to answer. When you have done everything Annex I asks, a findable policy, a staffed mailbox, a single point of contact that replies within the hour, and a researcher drops the zero-day anyway, what, if anything, was that researcher's duty to you?