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.
Document control
| 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
1. Scope and applicability
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
| 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 |
3. Roles and responsibilities
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)
| 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
| 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
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)) | [[email protected] 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
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
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
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
| 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
| 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
| 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
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.
| 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
| 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 |
- 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.