An earlier piece set out the shape of the Cyber Resilience Act: two deadlines fifteen months apart, with reporting obligations arriving on 11 September 2026 and the essential requirements following in December 2027. One sentence in that piece deserves an article of its own — a manufacturer cannot report what it cannot detect.
That sentence is where most Article 14 non-compliance will sit. Not in late filings, not in badly written notifications, but in events that were never recognised as events at all.
"Becoming Aware" Is Something You Build
Article 14 attaches its timelines to the moment the manufacturer becomes aware of an actively exploited vulnerability or a severe incident. Twenty-four hours to an early warning, seventy-two to a full notification, fourteen days to a final report once a corrective measure exists.
Read quickly, "becoming aware" sounds like a limiting condition — a protection against being held responsible for what you could not have known. Read against the rest of the regulation, it is nothing of the kind. Article 13 requires manufacturers to exercise due diligence and to handle vulnerabilities effectively; Annex I requires a documented vulnerability handling process. Awareness is not treated as something that happens to a manufacturer. It is treated as a capability the manufacturer is expected to have built.
The practical consequence is uncomfortable. An organisation with no monitoring, no disclosure channel and no software inventory can operate for months with an actively exploited vulnerability in its products and never trigger a single reporting obligation — not because it is compliant, but because it has no mechanism for becoming aware. The absence of reports is not evidence of a clean record. In many cases it is evidence of a blind spot.
Four Routes In, Four Ways to Miss It
In practice, knowledge of a vulnerability reaches a manufacturer through four channels. Each has a distinct failure mode, and each fails quietly.
- A security researcher finds something and looks for somewhere to report it. If no disclosure contact is published, the finding goes to a mailing list, a conference talk, or nowhere. If a contact is published but unmonitored, the position is worse — the organisation has documented evidence that it was told.
- A customer or installer reports odd behaviour to the people they already deal with: sales, technical support, field service. Those routes are built for warranty claims and configuration questions. A security report entering them is triaged as a support ticket, which is to say it is not triaged at all.
- A component supplier issues an advisory on a module, chipset or library. Whether this reaches the right person depends entirely on whether notification obligations were written into the supply agreement, and on whether anyone maintains the distribution list.
- Internal monitoring matches published vulnerabilities against the organisation's own products. This is the only route the manufacturer fully controls, and it is impossible without a software bill of materials. No inventory, no matching.
Most manufacturers, assessed honestly, have partial coverage on one or two of these and nothing on the rest. That is not a compliance programme. It is a hope that a customer will shout loudly enough.
The Friday Afternoon Test
There is a straightforward way to find out where an organisation actually stands, and it takes an afternoon. Send a security report through the public contact route — the address on the website, the support form, whatever a researcher would realistically use — and time how long it takes to reach someone who could act on it.
The results are usually instructive. A report that takes four working days to reach an engineer has consumed the entire Article 14 window and most of the following one, and it has done so through a process everybody believed was working. No gap analysis produces that insight as efficiently, because the failure is not in any documented procedure. It is in the handover between them.
Run it on a Friday afternoon. The clock does not pause for weekends, shutdowns or annual leave, and a reporting process that only functions between nine and five on weekdays is a process with a known five-day failure window built into every calendar year.
Judgement Has to Precede the Incident
Detection is necessary but not sufficient. Once something has been detected, two judgements decide what happens next, and both are poor candidates for improvisation.
The first is whether the vulnerability is actively exploited. The threshold is narrow — reliable evidence of exploitation in a system without the owner's permission. Theoretical exploitability does not meet it and a published proof-of-concept does not meet it. The bar is genuinely high, which is helpful, but only to an organisation capable of judging where it sits against that bar under time pressure. Those criteria belong in a controlled document, written in advance, when nobody is under pressure.
The second is who decides. If declaring a reportable event requires a security lead, a quality manager and a commercial director to reach agreement, the organisation does not have a twenty-four hour process — it has a twenty-four hour aspiration. One named individual needs the authority to start the clock, with a named deputy, and both need to be reachable outside working hours. Most reporting failures are not technical. They are an absence of authority at the moment it is needed.
The Decision Not to Report Is Also a Record
Not every vulnerability is reportable, and the narrow trigger means most will not be. But a decision not to report is a regulatory decision, and it needs to look like one after the fact.
That means recording what was received, when it was received, what evidence was reviewed, and why the threshold was judged not to have been met. Manufacturers already do exactly this for safety incidents that do not meet vigilance reporting criteria — the discipline is familiar, only the subject matter is new. An organisation that can produce that record has a defensible position. One that simply has no record of the report at all does not.
Building the Detection Layer
Closing the gap is a sequence rather than a project, and the early steps cost attention rather than budget:
- Publish and monitor a coordinated vulnerability disclosure contact, and give it a named owner rather than a shared mailbox nobody is accountable for
- Establish a route by which security reports arriving through sales, support or field service are escalated immediately, and brief those teams on what a security report looks like
- Write vulnerability notification obligations into supply agreements at the next renewal, and maintain the internal distribution list they feed
- Build a software bill of materials covering at least top-level dependencies, and set a monitoring cadence against it with a named owner
- Document the criteria for active exploitation and severe incidents, and name the individual and deputy authorised to declare a reportable event
- Register on ENISA's single reporting platform, confirm the coordinating CSIRT, and have named users log in before there is any reason to
- Exercise the whole path once with a simulated report, against the clock, with the people who would really be involved
None of this requires specialist security tooling, and none of it depends on guidance yet to be published. It is process design, which is work most regulated manufacturers already know how to do.
Where This Leads
The detection layer is not only an Article 14 obligation. Everything arriving in December 2027 — the documented vulnerability handling process in Annex I, the SBOM in machine-readable format, the security updates across a defined support period — assumes the same foundation. An organisation that builds it now to meet the reporting obligation is not doing separate work. It is doing the first part of the 2027 work, fifteen months early, under considerably less pressure.
The organisations that find December 2027 difficult will be the ones who treated September 2026 as a date that passed without incident. For some of them, that will be true. For others, it will only have looked that way.
Ninety8 Compliance supports manufacturers in scoping their product portfolio against the CRA, building the vulnerability detection and reporting process Article 14 requires, and developing the SBOM, technical documentation and conformity evidence that follow — across the CRA, CE marking and the wider EU product compliance framework.