The situation
A security team receives a CVE affecting a shipped component. Its first review finds no active exploitation. Later, reliable evidence may confirm exploitation affecting the relevant product. The reporting assessment should change with those facts, while remediation continues in either case.
Facts that change the answer
- What evidence establishes active exploitation rather than theoretical exploitability?
- Does the vulnerability affect the product being assessed?
- When did the manufacturer become aware of the relevant facts?
Compare the worked results
These examples use the published assessment with the assumptions shown below. Change the facts in your own assessment before relying on its result.
CVE recorded; active exploitation not identified
Hypothetical example 1
Key facts in this example
- Timestamp when the organisation became aware of the vulnerability
- 2026-09-11T09:00:00Z
- Evidence that a malicious actor is exploiting the vulnerability in a system without the system owner’s permission
- not identified
- The notification records, where applicable, Member States where the product is known to have been made available
- Yes
- The 72-hour notification records available product information and the general nature of the exploit and vulnerability
- Yes
- Date the corrective or mitigating measure became available
- 2026-09-12
- Corrective or mitigating measures taken, and measures users can take, are recorded
- Yes
- The notification records how sensitive the submitted information is, where applicable
- Yes
- Final-report status within 14 days after a corrective or mitigating measure became available
- submitted within 14 days
- The final report describes the vulnerability, including severity and impact
- Yes
- Available information about malicious exploitation and relevant threat actors is recorded
- Yes
- The final report gives details of the security update or other corrective or mitigating measures
- Yes
- Submission to the designated coordinating CSIRT and ENISA is confirmed
- Yes
All recorded assumptions (14)
- Affected product with digital elements
- Hypothetical example product
- Reporting role
- manufacturer
- Timestamp when the organisation became aware of the vulnerability
- 2026-09-11T09:00:00Z
- Evidence that a malicious actor is exploiting the vulnerability in a system without the system owner’s permission
- not identified
- The notification records, where applicable, Member States where the product is known to have been made available
- Yes
- The 72-hour notification records available product information and the general nature of the exploit and vulnerability
- Yes
- Date the corrective or mitigating measure became available
- 2026-09-12
- Corrective or mitigating measures taken, and measures users can take, are recorded
- Yes
- The notification records how sensitive the submitted information is, where applicable
- Yes
- Final-report status within 14 days after a corrective or mitigating measure became available
- submitted within 14 days
- The final report describes the vulnerability, including severity and impact
- Yes
- Available information about malicious exploitation and relevant threat actors is recorded
- Yes
- The final report gives details of the security update or other corrective or mitigating measures
- Yes
- Submission to the designated coordinating CSIRT and ENISA is confirmed
- Yes
Active exploitation confirmed; notifications in progress
Hypothetical example 2
Key facts in this example
- Timestamp when the organisation became aware of the vulnerability
- 2026-09-13T09:00:00Z
- Evidence that a malicious actor is exploiting the vulnerability in a system without the system owner’s permission
- confirmed
- 24-hour early-warning status
- deadline not yet reached
- 72-hour vulnerability-notification status
- deadline not yet reached
- A corrective or mitigating measure is available
- No
- Impacted users were informed without undue delay, including necessary risk-mitigation or corrective measures
- Yes
All recorded assumptions (8)
- Affected product with digital elements
- Hypothetical example product
- Reporting role
- manufacturer
- Timestamp when the organisation became aware of the vulnerability
- 2026-09-13T09:00:00Z
- Evidence that a malicious actor is exploiting the vulnerability in a system without the system owner’s permission
- confirmed
- 24-hour early-warning status
- deadline not yet reached
- 72-hour vulnerability-notification status
- deadline not yet reached
- A corrective or mitigating measure is available
- No
- Impacted users were informed without undue delay, including necessary risk-mitigation or corrective measures
- Yes
Evaluated on 2026-09-13 using EU Cyber Resilience Act actively exploited vulnerability notification record, version 2026.09.02. A completed example is not a customer Record or a declaration of conformity.
Evidence to keep
- CVE and affected-version analysis
- Exploitation evidence with provenance and timestamps
- Manufacturer role and awareness record
Keep source artifacts in their controlled systems and record their references, responsible owner and review date with the decision.
Your next step
Keep the initial finding and reassess when evidence changes. Confirm the reporting threshold before using the deadline calculator for the case.
Choose your real product or vulnerability case in the workspace. The selected assessment will be highlighted; example answers are not copied into your record.
Sources and application dates
- Regulation (EU) 2024/2847 (Cyber Resilience Act)Article 14(1), (2), (7) and (8), Article 24(3), and Article 71(2)
- European Commission CRA reporting obligationsSingle Reporting Platform, reporting scope and application date
Manufacturer reporting applies from 11 September 2026. Broader product requirements apply from 11 December 2027; these product-readiness examples support preparation. Open-source-steward obligations have their own application date.
These examples structure a decision and do not replace the Regulation, official guidance or product-specific professional advice. Not lawyer-reviewed.