For many organisations, the CRA is still associated with December 2027. That is when the regulation becomes broadly applicable to products with digital elements placed on the EU market. But the first operational obligations arrived earlier, and they are already in force.
Why does 11 September 2026 matter more than December 2027?
The July 2026 Commission guidance confirms that the reporting obligations also apply to products already placed on the market before 11 December 2027. So the immediate question is no longer only whether your organisation can demonstrate full CRA conformity by 2027. It is whether it can detect, assess, escalate and report a product-security event under tight deadlines today.
Could your organisation determine, document and report a CRA-relevant product-security event tomorrow?
What must be reported, and how fast?
| Trigger | Within 24h | Within 72h | Final report |
| Actively exploited vulnerability | Early warning | Vulnerability notification | No later than 14 days after a corrective or mitigating measure is available |
| Severe incident affecting product security | Early warning | Incident notification | Within one month after the incident notification |
Notifications are submitted through ENISA’s Single Reporting Platform. Impacted users must also be informed and, where necessary, given measures to reduce their risk.
Why is this a leadership issue, not only a compliance task?
At first glance, reporting sounds like a legal or compliance activity. In practice, the report is only the visible output of a much broader security process. Before a manufacturer can report, it needs to know which products and versions are affected, whether exploitation is really occurring, which users may be impacted, what mitigations exist, and who is authorised to decide.
Legal and compliance teams remain important, but they cannot create the underlying technical evidence after an incident has started. A large compliance function cannot compensate for weak product visibility, unclear ownership or slow technical triage.
Five questions to ask your teams this week
- Which of our products are in CRA scope, including products already on the market?
- Who owns the decision to report?
- Could we determine active exploitation within 24 hours?
- Do we know how ENISA and the designated CSIRT coordinator fit into our workflow?
- Could we prove the timeline of awareness, triage, approval, submission and user communication?
Leadership needs assurance that the process works in practice, not only that a policy exists.
The good news: the building blocks already exist
Most organisations do not need to invent new security disciplines. Vulnerability management, product security incident response, threat modelling, software inventories, incident response and secure development practices are familiar. The challenge is to connect them into one operational process that produces timely decisions, reliable evidence and proportionate communication.
Want to know where you stand? Our experts can help you check whether your organisation could meet the CRA reporting obligations today.
» CRA Reporting Readiness Check
Frequently asked questions
Do the CRA reporting obligations apply to products already on the market? Yes. According to the July 2026 Commission guidance, they apply from 11 September 2026, including to products placed on the market before 11 December 2027.
When does the 24-hour clock start? When, after an initial assessment, the manufacturer has a reasonable degree of certainty that a vulnerability is actively exploited or that a severe incident has compromised the security of the product. Not at every vague signal.
Where are reports submitted? Through ENISA’s Single Reporting Platform, which passes the information to the relevant national CSIRT coordinator, such as the CCB in Belgium.
This article offers a practical security reading of the CRA and the Commission guidance. It is not legal advice.