EU Cyber Resilience Act Article 14: Navigating Mandatory Vulnerability Reporting Requirements for Enterprise PSIRTs

BRUSSELS — On September 11, 2026, the European Union’s regulatory regime for digital products crossed an uncompromising threshold. Under Article 14 of Regulation (EU) 2024/2847, known as the Cyber Resilience Act (CRA), manufacturers and software publishers commercializing connected hardware and software in the EU must comply with a statutory mandate to report actively exploited vulnerabilities and severe security incidents within 24 hours.

While full CRA conformity assessments, technical design mandates under Annex I, and CE marking rules do not take effect until December 11, 2027, the European Parliament and Council intentionally staggered the timeline. IoT manufacturers face a related but distinct September deadline, covered in CRA 2026 compliance for IoT and the market-access reporting deadline. By activating Article 14 precisely 21 months after the regulation entered into force on December 10, 2024, European lawmakers created a 15-month advance window where reporting obligations precede product certification. This mandate applies to all products with digital elements (PDEs) made available on the EU single market, including legacy software and connected devices actively supported or commercialized in the bloc.

For Product Security Incident Response Teams (PSIRTs) and enterprise compliance architects, this statutory timeline eliminates any margin for error. Engineering leaders cannot wait for their 2027 CE marking readiness initiatives to overhaul their vulnerability intake, triage, and disclosure operations.

Defining an Actively Exploited Vulnerability

The statutory threshold of Article 14 hinges on explicit evidentiary criteria rather than internal engineering confirmations. Under Article 3, point (42) of the CRA, an actively exploited vulnerability is defined as:

"a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner."

The legal trigger for notification under Article 14(1) occurs the moment a manufacturer becomes aware of this condition. Regulators and national computer security incident response teams (CSIRTs) do not require organizations to finish a comprehensive root-cause analysis (RCA), isolate the offending lines of code, or synthesize a reproduction exploit before the reporting clock starts.

Reliable evidence encompasses corroborated telemetry:

• Live indicators of compromise (IoCs) detected in customer production networks or enterprise endpoint fleets.
• Malicious exploit payloads identified in edge sensors or honeypots specifically targeting the vendor’s software component.
• Confirmed inclusion of the vulnerability in verified threat advisories or active catalogs, such as CISA’s Known Exploited Vulnerabilities (KEV) list. CISA's KEV catalog drives similar urgency in the US, as seen when an actively exploited Ivanti Connect Secure flaw was added to KEV.

Conversely, Recital 68 clarifies that authorized security testing under Coordinated Vulnerability Disclosure (CVD) frameworks, penetration tests, and private bug bounty programs does not constitute unauthorized exploitation. Similarly, theoretical academic papers, fuzzing discoveries, and internal static analysis findings without in-the-wild exploitation do not trigger the statutory clock.

The Three-Stage Reporting Cadence

Article 14 establishes an accelerated, cascading notification framework that bifurcates between actively exploited flaws and severe operational security incidents.

Stage 1: Early Warning (Within 24 Hours)

Within 24 hours of becoming aware of active exploitation, the manufacturer must file an initial notice. The submission must state whether the vulnerability appears to stem from malicious or unlawful acts and indicate whether the issue carries potential cross-border repercussions across EU Member States.

Stage 2: Technical Notification (Within 72 Hours)

Within 72 hours of initial awareness—not 72 hours after the early warning—the manufacturer must provide a detailed technical assessment. This submission must supply available severity ratings using standardized metrics (such as CVSS and EPSS), describe technical impact, detail indicators of compromise, and outline any immediate workarounds or interim mitigating steps advised for end users.

Stage 3: Final Report (Within 14 Days of Mitigation)

The final stage closes the regulatory loop no later than 14 days after a corrective measure, firmware update, or security patch becomes available. This filing requires a technical post-mortem, permanent remediation details, a root-cause breakdown categorized by Common Weakness Enumeration (CWE), and definitive remediation instructions.

For severe incidents impacting the security of a product—such as the compromise of an over-the-air update server or a code-signing pipeline—the reporting cadence follows the same 24-hour and 72-hour progression, but sets the final report deadline at one month following the 72-hour notice.

Architecture of the Article 16 Single Reporting Platform

To prevent manufacturers from navigating 27 separate national notification portals, Article 16 tasks the European Union Agency for Cybersecurity (ENISA) with developing and securing a centralized Single Reporting Platform (SRP).

The SRP functions as a unified gateway. When a manufacturer submits an early warning or technical report, the filer's Assigned Representative selects the CSIRT designated as coordinator under Article 14(7), and the notification reaches that CSIRT and ENISA at the same time:

1. The coordinator CSIRT is the one in the EU Member State where the manufacturer has its main establishment (or where its designated EU Authorized Representative is located under Article 22).
2. ENISA receives the same filing for centralized European situational awareness.

The coordinator CSIRT then passes the notification on to the other relevant CSIRTs. Article 16(2) allows that onward sharing to be delayed in sensitive cases.

