Would your vulnerability management hold at three o'clock on a Friday?

In 1973, two Berkeley planners put a name to the sort of problem that refuses to sit still long enough to be solved. Horst Rittel and Melvin Webber called it wicked: no stopping rule, no definitive formulation, no right to be wrong. Every attempt leaves a mark and there is no clean second go.

Vulnerability management fits the description. The flaws keep coming, the regulation now insists you keep looking for the entire life of the product, and "manage your vulnerabilities" means something different depending on whether the CRA, NIS2 or your own board is asking. Ship with a known exploitable flaw, miss the moment one of yours turns up in an exploit catalogue, and there is no quiet do-over.

That changes the question. A wicked problem has no state called "done". You cannot certify that an organisation has solved vulnerability management, because there is nothing to solve. You can assess how well it is set up to keep managing, across the products it ships and the years it is on the hook for. A compliance tick-box asks whether a document exists. An assessment asks whether the thing would hold at three o'clock on a Friday when the report lands.

That capacity breaks down into five parts: organisation, engineering, communication, analytics, and the discipline to keep it up over time. The breakdown holds regardless of which regulation is asking, which is what makes it a model rather than one text's checklist.

The regulation asking right now happens to be the CRA

It will not be the only one, and it is not the first. NIS2 already obliges a swathe of organisations to run coordinated disclosure and feed a vulnerability database at ENISA. The ISO standards for handling and disclosing vulnerabilities have described how to do this for years. Strip the regulation away entirely and a serious risk appetite asks the same five questions unprompted.

The CRA is the one with a date and teeth. A quick orientation, because the timeline trips people up:10 December 2024: the Regulation entered into force. 11 September 2026: the reporting obligations under Article 14 bite. Weeks away as I write this. 11 December 2027: the bulk of the remaining obligations apply.

Running underneath all of it, the part that catches organisations out: the duty does not expire at launch. Support runs for the product's expected lifetime, and for at least five years unless it is plainly meant for less. The obligation has a long tail, and the tail is where wickedness compounds. A product that outlives the support window nobody revisited is the "no stopping rule" turning up as an audit finding.What follows maps the five capabilities against what the CRA specifically demands, with a first move on each. Note where the standards predate the CRA. That is the point: the reference framework keeps shifting; the capability does not.

1. Organisation: governance, point of contact, regulatory responsibilities

Warm words from the board will not cut it. The text asks for three things in particular:

• a coordinated disclosure policy (CVD) that people actually follow;
• a point of contact nobody has to hunt for;
• a named person on the hook for dealing with the national CSIRT.

The failure mode is familiar. The policy sits in a wiki nobody outside security reads. The published address routes to a shared inbox three people half-watch. A report lands on a Friday evening, and "who owns the clock" becomes a Slack thread rather than an answer that was already written down.

Coordinated disclosure is not a CRA invention. NIS2 requires it, and ISO/IEC 29147 and 30111 have set out how to run intake and disclosure for years. The CRA made it enforceable on a date.

Start here: publish your point of contact (a security.txt file does the job nicely) and put a name, rather than a department, against regulatory reporting.

2. Engineering: intake, verification, remediation, lifecycle

Patching bugs as they crop up is not the same as being compliant. The standard needs:

• a software bill of materials (SBOM) a machine can read and keep current;
• an assurance that nothing known and exploitable is lurking when the product goes on sale;
• free security fixes users can apply on their own, without being bundled into a feature update.

An SBOM that lists direct dependencies and stops there looks complete right up until a transitive library surfaces in an advisory feed the tooling never scanned. The exploitable-at-shipping check hits the same wall: an assurance built on a partial inventory only covers the part you inventoried. This is also where a VEX (Vulnerability Exploitability eXchange) earns its keep. The SBOM tells you what is in the box; the VEX tells you what in the box can actually be reached and hurt you. Most teams do the first and skip the second.

Start here: generate a first SBOM in CycloneDX or SPDX, covering direct dependencies at the very least, and get honest about how far down it goes.

3. Communication: advisories, notification, the regulatory chain

This is the one with a hard deadline nailed to it. Every vulnerability you fix needs an advisory. Affected users have to be told when a flaw is being exploited. And the reporting line to the CSIRT and ENISA runs on a clock the CRA sets, not one you get to negotiate.

Awareness of active exploitation, then 24 hours to an early warning to the CSIRT and ENISA, then 72 hours to a full notification, then a final report 14 days after a corrective or mitigating measure is available. The urgent node is the 24-hour trigger, because that is where everything starts ticking.

The clock is a CRA-specific fact. The capability is knowing which node in that chain is yours to hit, and knowing it before the first report arrives rather than while it is arriving. The machinery that decides who talks to the researcher, who verifies the report and who signs off the advisory is a discipline in its own right, covered in our dedicated guidance.

Start here: draft your 24-hour early-warning template and run a dry test through it, so you already know who makes the call, who writes it up, and who hits send.

4. Analytics: measurement, trends, spotting exploitation

For most of these capabilities, solid is plenty. This one is different.

The regulation raises the bar: you have to be able to tell, more or less as it happens, that one of your flaws is being exploited in the wild, because that is the moment the 24-hour clock starts.In practice that means settling on a handful of signals in advance rather than improvising under fire. A CVE landing in a known-exploited catalogue such as CISA's KEV. A high exploitation-probability score. A structured way to decide what to act on and how fast. Building all of that from scratch, mid-incident, is the same problem in its cruellest possible form.

Start here: decide what actually counts as "exploited in the wild" in your world, and work out how that news is supposed to reach you before your customers do.

5. Keeping it up: reviews, testing, staying compliant over time

Compliance is not a launch-day formality you can then forget. It runs for the life of the product:

• testing and reviewing on a schedule you can point to;
• revisiting the risks across the whole support window;
• going back through conformity whenever the product changes in a meaningful way.

A support period set once at launch and never touched again tends to hold right up until the product quietly outlives it, still out in the field, no longer in anyone's review cycle.

Start here: pin down a support period for each product (the expected lifetime, and at least five years unless it is plainly meant for less) and set how often you will revisit it.

The five do not stand alone

List them out and they look like five boxes. They are wired together, and that wiring is where the damage happens.

Which is why assessing the five in isolation misses the point. The question is whether they hold as a chain, under load.

Log4Shell is a capability question

In December 2021, a single flaw in Log4j (CVE-2021-44228) put much of the software world on notice overnight. The library sat buried so deep in so many products that the first hard question was not "how do we fix it" but "are we even affected". Organisations without a current, transitive-aware SBOM burned days answering something a machine should have answered in minutes. Capability 2 collapsing into capability 4: no inventory, so no way to tell whether the flaw being hammered was one of yours.

The exploitation signal, meanwhile, was impossible to miss: mass scanning within hours. Play that against the Article 14 clock and you get the 24-hour trigger firing on a weekend, for a flaw you cannot yet confirm you ship, to be reported to a contact you may never have published. Every one of the five capabilities tested at once, at speed, by a single CVE.

Log4Shell was a failure of readiness. Readiness is the thing you can only build before the report lands, and never conjure during it. That is precisely what a maturity assessment sets out to measure.

Where this leaves you

That is the shape of the model. The CRA is what makes it non-optional on a fixed date, but the same five capabilities hold whether the regulation in the room is NIS2 or nothing but your own appetite for risk. The goalposts will keep moving: harmonised standards are still being drafted, and the next directive is never far behind. The capability underneath is what stays put.

You will not finish this. Nobody does. What you can do is know, honestly and product by product, how well you are set up to keep coping. That is the assessment. And the graft of walking through it, question by question, is the part done alongside clients.