# CRA Vulnerability Handling and Reporting Procedure: [Manufacturer] [product family]

> Procedure for a manufacturer of products with digital elements to handle
> vulnerabilities and to report actively exploited vulnerabilities and
> severe incidents under the EU Cyber Resilience Act (Regulation (EU)
> 2024/2847). It covers the vulnerability handling requirements of Annex
> I Part II, the software bill of materials, coordinated vulnerability
> disclosure, security updates and the support period, and the Article 14
> reporting clocks (24 hours, 72 hours and final report) through the ENISA
> Single Reporting Platform. Article 14 applies from 11 September 2026,
> also to products placed on the market before 11 December 2027; the rest
> of the Regulation applies from 11 December 2027. Check the consolidated
> text on EUR-Lex for the dates and wording that apply to you.
> Replace every `[bracketed]` value and every row marked *Example*.
> This is a documentation format, not legal advice.

<!--
Guidance: How to use this template
- Confirm first that you are a manufacturer of a product with digital
  elements in scope of the Regulation (Article 2 and the exclusions for
  products covered by sector legislation). Importers, distributors and
  open-source software stewards have different, lighter obligations.
- Sections 1 to 3 set scope and roles. Sections 4 to 8 implement Annex I
  Part II and Article 13. Sections 9 and 10 implement Article 14. Keep
  them in one document so the people who triage a report also know when
  the reporting clock starts.
- The reporting clock in Article 14 starts when the manufacturer becomes
  aware. Define "aware" in section 9.2 so that nobody waits for a full
  analysis before starting the clock.
- Test the procedure with an exercise at least once a year (section 12)
  and after every real report.
- Paraphrases of the Regulation in this template are summaries. Read
  the Regulation itself for binding wording and check Commission
  implementing and delegated acts and ENISA guidance.
-->

## Document control

<!-- Guidance: Identify the products covered, the coordinator CSIRT and the people who can submit a notification on the platform at any hour. -->

| Field | Value |
|---|---|
| Document ID | [CRA-VH-001] |
| Manufacturer | [Legal name, address, main establishment Member State] |
| Products covered | [Product names, types, versions; or reference to the product register] |
| Coordinator CSIRT | *Example:* CSIRT designated as coordinator in [Member State of main establishment] |
| Single Reporting Platform account | [Organisation account ID; named submitters in section 3] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@product-security-lead] |
| Approvers / reviewers | [@ciso], [@legal-regulatory], [@head-of-engineering] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Related documents | [CRA technical documentation], [Coordinated vulnerability disclosure policy], [Incident response plan], [SBOM policy], [Security policy] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Product security lead | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Decision] | YYYY-MM-DD |
| Legal and regulatory affairs | [@name] | [Decision] | YYYY-MM-DD |
| Accountable executive | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved before 11 September 2026 reporting start |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Updated after tabletop exercise EX-2026-02 |

## Contents

<!-- Guidance: Keep the order: scope, roles, handling, then reporting. -->

