Purpose
Annex I Part II of the Cyber Resilience Act (Regulation (EU) 2024/2847) requires the manufacturer to have functioning vulnerability management throughout the entire support period: find vulnerabilities, document them, remediate them without undue delay, distribute updates securely, disclose remediated vulnerabilities and enforce a coordinated vulnerability disclosure policy (CVD policy) . This process is at the same time the nervous system of the reporting obligation: without it, an actively exploited vulnerability will not be detected in time, and the 24-hour deadline of Art. 14 CRA cannot be met structurally.
⚠️ Currency (as of 2026-07): The regulation entered into force on 10.12.2024 . From 11.09.2026 the reporting obligations under Art. 14 CRA apply; the requirements of Annex I Part II apply with full applicability from 11.12.2027.
In practice, the order is reversed. Although vulnerability management only becomes enforceable in 2027, the reporting obligation from 11.09.2026 de facto presupposes it: anyone without intake channels, without triage and without documented update provision can comply neither with the 24-hour early warning nor with the 14-day final report linked to update availability. The CVD process must therefore be established before 11.09.2026.
Product liability interface: With the implementation of the reformed Product Liability Directive on 09.12.2026 is software as a product is treated; omitted security updates within the support period can thus directly give rise to liability.
[unverifiziert - prüfen]The German implementation status must be examined separately.Sanctions framework: Infringements of the essential requirements including Annex I Part II are punishable with up to EUR 15 million or 2.5% of worldwide annual turnover , whichever amount is higher (Art. 64 CRA).
Inputs
- Product portfolio with versions, support periods and classification from the CRA product inventory
- Existing SBOM per product version, format and update frequency
- Existing processes: intake of security reports, triage, patch development, release, communication
- Existing CVD policy,
security.txt, bug bounty programme, contact address - Update infrastructure: signing procedure, distribution channels, rollback, reachability of offline installations
- Specific incoming report, if available: reporter, date, content, reporter's disclosure deadline
- Parallel obligation circles: NIS2 entity? DORA? Product liability risk?
Sub-agent architecture
Three conceptual roles structure the work. A process architect designs and reviews the process from the intake point through triage and remediation to disclosure and anchors it organizationally with roles, backup, and availability. A triage analyst assesses the individual vulnerability based on exploitability, severity, and impact on the portfolio — in particular, they decide whether active exploitation exists and thus the reporting trigger of Art. 14 CRA is met, and in this case immediately hands off to the cra-meldepflichten. A communications editor is responsible for external representation: response to the reporter, user information, security advisory after provision of the update, and coordination with CSIRT and the CVE assignment authority. The triage analyst is the time-critical path; their decision must not wait for patch development.
Process
1. Policy on coordinated vulnerability disclosure (Annex I Part II CRA)
The CVD policy is to be issued, enforced, and made publicly accessible. Minimum content:
- Scope: which products, versions, and services are covered
- Reporting channel with contact address and, where appropriate, the option of encrypted transmission
- Response commitments: acknowledgment of receipt, initial feedback, status updates — each with a time frame
- Disclosure model: coordinated disclosure after provision of an update; standard period and handling of extensions
- Safe harbour: commitment not to take legal action against good-faith researchers who comply with the policy — in particular, no criminal or civil prosecution under Sections 202a, 202c, 303a of the German Criminal Code
- Recognition of the reporter (credit) and handling of bug bounty compensation
- Exclusions: what is expressly not covered (such as denial-of-service tests in production systems, social engineering)
The policy must be made practically discoverable: via the product website, in the user information pursuant to Annex II CRA, and via a security.txt according to the relevant internet standard.
2. Intake channel and initial response (Annex I Part II CRA)
Annex I Part II requires measures that facilitate the reporting of vulnerabilities, including a contact address.
- A designated address, monitored, with a backup arrangement and availability outside business hours as well
- Automatic acknowledgment of receipt with case number and timestamp — the timestamp also serves as evidence of knowledge within the meaning of Art. 14 CRA
- No defensive reaction: The first contact with a security researcher determines the further course. Legal threats regularly lead to uncoordinated publication
- Consolidation all channels into a ticket system: support, sales, CERT notices, supplier reports, monitoring — vulnerability reports rarely reach the company via the intended channel
- Forwarding to triage within a few hours, not within days
3. Triage and assessment (Art. 14 CRA)
Triage answers four questions, in this order:
- Affectedness — which products and versions are affected? This question cannot be answered within hours without a reliable SBOM .
- Reproducibility and severity — verification, assessment according to an established scheme (such as CVSS), classification of exploitability.
- Active exploitation? — is there any indication that the vulnerability is actually being exploited? If so, the reporting trigger of Art. 14 CRA is met and the 24-hour early warning runs from the time of becoming aware. Handover to
cra-meldepflichten. - immediate measures — is there a workaround that users can apply immediately?
Separation of two regimes. An unexploited vulnerability triggers no reporting obligation under Art. 14 CRA, but is fully subject to the handling obligations of Annex I Part II. Conversely, reporting to the authority does not establish fulfilment of the remediation obligation. Both strands continue in parallel.
Every triage decision must be documented with reasons and a timestamp — including and especially the decision against a report.
4. Remediation and distribution of security updates (Annex I Part II CRA)
Annex I Part II requires immediate remediation, in particular through security updates, and mechanisms for secure distribution:
- Immediately means: without culpable delay after verification, not in the next regular release cycle
- Free of charge and, as far as technically possible, separate from feature updates
- Signature and integrity verification of the updates; secure distribution channels; protection against downgrade
- Option of automatic installation with an opt-out for the user
- Rollback capability and tested update paths also for older version states
- Document the time of provision — it triggers the 14-day deadline for the final report under Art. 14 CRA and cannot be proven later without documentation
- Where remediation is not immediately possible: documented workaround and user notice
For vulnerabilities in third-party open source components the manufacturer is responsible towards its users. Waiting for an upstream fix does not relieve it; if necessary, it must patch or mitigate itself.
5. Public disclosure and Security Advisory (Annex I Part II CRA)
After a security update is provided, information about the remediated vulnerability must be publicly disclosed. Content of the Advisory:
- Description of the vulnerability and the affected products and versions
- Impact and severity
- Clear instructions on how users can remediate the vulnerability — version, source of supply, procedure
- Identifier (CVE), if assigned, and time of remediation
Disclosure may be delayed as long as the security risks of publication outweigh the benefits — for example because no update is yet available. This weighing must be documented; it is an exception, not the norm and not an instrument of reputation management.
The user information under Art. 14 CRA and the Advisory under Annex I Part II overlap but are not identical: the former is incident-related and regularly precedes remediation, the latter follows remediation.
6. Coordination with CSIRT, BSI and CVE assignment (Art. 14 CRA)
- CSIRT coordination: In the case of actively exploited vulnerabilities, the report is made via the single reporting platform to the CSIRT of the Member State of the main establishment; the ENISA receives the information in parallel. For Germany, the BSI (bsi.bund.de) is the competent interface
- CVE identifier apply for via a CVE Numbering Authority — it is the common language towards customers, authorities and scanners. A dedicated CNA role should be considered for a larger portfolio
- Multi-party coordination, when a vulnerability in a widely used component affects multiple manufacturers: schedule, joint disclosure date, embargo discipline
- Official inquiries and prepare market surveillance measures under Art. 52 CRA: the documented process is the exculpatory evidence
7. Interfaces to NIS2, product liability and contract law (Art. 14, 52 CRA)
NIS2. In addition, the risk management and reporting obligations of Directive (EU) 2022/2555apply to the organization itself. The CRA attaches to the product , NIS2 to the entity. A manufacturer can simultaneously be subject to both regimes and must serve both reporting channels separately. At the same time, the manufacturer is a supplier to its NIS2-obligated customers: these contractually require response times, SBOM and advisory access.
Product liability from 09.12.2026. The reformed Product Liability Directive treats software as a product irrespective of the embodiment; the maximum liability amount under the old legal situation is eliminated, the concept of damage is broadened, and disclosure obligations as well as rebuttable presumptions of causation apply. [unverifiziert - prüfen] The German implementation status must be examined separately. Practical consequence: A omitted security update within the support period may be assessed as a product defect. CRA compliance thus becomes a liability defense; the CRA documentation must accordingly be maintained in a manner that is evidentially sound.
Contract law and supply chain. What is required are supplier commitments regarding vulnerability reporting, patch provision and SBOM delivery that cover at least one's own support period, as well as recourse provisions. Vis-à-vis customers, response times and advisory channels must be clearly defined.
Sources
Statute
- Regulation (EU) 2024/2847 (Cyber Resilience Act) — full text with annexes
- Annex I Part II CRA (requirements for vulnerability handling), Annex I Part I CRA (product characteristics), Annex II CRA (user information), Annex VII CRA (technical documentation)
- Art. 13 CRA (obligations of manufacturers, support period), Art. 14 CRA (reporting obligations), Art. 52 CRA (market surveillance), Art. 64 CRA (sanctions)
- Directive (EU) 2022/2555 (NIS2) — Art. 21, 23
- Directive (EU) 2024/2853 (Product Liability) — software as a product, implementation by 09.12.2026
- §§ 202a, 202c, 303a StGB — criminal-law framework for security research and reason for the safe-harbour commitment
Guidelines
- European Commission, Cyber Resilience Act — policy page and FAQ on implementation
- BSI — coordinated vulnerability disclosure and reporting channels
- ENISA, requirements for vulnerability coordination and the single reporting platform
- ISO/IEC 29147 (Vulnerability Disclosure) and ISO/IEC 30111 (Vulnerability Handling) as a reference framework
Case law: On the Cyber Resilience Act, no case law is apparent (as of 07/2026). Regarding the criminal-law classification of security research under §§ 202a, 202c StGB, case law exists that does not, however, support the CRA; it must be researched separately and with a verification marker.
Output format
CRA-SCHWACHSTELLENMANAGEMENT — <Produkt / Vorgang> — <Datum>
I. CVD-Policy (Anhang I Teil II)
Veröffentlicht / auffindbar [ja / nein — Fundort]
Geltungsbereich / Reaktionszusagen […]
Safe Harbour [ja / nein]
security.txt [ja / nein]
II. Eingangskanal
Kontaktadresse / Erreichbarkeit […]
Eingangsbestätigung + Zeitstempel […]
III. Triage
Betroffene Produkte/Versionen [SBOM-gestützt? …]
Schwere / Ausnutzbarkeit […]
AKTIVE AUSNUTZUNG? [ja → Art. 14 CRA, 24h-Frist läuft
ab <TT.MM. HH:MM> / nein]
IV. Behebung
Update / Umgehungslösung […]
Zeitpunkt der Bereitstellung <TT.MM.JJJJ, HH:MM> (löst 14-Tage-Frist)
Signatur / sichere Verteilung […]
V. Offenlegung
Security Advisory [Inhalt, Zeitpunkt]
CVE-Kennung […]
Verzögerung begründet? […]
VI. Koordinierung [CSIRT / BSI / CNA / Mehrparteien]
VII. Schnittstellen NIS2 [ja/nein] ·
Produkthaftung ab 09.12.2026 [Risiko]
Lieferkette / Zulieferzusagen […]
VIII. Sanktionsrisiko (Art. 64 CRA) [bis 15 Mio. EUR / 2,5 %]
Risikoeinstufung: 🟢 / 🟡 / 🔴
Empfehlung: <…>
Nächste Schritte: <…>
Risks / typical errors
- No published CVD policy — Annex I Part II requires adoption, enforcement and public accessibility. An internal policy is not sufficient.
- Reporter legally threatened — the defensive reaction toward a good-faith security researcher regularly leads to uncoordinated publication and reduces one's own response time to zero. Include a safe-harbour commitment.
- Triage waits for the patch — the decision on active exploitation and thus on the 24-hour deadline under Art. 14 CRA must be decoupled from patch development.
- Time of update provision not documented — it triggers the 14-day deadline for the final report; without documentation, compliance with the deadline cannot be evidenced.
- Only the designated reporting channel monitored — vulnerability reports come via support, sales, social networks and suppliers. All channels must be bundled.
- Triaged without SBOM — the question of affectedness then cannot be answered within hours, and the 24-hour deadline is structurally untenable.
- Waited for upstream fix — in the case of vulnerabilities in third-party open-source components, the manufacturer remains responsible towards its users; if necessary, it must patch or mitigate itself.
- Disclosure permanently delayed — the delay is an exception requiring justification, not an instrument of reputation management.
- Advisory without instructions for action — the disclosure must tell users concretely how to remediate the vulnerability.
- Notification confused with remediation — the notification to authorities under Art. 14 CRA does not fulfil the remediation obligation under Annex I Part II, and vice versa.
- Product liability as of 09.12.2026 not considered — a failure to provide a security update within the support period may be assessed as a product defect; the CRA documentation must be kept in a manner that is evidentially sound.
- Supplier commitments shorter than one's own support period — patch availability must be contractually passed down the supply chain.
- ⚠️ Article and Annex numbers adopted without verification — several details are
[unverifiziert - prüfen]and must be verified against the Official Journal text of Regulation (EU) 2024/2847 before client-facing use.