Vulnerability coordination is a capability, not a mailbox

Most teams treat vulnerability coordination as an address: a security.txt file, an inbox, a line in the footer. The address is the easy part. What sits behind it, and whether it holds on the day a real report arrives, is the capability this piece is about.

[cvd]

The CRA turns this from good practice into an obligation

Until recently, standing this capability up was something mature vendors chose to do. The Cyber Resilience Act removes the choice. Under Regulation (EU) 2024/2847, a coordinated vulnerability disclosure policy is a mandatory product requirement under Annex I, Part II, and Article 14 puts the reporting side on a hard clock. The exact deadlines and the dates they start to bite sit on the tracker rather than being restated here. What matters for capability is that the clock starts when you become aware of a problem, not when you are ready to address it.

The reporting trigger is also narrower and stranger than it looks. It fires on an actively exploited vulnerability, one where there is reliable evidence that a malicious actor is using the flaw in the wild. A proof of concept, a researcher's demonstration, or even public disclosure does not, by itself, meet the bar. That looks like a narrowing in your favour, though in practice it tends to work the other way. Knowing that a CVE exists in your product is a vulnerability-tracking problem, and many teams can manage that with a feed and a spreadsheet. Knowing that it is being exploited is a threat-intelligence problem, and far fewer can.

You inherit vulnerabilities you never wrote

Then there is the part you did not author. Your real exposure lives largely in components you did not write, and you cannot report on a flaw in a dependency you did not know you had shipped. This is what makes a reliable inventory of what is inside the product the precondition for the whole exercise, rather than a documentation chore that comes after it.

It also pushes the problem upstream. If a supplier does not tell you that a component of theirs is being exploited, your clock can run out before you are even aware that there is a clock running. Getting that intelligence reliably usually means having notification arrangements with your suppliers, and most relationships established before the CRA do not include such arrangements.

The ground is still moving

None of this has settled into a stable shape. The harmonised standard that will define what compliant vulnerability handling looks like is still in development, and the single reporting platform is still being built as this is written. Preparing against mechanics that are still moving, for a deadline that is not, is part of the difficulty, and the time spent waiting for final templates is time the deadline does not give back.

Close reading of the regulation will not be what separates the teams that meet the window from those that miss it. That comes down to who stood the capability up before they needed it, and who did not try to do it alone.

Sources. Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 13, 14 and 16 and Annex I, Part II. ISO/IEC 29147:2018, Vulnerability disclosure. ISO/IEC 30111:2019, Vulnerability handling processes. European Commission, "Cyber Resilience Act — Reporting obligations". ENISA guidance on coordinated vulnerability disclosure. Last verified July 2026.

A vulnerability programme is invisible until the day it is tested. That day usually opens with a message from someone you have never spoken to, in a mailbox nobody was quite sure who owned, describing a flaw in a product you shipped two years ago. What happens in the next few hours tells you whether you have a capability or a hope.

Disclosure and handling are two different machines

Coordinated vulnerability disclosure is usually pictured as one thing. It is two, and conflating them is the first blind spot.

ISO/IEC 29147:2018 covers disclosure: the interface with the outside world. How you receive a report, how you talk to the researcher who sent it, how and when you inform users. ISO/IEC 30111:2019 covers handling: the internal work of verifying the report, judging its severity, developing and testing a fix. One is a conversation with a stranger. The other is a process running inside your organisation.

A programme that has the disclosure half without the handling half acknowledges reports it cannot act on. A programme with the handling half and no disclosure half fixes things quietly while the researcher, losing patience, goes public on their own timeline. Both halves have to exist, and they have to be wired to each other.

The front door is a human problem

The disclosure side, the 29147 half, is more a human problem than a technical one. It needs an intake channel a researcher can actually find and a human actually answers, an acknowledgement that lands before the researcher concludes they are being ignored, and then the harder part, a relationship carried through the awkward middle: the embargo, the disclosure timeline, the disagreement over severity, the moment the reporter wants to publish and the fix is not ready.

Handled well, the coordinating authority becomes an ally in containment and the researcher a collaborator. Handled badly, the same set of facts becomes a public account of an organisation that could not get out of its own way. Legal and communications are in this from the first hour rather than summoned at the end.

The handling side runs on wiring a policy cannot describe

The 30111 half is internal, and it looks like paperwork only until a report arrives that starts a clock. What matters then is whether the report reaches whoever can judge it in hours rather than days, whether coverage holds through the weekends and holidays when reports tend to surface, and whether the path from triage to a tested fix is one people have walked before. None of that assembles itself under time pressure.

Why this rarely survives being done on the side

Seen whole, the problem has a clear shape, and so does the reason it seldom survives being built on the side of a desk. It is a standing capability rather than a document: something that spans engineering, product security, legal, communications and leadership, runs without pause, and still competes for attention with the thirty other things a team is already behind on.

The individual pieces are learnable. The difficulty is that the subtleties, what counts as exploitation, how a reporter relationship holds under time pressure, how to know with confidence what is inside your own products, are exactly the places a well-intentioned solo effort quietly breaks. And it breaks at the moment of the first real report, which is the worst possible moment to find the gap.

Direct link to this note →