1. [Scope and applicability](#1-scope-and-applicability)
2. [Key dates and legal basis](#2-key-dates-and-legal-basis)
3. [Roles and responsibilities](#3-roles-and-responsibilities)
4. [Vulnerability handling requirements (Annex I Part II)](#4-vulnerability-handling-requirements-annex-i-part-ii)
5. [Software bill of materials](#5-software-bill-of-materials)
6. [Coordinated vulnerability disclosure](#6-coordinated-vulnerability-disclosure)
7. [Handling workflow](#7-handling-workflow)
8. [Security updates and support period](#8-security-updates-and-support-period)
9. [Reporting under Article 14](#9-reporting-under-article-14)
10. [Informing users](#10-informing-users)
11. [Records](#11-records)
12. [Exercises and review](#12-exercises-and-review)
13. [Worked timeline](#13-worked-timeline)
14. [Glossary and references](#14-glossary-and-references)

## 1. Scope and applicability

<!-- Guidance: List which products and versions this procedure covers and why they are in scope. Note where another regime also applies (for example NIS2 for your own services, or sector legislation for medical devices) so that reports are coordinated. Pitfall: forgetting products already on the market; Article 14 reporting covers them too. -->

### 1.1 Products

| Product ID | Product and versions | Category | Placed on the market | In scope reason | Support period end |
|---|---|---|---|---|---|
| PRD-001 *(Example)* | [Router model X] firmware 3.x | Important product, Annex III class I | 2025-03 | Hardware with software, network connection | 2031-03 |
| PRD-002 *(Example)* | [Desktop app] 5.x | Default category | 2024-06 | Software placed on the market commercially | 2029-12 |
| PRD-003 *(Example)* | [Cloud companion service] | Remote data processing solution of PRD-001 | 2025-03 | Remote processing needed for a product function | Same as PRD-001 |
| [PRD-nnn] | [Product] | [Default / Annex III class I / class II / Annex IV] | YYYY-MM | [Reason] | YYYY-MM |

### 1.2 Other regimes that may apply

| Regime | Relevance | Coordination rule |
|---|---|---|
| *Example:* NIS2 (Directive (EU) 2022/2555) | Our own network and information systems if we are an essential or important entity | Incident response plan decides whether both regimes apply; one incident record, two reports |
| *Example:* GDPR (Regulation (EU) 2016/679) | Personal data breach in the companion service | Data protection officer assesses notification to the supervisory authority |
| *Example:* Sector legislation | [Medical devices, vehicles, aviation or other] | [Rule] |
| [Regime] | [Relevance] | [Rule] |

## 2. Key dates and legal basis

<!-- Guidance: Summarise the dates and provisions this procedure relies on. Recheck them against the consolidated text when the Regulation is amended. -->

| Provision | Summary in own words | Applies from |
|---|---|---|
| Article 71(2) | General date of application of the Regulation | 11 December 2027 |
| Article 71(2) | Reporting obligations of manufacturers (Article 14) | 11 September 2026 |
| Article 71(2) | Rules on notification of conformity assessment bodies (Chapter IV, Articles 35 to 51) | 11 June 2026 |
| Article 69(3) | Article 14 applies also to in-scope products placed on the market before 11 December 2027 | 11 September 2026 |
| Article 13(6) | Report vulnerabilities found in integrated components to the component maintainer and remediate them | 11 December 2027 |
| Article 13(8) | Handle vulnerabilities effectively for the support period; support period normally at least five years | 11 December 2027 |
| Article 13(9) | Keep each security update available for at least ten years or the rest of the support period, whichever is longer | 11 December 2027 |
| Article 13(17) | Single point of contact for users, including for vulnerability reports | 11 December 2027 |
| Article 15 | Voluntary reporting of vulnerabilities, threats, incidents and near misses | 11 December 2027 |
| Article 16 | ENISA Single Reporting Platform, national notification end-points | Platform operated by ENISA; reporting through it applies from 11 September 2026 (check ENISA for the current entry point) |
| Annex I Part II | Eight vulnerability handling requirements | 11 December 2027 |

<!-- Guidance: Although most handling duties apply from December 2027, you cannot meet the 24-hour reporting duty that already applies without an intake, triage and decision process. Implement sections 6, 7 and 9 now. -->

## 3. Roles and responsibilities

<!-- Guidance: Name people, not only teams, and give every critical role a deputy. At least two people must be able to submit on the Single Reporting Platform at any time, including weekends. -->

### 3.1 Roles

| Role | Holder | Deputy | Responsibilities |
|---|---|---|---|
| Product security incident response team (PSIRT) lead | [@name] | [@name] | Owns this procedure, runs triage, decides whether a case is reportable |
| Reporting officer | [@name] | [@name] | Submits early warning, notification and final report on the platform |
| Product owner | [@name] per product | [@name] | Fix planning, release, user communication content |
| Engineering lead | [@name] | [@name] | Root cause, fix, test |
| Legal and regulatory | [@name] | [@name] | Applicability, wording of reports, contact with authorities |
| Communications | [@name] | [@name] | Advisories, user notices, press |
| Executive sponsor | [@name] | [@name] | Escalation, resources, disclosure decisions with business impact |

### 3.2 RACI

R = responsible, A = accountable, C = consulted, I = informed.

| Activity | PSIRT lead | Reporting officer | Product owner | Engineering | Legal | Comms | Executive |
|---|---|---|---|---|---|---|---|
| Intake and acknowledgement | A, R | I | I | C | | | |
| Triage and severity | A, R | I | C | R | C | | |
| Decide "actively exploited" or "severe incident" | A | C | C | C | R | | I |
| Early warning (24 h) | A | R | I | C | C | | I |
| Notification (72 h) | A | R | C | C | C | | I |
| Fix and security update | C | | A | R | | | |
| Advisory and user information | A | | R | C | C | R | I |
| Final report | A | R | C | C | C | | I |
| Records and lessons learned | A, R | C | C | C | C | | I |

## 4. Vulnerability handling requirements (Annex I Part II)

<!-- Guidance: Map each of the eight points of Annex I Part II to the process that implements it and the evidence an authority could ask for. The point numbers match the Annex; the wording here is a summary. -->

| Point | Requirement (summary) | How we meet it | Evidence |
|---|---|---|---|
| (1) | Identify and document vulnerabilities and components, including a machine-readable SBOM covering at least top-level dependencies | Section 5; SBOM generated in every release build | SBOM archive, build logs |
| (2) | Address and remediate vulnerabilities without delay in relation to the risk, including through security updates; where technically feasible, ship security updates separately from feature updates | Sections 7 and 8; remediation targets by severity; separate security release train | Case records, release notes |
| (3) | Apply effective and regular security tests and reviews | *Example:* SAST and dependency scanning per commit; annual penetration test per product; fuzzing of parsers | Test reports |
| (4) | After a security update is available, publicly disclose information on fixed vulnerabilities (description, affected products, impact, severity, remediation guidance); publication may be delayed in justified cases until users could patch | Section 10; security advisories in CSAF and on the website | Advisory archive |
| (5) | Put in place and enforce a coordinated vulnerability disclosure policy | Section 6 | Published CVD policy |
| (6) | Facilitate sharing of information on potential vulnerabilities in the product and its third-party components, including a contact address for reports | Section 6.2; `security.txt`; reporting to upstream maintainers (Article 13(6)) | Contact page, upstream report log |
| (7) | Provide mechanisms to distribute updates securely so vulnerabilities are fixed or mitigated in a timely manner, automatically where applicable | Section 8.2; signed updates, automatic installation by default | Update architecture, signing records |
| (8) | Disseminate available security updates without delay and, unless agreed otherwise for a tailor-made product with a business user, free of charge, with advisory messages for users | Sections 8 and 10 | Release and notification records |

## 5. Software bill of materials

<!-- Guidance: The SBOM is both a handling tool (to know quickly whether you are affected) and a document an authority may request. Define format, depth, generation point and storage. The Commission may specify format and elements by implementing act (Article 13(24)); check whether one has been adopted. -->

| Item | Decision |
|---|---|
| Format | *Example:* CycloneDX 1.7 JSON (ECMA-424, 2nd edition); SPDX 3.0.1 on request |
| Minimum depth | At least top-level dependencies as required; *Example:* we include all transitive dependencies |
| Generation point | *Example:* Release build, from lockfiles and final firmware image |
| Binding | *Example:* SBOM signed and linked to the release artefact digest |
| Storage | *Example:* SBOM archive for every released version, kept for the documentation retention period |
| Use in handling | *Example:* Daily matching of all supported versions' SBOMs against vulnerability databases and the EU vulnerability database |
| Sharing | *Example:* Provided to market surveillance authorities on reasoned request; to customers under NDA; not published |
| Exploitability statements | *Example:* VEX statements published with advisories for "not affected" decisions |

See the supply chain security assessment (`security/supply-chain-security`)
for the full SBOM and VEX policy, and the AI-BOM template
(`ai-data/ai-bom`) if the product contains machine learning models.

## 6. Coordinated vulnerability disclosure

<!-- Guidance: Publish a policy that tells finders how to report, what to expect and how disclosure is coordinated. Keep the public version short; this section records the internal commitments behind it. -->

### 6.1 Policy commitments

| Commitment | Value |
|---|---|
| Public policy location | [URL of the CVD policy and `security.txt`] |
| Acknowledgement of a report | *Example:* Within 2 business days |
| Initial assessment shared with the reporter | *Example:* Within 10 business days |
| Status updates | *Example:* At least every 30 days until closure |
| Target disclosure | *Example:* Coordinated with the reporter; default 90 days after report or on release of a fix, whichever is earlier |
| Safe harbour | *Example:* Good-faith research within the policy is authorised; no legal action |
| Credit | *Example:* Reporter credited in the advisory unless they decline |
| CVE assignment | *Example:* We are a CVE Numbering Authority for our products / we request IDs from [CNA] |
| Use of a CSIRT as coordinator | Reporters may report to a national CSIRT acting as coordinator for CVD under NIS2 Article 12(1) |

### 6.2 Intake channels

| Channel | Address | Monitored | Notes |
|---|---|---|---|
| Single point of contact (Article 13(17)) | [security@example.com and web form] | 24/7 by on-call PSIRT | Users choose their channel; not limited to automated tools |
| Encrypted email | [PGP key fingerprint] | 24/7 | |
| Bug bounty platform | [Platform] | Business hours | Optional |
| CSIRT or ENISA forwarding | Via coordinator CSIRT | 24/7 | Article 15(4): CSIRT informs us of third-party reports |
| Internal findings | Ticket queue [name] | Business hours | Tests, audits, monitoring |
| Upstream and supplier advisories | Feeds [list] | Automated | Component vulnerabilities |

## 7. Handling workflow

<!-- Guidance: Show one path from intake to closure, with the decision point that starts Article 14 reporting. Use a severity scale that engineers and lawyers both understand. Remediation targets are internal commitments, not legal deadlines. -->

```mermaid
flowchart TD
  intake["Report received or vulnerability detected"] --> ack["Acknowledge, create case VH-nnn"]
  ack --> triage["Triage: reproduce, affected products and versions, severity"]
  triage --> exploited{"Reliable evidence of exploitation by a malicious actor?"}
  exploited -->|Yes| report["Start Article 14 vulnerability reporting (section 9)"]
  exploited -->|No| plan["Plan remediation by severity target"]
  report --> plan
  triage --> incident{"Severe incident affecting product security?"}
  incident -->|Yes| ireport["Start Article 14 incident reporting (section 9)"]
  plan --> fix["Fix, test, release security update"]
  fix --> advisory["Publish advisory, inform users (section 10)"]
  advisory --> final["Final report if reported; close case; lessons learned"]
```

### 7.1 Severity and remediation targets

| Severity | Typical criteria | Remediation target | Mitigation guidance to users |
|---|---|---|---|
| Critical *(Example)* | CVSS 4.0 base 9.0 to 10.0, or any actively exploited vulnerability | 7 days | Within 24 hours if fix not yet available |
| High *(Example)* | CVSS 4.0 base 7.0 to 8.9 | 30 days | With the fix |
| Medium *(Example)* | CVSS 4.0 base 4.0 to 6.9 | 90 days | With the fix |
| Low *(Example)* | CVSS 4.0 base below 4.0 | Next scheduled release | With the fix |

### 7.2 Case record fields

| Field | Content |
|---|---|
| Case ID | VH-YYYY-NNN |
| Source and date and time received | Channel, reporter, timestamp with time zone |
| Awareness timestamp | When the criteria in 9.2 were met (starts the Article 14 clock) |
| Affected products and versions | PRD IDs and version ranges; SBOM components |
| Severity and vector | CVSS 4.0 vector and score; exploitation evidence |
| Reportable | Actively exploited vulnerability / severe incident / neither, with reasoning |
| Remediation | Fix description, release, date |
| Disclosure | Advisory ID, CVE ID, publication date |
| Reports submitted | Platform reference numbers and timestamps |

## 8. Security updates and support period

<!-- Guidance: Record the support period per product and how it was set, the update delivery mechanism, and how users learn the end date. Pitfall: an end-of-support date that exists only in an internal roadmap. -->

### 8.1 Support period

| Product | Support period | Basis for the period (Article 13(8)) | End date shown to users | End-of-support notice |
|---|---|---|---|---|
| PRD-001 *(Example)* | 6 years from placing on the market | Expected use time of home routers; competitor practice; chipset vendor support until 2032 | Product page, packaging, admin UI (month and year) | Admin UI banner and email at end date |
| PRD-002 *(Example)* | 5 years per major version | Minimum period; users get the latest major version free (Article 13(10)) | Download page, About dialog | In-app notice |
| [PRD-nnn] | [Period] | [Basis] | [Where shown] | [Notice] |

### 8.2 Update delivery

| Item | Practice |
|---|---|
| Separation from feature updates | *Example:* Security fixes released on a separate patch line where technically feasible |
| Automatic updates | *Example:* Enabled by default for security updates, with a clear opt-out and the option to postpone |
| Integrity | *Example:* Updates signed; device verifies signature and version before install; rollback protection |
| Availability | Each security update kept available for at least ten years or the rest of the support period, whichever is longer (Article 13(9)) |
| Cost | Free of charge, unless otherwise agreed with a business user for a tailor-made product |

## 9. Reporting under Article 14

<!-- Guidance: This is the part of the procedure with legal deadlines that already apply. Write it so that a deputy who has never reported can do it at 03:00. Pitfall: waiting for a fix or a complete analysis before sending the early warning. -->

### 9.1 What must be reported

| Case | Definition (summary) | Article |
|---|---|---|
| Actively exploited vulnerability | A vulnerability with reliable evidence that a malicious actor has exploited it in a system without the owner's permission (Article 3) | 14(1) |
| Severe incident having an impact on the security of the product | An incident that negatively affects, or can affect, the product's ability to protect availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or that has led or can lead to malicious code in the product or in a user's systems | 14(3), 14(5) |

Notifications go simultaneously to the CSIRT designated as coordinator and
to ENISA, through the Single Reporting Platform, using the electronic
notification end-point of the coordinator CSIRT of the Member State of
the main establishment (Article 14(7)). Main establishment means the
Member State where cybersecurity decisions for the products are mainly
taken; if that cannot be determined, the establishment with the most
employees in the Union. Manufacturers without a main establishment in
the Union follow the order set out in Article 14(7): authorised
representative, then importer, then distributor, then the Member State
with the most users.

### 9.2 When the clock starts

[Define awareness. Example: "We are aware when the PSIRT lead or a
deputy has information giving reasonable grounds to believe that the
criteria in 9.1 are met, for example a credible third-party report with
indicators of exploitation, our own telemetry, or a CSIRT notification.
Triage to reach that judgement must not exceed [4] hours from receipt.
The awareness timestamp is recorded in the case record."]

### 9.3 Reporting stages

| Stage | Deadline (from awareness) | Content (summary) | Owner |
|---|---|---|---|
| Early warning, vulnerability | Without undue delay, at most 24 hours | Notice of the actively exploited vulnerability; Member States where we know the product is available | Reporting officer |
| Vulnerability notification | Without undue delay, at most 72 hours, unless already provided | General information on the product, the nature of the exploit and vulnerability, corrective or mitigating measures taken and measures users can take; how sensitive we consider the information | Reporting officer |
| Final report, vulnerability | At most 14 days after a corrective or mitigating measure is available, unless already provided | Description with severity and impact; information on the malicious actor where available; details of the security update or other corrective measures | Reporting officer |
| Early warning, severe incident | Without undue delay, at most 24 hours | Notice of the incident; whether unlawful or malicious acts are suspected; Member States where the product is available | Reporting officer |
| Incident notification | Without undue delay, at most 72 hours, unless already provided | Nature of the incident, initial assessment, measures taken and measures users can take; sensitivity of the information | Reporting officer |
| Final report, severe incident | Within one month after the incident notification, unless already provided | Detailed description with severity and impact; type of threat or likely root cause; applied and ongoing mitigation | Reporting officer |
| Intermediate report | When requested by the coordinator CSIRT | Status updates on the vulnerability or incident (Article 14(6)) | Reporting officer |

### 9.4 Submission checklist

| Step | Done |
|---|---|
| Case ID and awareness timestamp recorded | [ ] |
| Product identification (name, type, versions, identifiers) ready | [ ] |
| Member States where the product is made available listed | [ ] |
| Sensitivity of the information stated, including any request to delay dissemination for justified cybersecurity reasons (Article 16(2)) | [ ] |
| Mitigation users can apply now described in plain language | [ ] |
| Submitted on the Single Reporting Platform; reference number recorded | [ ] |
| Next deadline entered in the case and the on-call calendar | [ ] |
| Coordination with NIS2, GDPR or sector reports checked (section 1.2) | [ ] |

## 10. Informing users

<!-- Guidance: Article 14(8) requires informing impacted users, and where appropriate all users, about an actively exploited vulnerability or severe incident and the measures they can take. Annex I Part II point (4) requires public advisories once a fix exists. If you do not inform users in time, the CSIRT may do it. -->

| Situation | Audience | Channel | Content | Timing |
|---|---|---|---|---|
| Actively exploited vulnerability, no fix yet | Impacted users, or all users where appropriate | *Example:* Admin UI notice, email, advisory page | Risk, mitigation steps, expected fix date | *Example:* With or before the 72-hour notification |
| Security update available | All users of affected versions | Update notification, advisory in CSAF and HTML | Description, affected products, impact, severity, remediation | With the update |
| Severe incident | Impacted users | Direct notice | What happened, impact on them, measures to take | As soon as measures are known |
| Delayed publication (justified) | Public | Advisory | Published after users could apply the patch | Documented decision |

Provide user information, where appropriate, in a structured,
machine-readable format that tools can process automatically, for
example CSAF 2.0 advisories with VEX status.

## 11. Records

<!-- Guidance: Keep the evidence an authority would expect: case records, reports submitted, advisories, SBOMs and decisions. Align retention with the technical documentation (at least ten years after placing on the market or the support period, whichever is longer, under Article 13(13)). -->

| Record | Content | Retention | Location |
|---|---|---|---|
| Case records | Fields in 7.2, decisions, timeline | *Example:* 10 years after the last affected version was placed on the market or the support period, whichever is longer | [System] |
| Platform submissions | Copies of each report and platform references | Same | [System] |
| Advisories and VEX | Published versions | Same | [System] |
| SBOMs | Per released version | Same | [System] |
| Component vulnerability reports to maintainers | Article 13(6) reports and shared fixes | Same | [System] |
| Exercise reports | Section 12 | 5 years | [System] |

## 12. Exercises and review

<!-- Guidance: Practise the 24-hour path with deputies, outside business hours, at least once a year. Measure the time from intake to early warning. -->

| ID | Exercise | Scenario | Measured | Date | Result |
|---|---|---|---|---|---|
| EX-2026-01 *(Example)* | Tabletop | Exploited authentication bypass in PRD-001 firmware reported on a Saturday | Time from intake to early warning draft | YYYY-MM-DD | 9 h; deputy lacked platform access, fixed |
| EX-2026-02 *(Example)* | Technical drill | Malicious update pushed through compromised build server | Detection, incident classification, user notice | YYYY-MM-DD | [Result] |
| [EX-nnn] | [Type] | [Scenario] | [Measure] | YYYY-MM-DD | [Result] |

Review this procedure after every reportable case, after each exercise,
when the Commission adopts implementing or delegated acts on reporting
or SBOM format, and at least annually.

## 13. Worked timeline

<!-- Guidance: Use the example to brief new staff. Replace it with a sanitised real case after the first report. -->

*Example:* A researcher reports on Monday at 10:00 that an authentication
bypass in PRD-001 firmware 3.4 is being used against routers on the
internet. The PSIRT confirms indicators of exploitation at 13:00, which is
the awareness time.

```mermaid
sequenceDiagram
  participant R as Researcher
  participant P as PSIRT
  participant S as Single Reporting Platform
  participant C as Coordinator CSIRT and ENISA
  participant U as Users
  R->>P: Mon 10:00 report with exploitation indicators
  P->>P: Mon 13:00 exploitation confirmed (awareness)
  P->>S: Mon 20:00 early warning (deadline Tue 13:00)
  S->>C: Dissemination to CSIRTs and ENISA
  P->>U: Tue 09:00 notice with mitigation (disable remote admin)
  P->>S: Wed 16:00 vulnerability notification (deadline Thu 13:00)
  P->>U: Fri security update 3.4.2, advisory and CSAF file
  P->>S: Following Wed final report (deadline 14 days after fix)
```

| Time | Action | Deadline met |
|---|---|---|
| Mon 13:00 | Awareness recorded in VH-2026-014 | Not applicable |
| Mon 20:00 | Early warning submitted | Yes (24 h deadline Tue 13:00) |
| Wed 16:00 | Vulnerability notification submitted | Yes (72 h deadline Thu 13:00) |
| Fri | Security update released (corrective measure available) | Not applicable |
| Following Wed | Final report submitted | Yes (14 days after the update) |

## 14. Glossary and references

<!-- Guidance: Keep the terms consistent with the Regulation. -->

| Term | Meaning in this document |
|---|---|
| Product with digital elements | Software or hardware product and its remote data processing solutions, including separately placed components |
| Manufacturer | Person who develops or manufactures the product, or has it designed or made, and markets it under its name or trademark |
| CSIRT designated as coordinator | National computer security incident response team designated for coordinated vulnerability disclosure under NIS2 |
| Single Reporting Platform | Platform run by ENISA through which Article 14 notifications are submitted |
| Support period | Period during which the manufacturer must handle vulnerabilities effectively in line with Annex I Part II |
| SBOM | Software bill of materials: a formal record of the components in the product's software and their supply chain relationships |
| CVD | Coordinated vulnerability disclosure |

References:

- Regulation (EU) 2024/2847 (Cyber Resilience Act), OJ L, 20.11.2024, ELI http://data.europa.eu/eli/reg/2024/2847/oj
- ENISA, CRA Single Reporting Platform, https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp
- Directive (EU) 2022/2555 (NIS2), Article 12 on coordinated vulnerability disclosure
- Related templates: `security/cra-technical-documentation`, `compliance/incident-response-plan`, `dev/security-policy`, `security/supply-chain-security`, `ai-data/ai-bom`

## Standard and licence note

Based on Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 3,
13 to 17, 69 and 71 and Annex I Part II, as published in the Official
Journal of the European Union on 20 November 2024; EU legislative texts
are free to reuse. The provisions are summarised in original wording and
no text of the Regulation is reproduced. Check the consolidated text on
EUR-Lex, Commission implementing and delegated acts, and ENISA guidance
for the current requirements. This is a documentation format, not legal
advice. Template licence: MIT.