CRA reporting pressure exposes gaps in product vulnerability governance

At a glance

What this is: ArmorCode argues that CRA compliance for products with digital elements depends on moving from ad hoc vulnerability handling to classified, time-bound, evidence-backed disclosure workflows.

Why it matters: This matters because product security, supply chain governance, and identity-linked components all need a provable reporting path when vulnerabilities become actively exploited.

Context

The core governance problem is not whether a vulnerability exists, but whether an organisation can prove what product it affects, how serious it is, and whether it has met the legal reporting deadline. Under the CRA, vulnerability management becomes a regulated workflow with evidence, timestamps, and product-level accountability rather than an informal security process.

That shift matters for teams managing software, hardware, connected devices, and identity-adjacent products because the regulation expects classification, disclosure, and lifecycle evidence to be linked to specific products and sub-products. The article’s posture is typical of a modern compliance transition: security teams must operationalise controls that were previously scattered across ticketing, spreadsheets, and email threads.

Key questions

Q: What breaks when CRA reporting is handled with spreadsheets and email chains?

A: Manual workflows usually break at the points CRA cares about most: deadline calculation, ownership assignment, and evidence retention. Spreadsheets may track status, but they rarely enforce who approved a decision, when a notice was sent, or whether the affected product was correctly classified. That creates a compliance gap even when the security team acts quickly.

Q: Why does exploit-aware prioritisation matter under the Cyber Resilience Act?

A: Because the CRA is about reportable risk, not abstract vulnerability count. A flaw that is actively exploited or clearly exploitable in the product’s environment can trigger urgent disclosure and remediation duties, so teams need intelligence that shows what is truly weaponised, not just what scores high.

Q: How do teams know whether CRA disclosure controls are working?

A: Look for measurable signs that the organisation can move from detection to notification without manual stitching between tools. If product scope, deadline tracking, owner assignment, and evidence capture all happen in one workflow, the control is operating. If any of those steps rely on ad hoc follow-up, it is not reliable enough.

Q: Which matters more for CRA readiness, product classification or SBOM accuracy?

A: They are complementary, but product classification usually comes first because it tells you what obligations apply. SBOM accuracy then becomes essential for proving which components are affected and for supporting VEX decisions. A team that has one without the other may know the parts list but still fail to answer regulator questions quickly.

Technical breakdown

How CRA product classification changes vulnerability governance

The CRA forces organisations to classify Products with Digital Elements by risk and lifecycle status before they can govern reporting properly. That classification is not just taxonomy. It determines which products fall into tighter disclosure, documentation, and conformity expectations, and it creates the basis for linking a vulnerability to the affected product and sub-product. Without a product inventory that is accurate enough for regulatory use, triage becomes guesswork and reporting becomes inconsistent across teams and tools. This is a governance problem as much as a security one, because the reportable unit is the product, not the finding alone.

Practical implication: maintain a product and sub-product inventory that can support regulatory classification and reporting at the point of triage.

Why exploit-aware prioritisation matters more than CVSS alone

The article’s prioritisation model reflects a basic operational reality: severity scores do not tell you whether a vulnerability is actively being used in the wild. CRA reporting obligations depend on exploitation status, so teams need to combine CVSS with EPSS, known exploited intelligence, asset context, and business impact to decide what moves first. This is especially important where a lower-scoring issue is already weaponised and therefore legally reportable. The mechanism here is not just enrichment; it is decision-making under deadline pressure, where the wrong ordering creates both security and compliance failure.

Practical implication: enrich vulnerability triage with exploit intelligence so response queues follow real-world exploitation, not score alone.

How disclosure workflows become auditable control systems

CRA reporting turns disclosure into a managed sequence: early warning, vulnerability notification, final report, and user disclosure when corrective measures become available. Each stage needs deadlines, status tracking, and evidence that can be shown to regulators or auditors. That requires a workflow system that records who reviewed the finding, when it was escalated, what was disclosed, and which exception or approval path was used. In practice, the control is the chain of evidence, not just the email or ticket that started the process. Organisations that cannot reconstruct that chain will struggle to demonstrate compliance even if they did some of the right work.

Practical implication: implement audit trails and deadline tracking that preserve the disclosure sequence end to end.

Threat narrative

Attacker objective: The attacker’s objective is to exploit a product vulnerability before the manufacturer can complete legally required reporting and response steps, extending exposure and pressure on the vendor.

