← Role Guides
SecurityCRA Role Guide

EU Cyber Resilience Act — Guide for PSIRT Manager

What the CRA means for your role, your team, and your day-to-day responsibilities.

The Product Security Incident Response Team is the organisational function most directly impacted by the CRA's mandatory reporting obligations. Article 14 requires manufacturers to notify ENISA and national CSIRTs of actively exploited vulnerabilities within strict deadlines, and to operate an accessible coordinated vulnerability disclosure policy. PSIRT managers must design processes that meet these obligations without disrupting engineering velocity or creating unnecessary legal exposure.

Your CRA responsibilities:

  • Operate a CRA-compliant coordinated vulnerability disclosure (CVD) policy and maintain a machine-readable contact method
  • Triage inbound vulnerability reports and classify severity using CVSS or equivalent
  • Manage Article 14 notification submissions to ENISA and the relevant national CSIRT within regulatory deadlines
  • Coordinate remediation timelines with engineering, legal, and communications teams
  • Author and publish CSAF-format security advisories for resolved vulnerabilities
  • Maintain records of all vulnerability reports, triage decisions, and disclosure timelines
  • Conduct post-incident reviews and feed lessons learned back into secure development practices
Security

The PSIRT's role under the CRA

The Cyber Resilience Act elevates coordinated vulnerability disclosure from a voluntary best practice to a legal obligation. Article 14 requires manufacturers to have a CVD policy in place, to accept vulnerability reports from third-party researchers, and to report actively exploited vulnerabilities to public authorities within defined timelines. The PSIRT is the organisational unit responsible for making this work in practice. Unlike traditional security teams whose work is largely internal, the CRA-era PSIRT operates at the intersection of engineering, legal, regulatory, and public communications — managing inbound reports, coordinating remediation, satisfying reporting obligations, and publishing advisories that give downstream users actionable information.

CRA reference:Article 14, Annex I Part II

Operating a CRA-compliant CVD process

Annex I Part II requires manufacturers to handle vulnerabilities in accordance with a documented CVD policy. The policy must specify how researchers can submit reports, what information is required, how the manufacturer will acknowledge receipt, and the expected timeline from report to disclosure. The security.txt standard (RFC 9116) provides a machine-readable way to publish this contact information at a discoverable URL (/.well-known/security.txt). The CVD policy should also address disclosure timelines — ENISA's guidance suggests 90 days as a reasonable default before coordinated disclosure — and the circumstances under which the manufacturer will deviate from that timeline. Records of all inbound reports, triage decisions, and resolution timelines must be retained for potential review by market surveillance authorities.

CRA reference:Annex I Part II(5), Article 14(1)

Article 14 — 24h/72h/14-day notification obligations

Article 14 establishes a tiered notification regime for actively exploited vulnerabilities. Within 24 hours of becoming aware that a vulnerability in their product is being actively exploited, the manufacturer must submit an early warning to ENISA's single reporting platform and the relevant national CSIRT. This early warning must include basic product identification and a description of the vulnerability and exploitation activity. Within 72 hours, a detailed notification must be submitted covering the vulnerability's technical nature, its severity, affected product versions, and any interim mitigations available. Within 14 days of the initial notification, a final report must be submitted that includes remediation status — whether a patch has been issued, a timeline for one if not, and any residual risk. PSIRT managers must ensure their internal escalation and approval processes can operate within these compressed timelines.

CRA reference:Article 14(2), Article 14(3), Article 14(7)

CSAF advisory authoring

The Common Security Advisory Framework (CSAF) is a machine-readable JSON format for publishing security advisories. ENISA and the European Commission have signalled that CSAF will be the expected format for CRA-related disclosures. A CSAF advisory contains structured information about affected products (using CPE identifiers), vulnerability identifiers (CVE numbers), CVSS scores, remediation instructions, and VEX (Vulnerability Exploitability eXchange) statements that allow downstream integrators to understand whether a specific component configuration is actually affected. PSIRT managers should invest in CSAF tooling during the CRA transitional period. Producing CSAF advisories consistently also benefits enterprise customers who are themselves subject to the NIS2 Directive and need machine-readable supplier security information to meet their own obligations.

CRA reference:Article 14, Annex I Part II

Getting started checklist

Audit whether the organisation has a published CVD policy and a working security contact. If not, publish a security.txt file referencing a monitored disclosure inbox, and draft a CVD policy document. Map the internal escalation path for Article 14 notifications: who assesses active exploitation, who approves the submission, and who holds the credentials for ENISA's reporting platform. Create a notification template for each of the three Article 14 deadlines so that submissions can be prepared quickly under pressure. Establish a CSAF template for standard advisory types. Run a tabletop exercise simulating an actively exploited vulnerability to validate that the process works within the 24-hour early warning window. Use CVD Portal's Article 14 timeline tool to track submission deadlines during live incidents.

CRA reference:Article 14, Annex I Part II

CVD Portal handles your CRA Article 13 obligations automatically.

Public CVD submission portal, 48-hour acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation — built for PSIRT Mgrs and their teams.

Start your free portal

Frequently asked by PSIRT Mgrs

What does 'actively exploited' mean under Article 14?+

The CRA uses 'actively exploited vulnerability' as the trigger for the Article 14 notification obligations, but does not define the term with precision. ENISA guidance interprets it as evidence that the vulnerability is being used in real-world attacks — not merely that a proof-of-concept exploit exists in a research context. Indicators include threat intelligence feeds reporting exploitation in the wild, CISA KEV catalogue additions, honeypot observations, or direct customer reports of compromise attributed to the vulnerability. PSIRT managers should document the evidence basis for any active exploitation assessment.

Must the manufacturer notify ENISA if a vulnerability is discovered but not yet exploited?+

The Article 14 mandatory notification regime is triggered specifically by active exploitation. Vulnerabilities that are discovered but have no evidence of active exploitation do not trigger the 24h/72h/14-day reporting obligation. However, the manufacturer still has an obligation under Annex I Part II to address and remediate known vulnerabilities, and to disclose them through the CVD process within the timeframe established in the CVD policy. For severe vulnerabilities, proactive notification to ENISA is permitted and may be advisable to demonstrate good faith.

Can the PSIRT use existing CVE infrastructure for CRA compliance?+

CVE identifiers are a required element of CSAF advisories and are referenced in Article 14 notifications. Manufacturers who are CNA (CVE Numbering Authority) members can self-assign CVE IDs to vulnerabilities in their products, which streamlines the disclosure process. Manufacturers who are not CNAs must request CVE IDs through an appropriate root or top-level CNA. Establishing CNA status is advisable for manufacturers with a regular flow of vulnerability disclosures, as it provides control over timing and reduces dependency on third parties during coordinated disclosure windows.

Need a CVD policy template your team can deploy today?

Free CRA-compliant templates for every stage — from first CVD policy to full PSIRT programme.

Browse templates →