CRA Vulnerability Management: Building a 24-Hour Reporting Program for Manufacturers

Introduction

Since September 11, 2026, manufacturers selling connected products in the EU face a live 24-hour reporting clock under CRA Article 14. That makes CRA vulnerability management an operational challenge, not a future planning item. If you learn a vulnerability in one of your components is being actively exploited,, can you file an early warning within 24 hours? If the answer is no, the reason usually isn’t a lack of scanning tools. It’s a lack of scoping speed.

Manufacturing is the most-attacked industry according to IBM X-Force’s 2026 threat intelligence report (IBM X-Force 2026). The Cyber Resilience Act doesn’t ask whether you can find vulnerabilities. It asks whether you can detect exploitation, scope which products and versions are affected, and report through ENISA’s Single Reporting Platform within hours. That’s a different problem, and it requires a different program.

This article covers what changed on September 11, why the 24-hour clock breaks traditional vulnerability management, and how to build a CRA vulnerability management program that makes reporting a byproduct of your remediation work rather than a separate, frantic exercise.

What Changed on September 11: CRA Article 14 in Plain Terms

The CRA’s vulnerability and incident reporting obligations became enforceable on September 11, 2026. Under Article 14, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents affecting product security to ENISA’s Single Reporting Platform. The regulation sets three reporting deadlines, and the first two run from when you become aware of an actively exploited vulnerability in your product or a qualifying severe incident.     .

The first clock is 24 hours for an early warning. This isn’t a full report. It’s a notification that something is happening, with whatever facts you have. The second clock is 72 hours for a notification, which adds more detail about the vulnerability, affected products, and potential impact. The third is the final report. For an actively exploited vulnerability, it is due no later than 14 days after a corrective or mitigating measure is available, and it documents the vulnerability, any known malicious actors, and the fix. For a severe incident, it is due within one month of the 72-hour notification. Because the vulnerability deadline depends on when a fix exists, remediation speed shapes the entire reporting timeline.

Scope and Stakes

The reporting obligation applies to in-scope products already on the EU market since September 11, 2026. You don’t need to retroactively report exploitation that was known before that date. But if a vulnerability in a product you shipped three years ago is exploited today, the clock starts now.

SBOM obligations follow on December 11, 2027, giving manufacturers time to build the component inventories they need. Fines under Article 64 can reach EUR 15 million or 2.5 percent of global annual turnover, whichever is higher (European Commission).

Why a 24-Hour Clock Breaks Traditional Vulnerability Management

Traditional vulnerability management is built around weekly or monthly scan cycles, CVSS-sorted backlogs, and manual scoping. None of that works when you have 24 hours to file an early warning and 72 hours to produce a detailed notification. The problem isn’t the scanning. It’s everything that has to happen between the scan and the report.

Long-Lived Products, Many Versions

A manufacturer may ship a product line for a decade, with hundreds of firmware versions across different hardware revisions. A vulnerable open-source component may appear in some versions and not others, depending on when it was introduced and when it was patched. When an exploitation signal arrives, the first question isn’t ‘how bad is it?’ but ‘which of our products contain this component, and in which versions?’ For most teams, answering that question requires searching through firmware repositories, SBOMs, and supplier documentation that live in different systems maintained by different people. That scoping exercise alone can consume most of the 24-hour window.

Exploitation Signals, Not Severity Scores

Article 14 triggers on active exploitation, not on CVSS severity. A CVSS 6.5 vulnerability with a public exploit and CISA KEV inclusion is more urgent than a CVSS 9.8 with no exploitation evidence. But most vulnerability backlogs are sorted by CVSS score, which means exploited mediums are buried beneath unexploited highs. CISA KEV and EPSS provide exploitation probability and known-exploitation signals that should drive triage order. We have written about this in more detail: Vulnerability Risk Scoring: Why CVSS Alone Is Not Enough.

Findings Scattered Across Tools and Teams

Manufacturers typically run firmware scanners, software composition analysis tools, penetration tests, PSIRT intake channels, and supplier advisory feeds. Each produces findings. Few share an owner or a common record. When an exploitation signal arrives, the team responding needs to check all of these sources to understand whether the vulnerability has been seen before, whether it was triaged, and whether any version scoping has already been done. The fragmentation is what makes the 24-hour clock unrealistic for programs that haven’t unified their findings.

The Building Blocks of a CRA Vulnerability Management Program

Building a program that meets the 24-hour clock requires three structural changes. Each one addresses a specific bottleneck that traditional vulnerability management leaves unresolved. ArmorCode’s agentic control plane for Unified Exposure Management provides the foundation, connecting findings, product versions, and remediation status through the Context Risk Graph. Its Risk-Based Vulnerability Management (RBVM), Application Security Posture Management (ASPM), and Software Supply Chain Security capabilities support the CRA compliance use case.

One Exploitation-Aware Backlog

ArmorCode’s RBVM unifies findings from your existing tools into a single backlog, so when an exploitation signal arrives, you aren’t searching across five systems. Adaptive Risk Scoring combines ArmorCode Advanced Threat Intelligence (AATI), EPSS, CISA KEV, and reachability data to surface exploited vulnerabilities at the top of the queue, not buried by CVSS sorting. When the 24-hour clock starts, the findings that matter are already visible and prioritized. Across its platform, ArmorCode reports alert volume cut by up to 90 percent (ArmorCode).

Version-Aware Composite SBOMs