Update (2026-10-05): The platform is now live. ENISA says the SRP opened on 11 September 2026 as an initial operating capability at portal.cra-srp.enisa.europa.eu. At launch it accepts Article 14 mandatory notifications only, covering actively exploited vulnerabilities and severe incidents. Voluntary reporting under Article 15 is planned for a later phase. ENISA's FAQ says no API will be provided in the initial release: notifications must be submitted through the platform interface, and an API "may be considered" in a future phase with no committed date. Organisations may still automate their internal reporting workflows; only the submission itself is manual. The interface is English-only, with supporting materials to be translated progressively. The European Commission published implementation guidance on 27 July 2026, with the reporting obligations detailed in its Section 9.1.

What PSIRTs need to do now:

• Every Assigned Representative needs a personal EU Login account with multi-factor authentication. One Primary Assigned Representative per manufacturer registers on the SRP, selects the coordinator CSIRT and invites up to 20 Secondary representatives; the coordinator CSIRT validates the association.
• If the SRP is unavailable, you may contact the coordinator CSIRT directly, but you must still file through the SRP once it is back.
• Open-source stewards have their own Article 24(3) obligations from 11 December 2027.

Source: ENISA SRP frequently asked questions (FAQ updated 3 October 2026).

Re-engineering PSIRT Playbooks and Reconciling CVD

The 24-hour reporting mandate fundamentally conflicts with traditional Coordinated Vulnerability Disclosure frameworks defined by ISO/IEC 29147 and ISO/IEC 30111, which routinely rely on 60-to-90-day embargoes while engineering validates a patch. Under CRA Article 14, state entities must be notified of active zero-day exploitation long before a patch exists.

To prevent the government platform from becoming an espionage target, Articles 14(6) through 14(8) establish strict confidentiality rules, empowering coordinating CSIRTs to delay downstream technical dissemination across the CSIRTs Network if early sharing would prematurely expose an unmitigated flaw. Concurrently, enterprise legal teams must update bug bounty policies and researcher non-disclosure agreements with explicit regulatory compliance carve-outs, confirming that mandatory disclosures to ENISA and national CSIRTs do not breach confidentiality covenants.

{
 "event_type": "vulnerability_intake",
 "policy_check": "CRA_ARTICLE_14",
 "in_the_wild_exploitation_confirmed": true,
 "system_owner_permission": false,
 "statutory_clock_active": true,
 "sla_hours": 24,
 "routing_action": "TRIGGER_STAGE_1_EARLY_WARNING",
 "dispatch_target": "ENISA_SRP_GATEWAY"
}

Global organizations must also distinguish CRA Article 14 from other reporting regimes, such as the U.S. SEC’s four-business-day Form 8-K disclosure rule for material cybersecurity incidents and CISA’s CIRCIA critical infrastructure framework. It also overlaps operationally with NIS2's technical control requirements under EU Regulation 2024/2690. Unlike those regimes, which focus on corporate financial impact or domestic infrastructure resilience, the CRA is strictly a product-level regulation: it governs security flaws distributed to third parties even when the vendor's own enterprise networks remain entirely uncompromised.

Sanctions, Liability, and Operational Readiness

Non-compliance with Article 14 triggers severe administrative fines under Article 64 of the CRA. Failure to meet the 24-hour notification window exposes manufacturers to Tier 1 penalties of up to €15,000,000 or 2.5% of total worldwide annual turnover, whichever is higher. Furthermore, Articles 61 through 63 empower national Market Surveillance Authorities to prohibit non-compliant products from the European market, order withdrawals, or mandate public hardware recalls. Delayed disclosures also create contractual breach exposure with enterprise customers whose own compliance under the NIS 2 Directive and the Digital Operational Resilience Act (DORA) depends directly on receiving timely upstream vulnerability notices. DORA carries its own personal-liability teeth for boards, detailed in DORA board liability audits across the EU.

To ensure ongoing operational compliance, enterprise security organizations should execute four core engineering initiatives:

1. Automate Threat Telemetry Ingestion: Connect endpoint detection, production crash logs, and external threat feeds directly into PSIRT case management, establishing automated triggers that flag actively exploited flaws under mandatory Article 14 response SLAs. Automating that intake at scale is exactly the challenge covered in AI-automated vulnerability orchestration in open source clearinghouses.
2. Operationalize Dynamic SBOM Pipelines: Maintain comprehensive, machine-readable Software Bills of Materials in CycloneDX or SPDX formats across all commercial product lines to identify affected software components within hours of zero-day discovery.
3. Deploy Pre-Approved Notification Templates: Maintain pre-authorized disclosure templates for Stage 1 Early Warnings and Stage 2 Technical Notifications, supported by a 24/7 on-call rotation of legal and engineering decision-makers.
4. Formalize European Representation: Non-EU manufacturers must establish formal agreements with designated EU Authorized Representatives under Article 22, ensuring validated legal and technical channels to interface with coordinating national CSIRTs and the ENISA platform.

Related reading

• Anthropic Implements Global Token Watermarking to Meet EU AI Act Article 50 Mandate
• CVE-2026-16232: Hardening Check Point SmartConsole Planes
• Blueprint for Defense: Securing Third-Party Data Exchange Portals After the Stadler Rail Breach