The CRA requirement that obliges manufacturers to notify authorities when a vulnerability is actively exploited or a severe incident occurs. In practice, it turns product security triage into a time-bound reporting process that depends on evidence, scope, and escalation discipline.
What Article 14 Reporting Obligation Means in Practice
Article 14 turns product security into a reporting duty, not just a remediation duty. Once a vulnerability is actively exploited or a severe incident occurs, the manufacturer must recognize that the clock has started and that internal triage now has an external accountability deadline.
The practical meaning is that evidence quality matters as much as speed. Teams need a defensible way to determine whether the issue meets the reporting threshold, because the obligation is triggered by severity and exploitation status, not by whether the product team has finished its own investigation.
Why the Obligation Exists
Article 14 exists to reduce the gap between discovery and authority notification when harm is already plausible or underway. The reporting requirement is part of the EU Cyber Resilience Act, which treats vulnerability handling as a lifecycle security issue rather than a one-time release concern.
The logic is simple: if a vulnerability is being exploited in the wild, or if a severe incident has occurred, regulators and affected stakeholders need timely visibility. That shifts the emphasis from purely technical patching to coordinated disclosure, escalation, and traceable decision-making.
What Must Be Judged Before Reporting
The hard part is deciding whether the event crosses the reporting threshold. A manufacturer has to distinguish a normal vulnerability report from an actively exploited weakness, and a routine incident from one that is severe enough to trigger the obligation.
That assessment usually depends on scope, impact, and confidence in the evidence. If the organization cannot show how it reached its conclusion, it risks either under-reporting a reportable event or over-reporting a case that did not meet the threshold, both of which weaken trust in the process.
How Article 14 Changes Product Security Operations
Article 14 effectively makes triage, logging, and escalation part of product security governance. The team handling a vulnerability needs clear ownership, fast internal routing, and a reporting path that can survive scrutiny after the fact.
For organisations that build connected or software-enabled products, this is a reminder that security operations do not end at fix deployment. The reporting obligation sits alongside secure development, vulnerability intake, and incident response, so the organisation can explain not only what it did, but when it knew, what it concluded, and why it acted the way it did.
Risk and Threat Considerations
Article 14 creates exposure when organizations delay classification, lack evidence, or treat reporting as an afterthought. The main risk is not only regulatory non-compliance, but also the operational blind spot that appears when exploitation is happening faster than the reporting workflow can keep up.
Failure mechanism: Weak triage discipline, incomplete telemetry, or unclear escalation paths can cause a reportable exploitation event to be misclassified, missed, or reported too late.
Impact: Delayed notification can undermine regulator trust, slow coordinated response, and leave the manufacturer exposed to compounding security and compliance consequences.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while EU Cyber Resilience Act and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU Cyber Resilience Act | Cyber Resilience Act reporting obligation | Article 14 is a reporting duty under the CRA for exploited vulnerabilities and severe incidents |
| Recommendation — Build a reporting workflow that classifies reportable exploits quickly and notifies authorities within the required timeline. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | Timely reporting depends on detection and visibility into exploitation and severe incidents |
| RS.CO-02 — Incidents Are Reported Consistent with Established Criteria | Article 14 is fundamentally a criteria-driven reporting decision after a qualifying security event | |
| Recommendation — Strengthen monitoring so exploitation evidence reaches incident triage before reporting deadlines are missed. Define reporting criteria and route qualifying product-security events through a formal notification process. | ||
| NIST SP 800-53 Rev 5 | IR-6 — Incident Reporting | The obligation is a structured notification requirement driven by incident severity and exploitation status |
| Recommendation — Document when a product security event becomes reportable and require timely escalation to responsible authorities. | ||
| ISO/IEC 27001:2022 | A.5.24 — Information security incident management planning and preparation | Article 14 depends on prepared incident handling and notification procedures |
| Recommendation — Prepare incident handling procedures that preserve evidence and support external reporting decisions. | ||
Practitioner Guidance
Why practitioners should care: Article 14 is less about writing a report and more about proving that the organisation can make a fast, defensible judgment under pressure. That means the reporting workflow has to be integrated with vulnerability management and incident response, not kept as a separate legal formality.
Common misunderstanding: Teams often assume the trigger is only a confirmed breach. In practice, the threshold can be reached by active exploitation or a severe incident even when root cause analysis is still underway, so waiting for complete certainty can be the wrong instinct.
Practitioner takeaway: The safest operating model is one that can escalate early, preserve evidence, and produce a clear timeline for why the obligation was, or was not, activated.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org