The scoping problem is fundamentally an SBOM problem. You need to know which components are in which product versions, and you need that mapping to be current. Composite SBOMs map components to specific shipped product versions, so when a component vulnerability is exploited, the answer to ‘are we affected, and where’ takes minutes instead of a week of searching. The Anya Agents Zero-Day Exposure Hunting Agent answers that question directly, grounded in the Context Risk Graph, without requiring a new scan. End-of-life component tracking adds another layer, flagging components that are no longer maintained so you know which versions carry unfixable risk.

VEX and Ownership

Vulnerability Exploitability eXchange (VEX) statements document whether a product is affected or not affected by a specific vulnerability. VEX isn’t mandated by the CRA, but it’s the mechanism manufacturers use to communicate status to customers and users. Without VEX, every customer who hears about a vulnerability contacts your PSIRT independently. With VEX, the status is published once. Ownership mapping ensures that when a finding touches a product, the right product team receives it. ArmorCode’s ownership mapping routes fixes to the team that owns the affected product version, not to a generic security queue.

Running the Clock: From Signal to Final Report

Here is what a reporting cycle looks like when the program is in place. This is an operational walkthrough a PSIRT lead could use for a tabletop exercise.

Hours 0 to 72: Detect, Scope, Assess

The signal arrives. It may come from CISA KEV, a supplier advisory, an internal detection, or a researcher report. Within the first hours, you need three things: the affected versions, the owner, and the early warning facts. The exploitation-aware backlog surfaces the finding immediately. The composite SBOM answers version scoping in minutes. The Anya Agents Finding Overview Agent summarizes what’s known, and the Risk Analyzer Agent assesses exploitability and business impact, both grounded in the Context Risk Graph. These agents are bounded and human-led, meaning they accelerate the assessment but don’t replace the human decision. With those inputs, the 24-hour early warning and the 72-hour notification become achievable, not aspirational.

Through the Final Report: Remediate and Verify

Once the early warning and notification are filed, the focus shifts to remediation and verification. SLA tracking ensures the fix stays on schedule. Closed-loop verification confirms the vulnerability is resolved in the affected product versions. The Decision Trail serves as the record for the final report, documenting what was found, how it was scoped, what was fixed, and how the fix was verified. At a global equipment manufacturer, this approach accelerated remediation by 97 percent, from 240 days to hours (ArmorCode). Across its platform, ArmorCode also reports security tech debt burn-down of 80 percent or more (ArmorCode).

Readiness Checklist

Before the first real exploitation event tests your program, run through this checklist to confirm you can meet the clock.

• Confirm your CSIRT route and ENISA Single Reporting Platform registration. Know where the report goes and who files it before the clock starts.
• Baseline components by product version. Your composite SBOM should cover every shipped product line, with EOL components flagged.
• Add exploitation intelligence to triage. EPSS, CISA KEV, and AATI should drive prioritization order, not CVSS alone.
• Run a 24-hour tabletop. Simulate an exploitation signal and walk through the full reporting cycle from detection to final report. Measure where the bottlenecks are and fix them before the real thing.

How ArmorCode Supports CRA Vulnerability Management

ArmorCode’s agentic control plane for Unified Exposure Management, built on the Context Risk Graph and powered by Anya Agents, connects the building blocks into a program that makes CRA reporting a byproduct of daily vulnerability management. ArmorCode supports the preparation of CRA reports; your team still files them through the ENISA Single Reporting Platform.

Unified Finding Aggregation and Exploitation-Aware Triage

ArmorCode integrates with 400+ security tools and has processed 400 billion findings, aggregating them into one backlog. Adaptive Risk Scoring surfaces exploited vulnerabilities first using CISA KEV, EPSS, AATI, and reachability data. When the 24-hour clock starts, the findings that matter are already at the top of the queue.

Version-Aware SBOM Scoping with Anya Agents

Composite SBOMs map components to shipped product versions. The Zero-Day Exposure Hunting Agent answers ‘are we affected, and where’ in minutes, grounded in the Context Risk Graph, without requiring a new scan. EOL component tracking flags versions that carry unfixable risk.

The Decision Trail for Final Reports

The Decision Trail records every finding, decision, owner, fix, and verification step, producing the evidence needed for the final report as a byproduct of remediation work. SLA tracking ensures fixes stay on schedule, and closed-loop verification confirms resolution before the report is filed.

Conclusion

The CRA’s 24-hour reporting clock is a vulnerability management problem before it’s a reporting problem. If your program can detect exploitation, scope affected versions in minutes, and record fixes as they happen, the reporting becomes a query, not a project. If it can’t, no amount of template preparation will help you meet the deadline.

The building blocks are straightforward: one exploitation-aware backlog, version-aware composite SBOMs, VEX statements for customer communication, and ownership routing that puts fixes in the right hands. The operational walkthrough from signal to final report is the same whether you’re running a tabletop or responding to a real event. The difference is whether your program is ready before the clock starts or scrambling after it does.

See how ArmorCode turns CRA reporting into a byproduct of your vulnerability management program. Request a demo to see version-aware SBOM scoping and exploitation-aware triage in action.

Key Takeaways

• Since September 11, 2026, manufacturers selling connected products in the EU face a live 24-hour reporting clock under CRA Article 14 for actively exploited vulnerabilities.
• The 24-hour deadline breaks traditional vulnerability management because it requires knowing which product versions are affected within hours, not weeks, of an exploitation signal.
• Version-aware SBOMs and exploitation-aware triage, not CVSS severity alone, are the building blocks of a CRA-ready program.
• Remediation was accelerated by 97 percent, from 240 days to hours, at a global equipment manufacturer using ArmorCode (ArmorCode).