CRA Article 13(8) Vulnerability Handling Policy: Free Template for Manufacturers

The Cyber Resilience Act (CRA) enters into force on 10 December 2024, imposing strict vulnerability handling obligations on manufacturers of connected products. Article 13(8) requires a documented policy for coordinated disclosure and remediation of vulnerabilities—failure to comply risks fines up to €15 million or 2.5% of global turnover. This article provides a production-ready template aligned with CRA and ISO/IEC 30111, including a CVD process flow, severity-based SLAs, and ENISA reporting integration.

---

1. CRA Article 13(8) Vulnerability Handling Mandate Breakdown

CRA Article 13(8) obliges manufacturers to:

• Identify and document vulnerabilities in products with digital elements (PDEs) throughout their lifecycle.
• Establish and maintain a vulnerability handling policy that includes: - Processes for coordinated disclosure (CVD). - Remediation timelines based on severity. - Mechanisms for reporting to ENISA’s single reporting point (SRP) under CRA Article 11(6).
• Ensure transparency by publishing vulnerability information in a machine-readable format (e.g., CSAF or CVRF).

The policy must cover both internally discovered vulnerabilities and those reported by third parties (e.g., security researchers, customers, or CERTs). Manufacturers must also retain records of vulnerability handling for 10 years post-product-support (CRA Article 10(11)).

Key compliance gaps to address:

• Lack of a formal CVD process with defined roles (e.g., PSIRT, legal, communications).
• Missing severity-based SLAs for remediation.
• No integration with ENISA’s SRP for 24-hour notifications of actively exploited vulnerabilities.

---

2. Coordinated Vulnerability Disclosure (CVD) Flow

A robust CVD process ensures vulnerabilities are reported, triaged, and remediated without exposing users to unnecessary risk. Below is a Mermaid sequence diagram of the workflow, followed by a textual breakdown.

sequenceDiagram
    actor Reporter
    participant PSIRT
    participant ProductTeam
    participant Legal
    participant Comms
    participant ENISA_SRP

    Reporter->>PSIRT: Submit vulnerability (email/PGP/web form)
    PSIRT->>PSIRT: Acknowledge receipt (24h)
    PSIRT->>ProductTeam: Triage & severity assessment (48h)
    alt Critical/High
        ProductTeam->>PSIRT: Confirm exploitability
        PSIRT->>ENISA_SRP: 24h notification (if actively exploited)
    end
    ProductTeam->>PSIRT: Remediation plan (SLA-based)
    PSIRT->>Reporter: Regular updates (bi-weekly)
    ProductTeam->>PSIRT: Fix validated
    PSIRT->>Legal: Approve disclosure
    PSIRT->>Comms: Draft advisory
    PSIRT->>Reporter: Pre-disclosure (if applicable)
    PSIRT->>Public: Publish advisory (CSAF/CVRF)
    PSIRT->>ENISA_SRP: Final report (if required)

CVD Process Steps:

1. 1Intake: Vulnerabilities are submitted via a secure channel (e.g., security@vendor.com with PGP key or a web form). CRA Article 13(8)(a) requires manufacturers to provide a publicly accessible reporting mechanism.
2. 2Acknowledgment: PSIRT acknowledges receipt within 24 hours (ISO/IEC 30111 best practice).
3. 3Triage: The product team assesses severity (see Section 3) and exploitability within 48 hours.
4. 4ENISA Notification (if applicable): For actively exploited vulnerabilities, notify ENISA’s SRP within 24 hours (CRA Article 11(6)).
5. 5Remediation: Develop and validate a fix within the SLA (see Section 3).
6. 6Disclosure: Publish a machine-readable advisory (CSAF/CVRF) and notify affected customers. Pre-disclosure to the reporter is optional but recommended for transparency.

---

3. Severity Classification + Remediation SLA Table

CRA does not prescribe a specific severity framework, but ISO/IEC 30111 and CVSS v3.1 are widely adopted. Below is a severity-SLA matrix aligned with CRA’s risk-based approach.

Notes:

• Critical/High vulnerabilities with active exploitation trigger a 24-hour notification to ENISA’s SRP (CRA Article 11(6)).
• SLAs are maximum timeframes; faster remediation is encouraged.
• Patch testing: All fixes must be validated in a staging environment before release.

---

4. ENISA Single Reporting Point Integration: 24h Actively Exploited Notification

CRA Article 11(6) requires manufacturers to report actively exploited vulnerabilities to ENISA’s SRP within 24 hours of confirmation. This applies to:

• Vulnerabilities in supported products (i.e., still under security maintenance).
• Vulnerabilities with public proof-of-concept (PoC) exploits or evidence of in-the-wild exploitation.

ENISA SRP Reporting Workflow:

1. 1Detection: PSIRT or the product team confirms active exploitation (e.g., via threat intelligence, customer reports, or researcher disclosures).
2. 2Initial Notification: Submit a preliminary report to ENISA within 24 hours via the [ENISA SRP portal](https://www.enisa.europa.eu/topics/cybersecurity-incident-reporting/single-reporting-point). Include: - Product name and version. - CVE ID (if assigned). - CVSS score and vector. - Evidence of exploitation (e.g., IOCs, attack patterns).
3. 3Follow-Up: Provide a final report within 7 days with: - Remediation status (e.g., patch available, workaround). - Mitigation guidance for users. - Disclosure timeline.

Key considerations:

• No double reporting: If the vulnerability is already reported under NIS2 (e.g., by a CSIRT), coordinate with ENISA to avoid duplication.
• Confidentiality: ENISA treats reports as confidential but may share them with relevant authorities (e.g., national CSIRTs).

---

5. Internal RACI: PSIRT vs Product Team vs Legal vs Comms

A clear RACI matrix ensures accountability across teams. Below is a role breakdown for vulnerability handling:

Role Definitions:

• R (Responsible): Executes the task.
• A (Accountable): Owns the outcome (only one per task).
• C (Consulted): Provides input.
• I (Informed): Notified of progress.

Critical dependencies:

• Legal must approve all public disclosures to avoid liability risks (e.g., misrepresentation of severity).
• Comms must align messaging with the product team to ensure technical accuracy.

---

6. Policy Template: Download and Customize

To help manufacturers comply with CRA Article 13(8), we’ve created a production-ready vulnerability handling policy template. The template includes:

• CVD process workflow (aligned with ISO/IEC 30111).
• Severity classification and SLA matrix.
• ENISA SRP reporting procedures.
• RACI matrix for internal teams.
• Machine-readable advisory format (CSAF/CVRF) guidance.

Download the template here: [CRA Vulnerability Handling Policy Template](https://www.nexcyber.eu/assess?utm_source=editorial&utm_campaign=cra-vulnerability-handling-policy-template)

Customization tips:

1. 1Tailor severity SLAs to your product risk profile (e.g., medical devices may require shorter SLAs).
2. 2Integrate with existing tools: Link the policy to your PSIRT ticketing system (e.g., Jira, ServiceNow) and vulnerability scanners (e.g., Nessus, Qualys).
3. 3Train teams: Conduct tabletop exercises to test the CVD process and ENISA