CRA reporting readiness: dates, awareness timestamps and final-report follow-up
Practical guide · Educational reading
CRA reporting duties apply before the regulation's wider requirements. Manufacturers should review existing products, preserve awareness timestamps and track distinct final-report deadlines.
Effective date stated by the source: 2026-09-11
Audience / jurisdiction: European Union; manufacturers of in-scope products and the product-security, compliance and management-system teams supporting them
Separate reporting applicability from the wider timetable
Manufacturers assessing their duties under the EU Cyber Resilience Act (CRA) need to separate two dates. Article 14 reporting obligations apply from September 11, 2026, while the regulation generally applies from December 11, 2027. Waiting for the later date to prepare reporting arrangements would therefore overlook an obligation already applicable to manufacturers of in-scope products.
This guide focuses on those reporting duties, rather than the regulation's wider requirements. It is intended for product-security, compliance and management-system teams supporting manufacturers with potentially covered products. It is not a claim that every business, every software product or every vulnerability falls within the reporting regime. Product coverage and the relevant reporting trigger require their own assessment.
Sources: [1]
Review existing products and distinguish responsible roles
The timetable also requires attention to existing products. Article 69(3) extends Article 14 reporting obligations to in-scope products placed on the market before December 11, 2027. Teams should not assume that reporting preparation concerns only products launched after the regulation's general applicability date.
As a practical step, create a working inventory of potentially covered products and identify the internal team responsible for each. Include existing product lines in that review, rather than restricting it to development projects. This inventory is a suggested way to organise the assessment; it does not itself establish that a product is legally covered.
Keep organisational roles distinct too. The supplied legal evidence places the corresponding reporting duties for open-source software stewards at December 11, 2027. Do not automatically apply the manufacturers' earlier reporting date to that separate role.
Sources: [1]
Build the first response around awareness
For relevant reportable vulnerabilities and severe incidents, Article 14 requires an early warning without undue delay and within 24 hours of awareness. Subsequent notifications are due within 72 hours, unless the relevant information has already been provided. These are awareness-based deadlines, so a reporting procedure needs to preserve when awareness occurred.
A useful implementation approach is to record the awareness timestamp, the information then available and the person coordinating the response. For example, when a product-security team identifies a potentially reportable issue, its escalation record can include both the technical assessment and the timing information needed by the reporting owner.
That recordkeeping approach is advice, not a separate legal reporting threshold. Nor should the maximum time limits be treated as permission to postpone action: the requirement to act without undue delay remains important.
Sources: [1]
Track final reports separately
The two final-report deadlines use different starting points. For a reportable vulnerability, the final report is due within 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final report is due within one month after the incident notification.
Treat these as separate workflow paths rather than assigning every case a single generic closure deadline. A suggested tracking record would distinguish awareness, early warning, subsequent notification and the event that starts the final-report period. For vulnerability cases, that means explicitly tracking when a corrective or mitigating measure becomes available.
Assigning an owner for follow-up can help prevent an initial submission from being mistaken for completion of the reporting process. The ownership arrangement is an implementation choice; the applicable reporting deadlines come from the regulation.
Sources: [1]
Rehearse the reporting handover
A short readiness exercise can test whether the organisation can translate these requirements into action. Choose a hypothetical potentially reportable product issue, identify who assesses coverage and reportability, and check who can coordinate the early warning and subsequent notification. Name a deputy so the exercise does not depend on one person's availability.
Then test the timing record and final-report handover. Can the team identify the awareness timestamp, distinguish the applicable deadlines and explain who follows the case through to its final report? These are suggested checks, not additional CRA obligations. Their purpose is to expose operational gaps while keeping product-specific legal assessment separate from routine incident handling.
Sources: [1]
Sources
Your experience
Could your product-security and compliance teams identify the awareness timestamp and reporting owner for a potentially reportable issue today?
Originally published by AdviseISO, a knowledge-sharing initiative of W3 Solutionz.