Clock-ready: Cyber Resilience Act vulnerability handling for a German industrial software maker, as AI-found reports surge

The situation

A German software company sold machine-monitoring software to manufacturers across Europe. Its product had two parts: an edge gateway installed on factory networks that collected data from machines, and a cloud application where customers viewed dashboards and alerts. Both were built on many open-source components. Security reports came in through a shared email address, were picked up by whichever engineer had time, and were tracked in the general bug tracker. Nobody could quickly say which customers ran which gateway release, or which releases contained a given library.

The product counted as a product with digital elements under the EU Cyber Resilience Act. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents, once, through ENISA's Single Reporting Platform, which passes them to the relevant national CSIRT and ENISA¹². The first step is an early warning within 24 hours of becoming aware of active exploitation, followed by a fuller notification and a final report². An email inbox and goodwill could not meet those deadlines reliably.

Why now. Vulnerability reports were getting more numerous and harder to judge. On 5 November 2026 OpenAI released GPT-6 Cyber, a model for authorised vulnerability research that it rates at its highest cybersecurity risk level³. OpenAI's own security leadership has said AI-generated reports are overwhelming some open-source maintainers⁴, and projects such as Debian have begun experimenting with AI-assisted triage to cope⁵. The company was seeing the same pattern at its own scale: more reports, some excellent, many duplicated or unreproducible.

What had to be true

• One way in: every report, from researchers, customers, suppliers or internal scanners, reaches one queue with an owner.
• Noise filtered cheaply, without letting a real vulnerability sit unread.
• Exposure answerable fast: for any component, which releases contain it and which customers run them.
• A consistent start to the clock: a written rule for when the company is "aware" of active exploitation.
• Fixes customers can trust: signed releases and advisories that say what to do.
• Evidence kept: who knew what, when, and what was reported.

Architecture

The core was a security case record, separate from the general bug tracker, with restricted access. Every report became a case with an owner, a status and a timeline. The build pipeline produced a CycloneDX SBOM for every gateway and cloud release, and the licensing system already knew which customer ran which gateway release, so joining the two gave a direct answer to "who is exposed?". When a vulnerable library was present but its vulnerable code was not reachable, the team published a VEX statement saying so, which cut down repeated questions from customers' scanners.

The data flow, end to end

The hard part: AI triage and the start of the clock

Treating reports as untrusted input. Using a language model to read incoming reports helped with volume, but reports are written by strangers, and some could contain instructions aimed at the model. The triage model therefore had no tools, no access to code or customer data, and only produced a structured summary: claimed component, claimed impact, duplicate candidates and missing information. It could not close a case. Anything it marked as low quality still had a person glance at it before closing. See prompt injection defence for agents.

Defining "aware". The 24-hour early warning runs from when the manufacturer becomes aware of active exploitation¹. A report that a flaw exists is not the same as evidence that someone is exploiting it. With the company's lawyers, we wrote a short rule: credible evidence of exploitation, such as a customer incident, a national CERT notice, a public exploit used in attacks or an entry in an exploited-vulnerability catalogue, starts the clock, and the on-call lead records the time and the evidence. Borderline cases went to a named second person within working hours, with a bias toward reporting early.

Shipping fixes to factories. Gateways sat on factory networks where customers controlled update timing. Signed releases, verifiable before installation, meant customers' operations teams could accept updates without a call to the vendor⁶. Advisories listed affected versions, the fixed version and a workaround for sites that could not update immediately.

How it ran

A tabletop exercise, run before any real case, walked through a mock exploited vulnerability from report to final submission. It found gaps that documents had hidden: who held access to the reporting platform at weekends, and which customer contacts were out of date.

Key decisions and trade-offs

What I'd do again, and differently

Again: build the release-to-customer map before anything else. It turned every later question from an investigation into a lookup. Differently: run the tabletop exercise in the first weeks, not after the process was written; it would have shaped the runbook rather than corrected it. Related: defender-first AI models and vulnerability management, AI model supply chain security, the 6 November tech news and the Europe page.

If you sell software or connected products in the EU and need to be ready for Cyber Resilience Act reporting, see my fractional CTO work, or analyse your challenge and bring the result to a call.