1. Entry occurs when an actively exploited vulnerability is discovered in a product with digital elements that is already in market circulation.
2. Escalation follows when the organisation cannot quickly map the issue to the right product, classify its severity in context, and route it into the CRA reporting workflow.
3. Impact is a missed or poorly evidenced notification path that exposes the manufacturer to compliance failure, delayed remediation, and weak regulator-facing proof.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
• United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CRA reporting is converting vulnerability management from a security workflow into a provable governance system. Once a reportable vulnerability is tied to legal deadlines, teams need product classification, traceability, and evidence quality that can survive external scrutiny. That is a different operating model from traditional ticket-driven remediation, and it will expose weak ownership boundaries fast. Practitioners should treat reporting readiness as a governance capability, not a documentation exercise.

Exploit-aware prioritisation is the right control shift for regulated product security. CVSS alone cannot tell a manufacturer whether a flaw is now reportable, time-bound, and business-critical. The article correctly centres exploit intelligence, product context, and lifecycle status because those factors determine what gets escalated first. Practitioners should anchor triage to real exploitation signals rather than static severity labels.

Disclosure latency is the hidden failure mode CRA will surface. Many programmes can find vulnerabilities, but fewer can move from discovery to early warning to final report without losing time or evidence. That gap is especially visible when product, security, and compliance teams still operate in separate systems. Practitioners should measure whether disclosure workflows are actually executable under deadline, not merely documented.

Product-level accountability now extends to security-relevant supply chain dependencies. SBOM and VEX handling are no longer optional reference artefacts when a manufacturer must explain what is affected, what is not, and why. This is particularly relevant for identity systems, connected devices, and other products where a component issue can cascade across customers. Practitioners should make component traceability part of regulatory readiness, not an afterthought.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Identity Security Regulatory Map

What this signals

CRA readiness will expose whether product security teams can operate at compliance speed. The hardest part is not finding vulnerabilities but proving, under deadline pressure, which product they belong to and whether the disclosure clock has started. Teams that still separate vulnerability data, product inventory, and reporting evidence will find the process brittle as soon as an issue is actively exploited.

Product-level traceability is becoming a governance requirement, not a nice-to-have control. Where a product includes software components, connected services, or identity-relevant functions, teams need to know exactly what changed, what is affected, and what evidence supports the decision. That is where CRA readiness intersects with NHI governance, software supply chain visibility, and operational auditability.

For practitioners

• Map products to CRA classifications Build and maintain a product and sub-product inventory that supports Default, Important Class I, Important Class II, and Critical classification before disclosure duties begin.
• Prioritise exploited vulnerabilities by context Use EPSS, KEV, asset exposure, and business impact together so actively exploited findings rise above high-CVSS issues that are not yet weaponised.
• Automate the CRA disclosure workflow Track early warning, 72-hour notification, final report, and user disclosure as discrete workflow states with timestamps, owners, and escalation triggers.
• Link SBOM and VEX to the affected product Correlate component data to the exact product version so teams can prove what is affected, what is excluded, and what evidence supports that decision.
• Preserve an immutable audit trail Record review decisions, exception approvals, disclosure events, and remediation actions in a system that can be exported for regulatory inspection.

Key takeaways

• CRA reporting turns vulnerability management into a formal governance workflow with evidence, timestamps, and product-level accountability.
• Exploit-aware prioritisation matters because legal reporting obligations depend on whether a vulnerability is actively exploited or likely to be weaponised.
• Organisations that cannot classify products, trace components, and preserve disclosure evidence will struggle to meet CRA deadlines consistently.

Key terms

• Product with digital elements: A product with digital elements is any hardware or software product that contains or depends on digital components and is placed on the market. Under the CRA, the phrase matters because it determines whether security, documentation, and lifecycle obligations apply across development and maintenance.
• Exploit-Weighted Prioritisation: Exploit-weighted prioritisation is the practice of ranking remediation work by whether a vulnerability is actively exploited, not just by technical severity. It combines external threat signals, fix availability, and asset exposure so teams can reduce real attacker opportunity first.
• Vulnerability Disclosure Workflow: A vulnerability disclosure workflow is the set of roles, rules, and communication steps used to receive, verify, and act on security reports. Strong workflows reduce ambiguity, preserve researcher trust, and help organisations move from finding receipt to remediation without losing context.
• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.