ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
The CRA reporting deadline is the one date in the Cyber Resilience Act that most summaries get wrong. The Regulation is widely described as applying from 11 December 2027. That is true of most of it. It is not true of the part that will catch manufacturers first.
Article 14 of Regulation (EU) 2024/2847 applies from 11 September 2026 — and under Article 69(3) it reaches products that were placed on the market years ago. If you shipped a connected product in 2023 and no longer develop it, you may have a 24-hour reporting obligation attached to it from that date.
Article 14 creates two separate duties, each with a three-stage cascade. They can run simultaneously over the same facts, and their final-report deadlines are measured from different events — which is the single most common procedural error in implementing this article.
| Actively exploited vulnerability | Severe incident | |
|---|---|---|
| Trigger | Becoming aware of an actively exploited vulnerability contained in the product | Becoming aware of a severe incident having an impact on the security of the product |
| Stage 1 | Early warning — 24 hours | Early warning — 24 hours |
| Stage 2 | Vulnerability notification — 72 hours | Incident notification — 72 hours |
| Stage 3 | Final report — no later than 14 days after a corrective or mitigating measure is available | Final report — within one month after the incident notification was submitted |
Read the CRA reporting deadline for stage 3 twice. The vulnerability clock runs from the availability of a fix; the incident clock runs from the submission of the stage 2 notification. If remediation takes three months, the vulnerability final report is due 14 days after that — not 14 days after stage 2. Applying one rule to both duties will miss a deadline.
Every notification under the CRA reporting deadline goes simultaneously to the CSIRT designated as coordinator and to ENISA, through the single reporting platform established by ENISA under Article 16. There is no alternative channel. An email to a national authority does not discharge the obligation.
The definition has three parts and all must be met: there is reliable evidence that execution of malicious code was performed by an actor without permission of the system owner.
That excludes your own authorised testing. It also excludes a published proof of concept, by itself — a PoC is not evidence that anyone has run anything against a real system without permission. It does, however, raise the likelihood sharply enough that monitoring should step up immediately.
What does establish it: telemetry showing exploitation, a customer incident report naming the vulnerability, a credible CSIRT or third-party advisory reporting exploitation in the wild, or exploitation observed in your own hosted environment.
Article 14(5) sets two limbs, and either is sufficient.
(a) The incident negatively affects, or is capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions.
(b) It has led, or is capable of leading, to the introduction or execution of malicious code in the product or in the network and information systems of a user of the product.
Both limbs include a capability test. Actual harm is not required — an incident that could have led to malicious code execution but did not is within limb (b). Limb (a) also reaches “functions”, not only data, and includes authenticity, which does not appear among the Annex I product properties and has to be assessed separately.
This is where the real exposure sits. Every deadline in Article 14 runs from the manufacturer “becoming aware”. The Regulation does not define the term.
In a dispute, an authority will reconstruct the timeline from your own records — when the email arrived, when the ticket was raised, when the alert fired — and compare it with the awareness time you reported. Any gap has to be explicable.
A defensible working position is that awareness arises when information sufficient to identify a reportable event reaches someone who could reasonably be expected to recognise it as such. That has consequences worth accepting deliberately:
Record the determination for every event you assess, including the ones you decide not to report. A file containing only the events you reported cannot demonstrate that the others were considered. And record it contemporaneously — a determination written up a fortnight later, when the final report is being drafted, reads as a reconstruction.
The 24-hour stage asks for very little: who you are, the product, the Member States where you know it has been made available, and — for a severe incident — whether the incident is suspected of being caused by unlawful or malicious acts.
That last element is required at 24 hours, when the cause is usually unknown. State the current suspicion and its basis. “Not yet determined; no indicators of compromise identified at this time” is a complete and honest answer at that stage, and it is a far better one than a late notification.
Stages 2 and 3 exist precisely so that stage 1 does not have to be complete. Both open with “unless the relevant information has already been provided”, so nothing has to be repeated — but each stage still has to be addressed.
One element of stage 2 is easy to skip and worth taking: indicate how sensitive you consider the information to be. Under Article 16(2), dissemination of your notification to other Member States’ CSIRTs may be delayed on justified cybersecurity grounds, in particular on the manufacturer’s request and in light of the sensitivity you indicated. If you want that protection you have to ask for it, and give the CSIRT something to weigh.
Article 69(2) sets the general transitional rule. Products placed on the market before 11 December 2027 are subject to the requirements of the Regulation only if, from that date, they are subject to a substantial modification.
Then Article 69(3) derogates from it: by way of derogation from paragraph 2, the obligations laid down in Article 14 apply to all products with digital elements falling within the scope of this Regulation that have been placed on the market before 11 December 2027.
So a legacy product sits in two positions at once.
| Applies to a legacy product? | |
|---|---|
| Article 14 reporting | Yes — always, from 11 September 2026, modified or not |
| Essential requirements, conformity assessment, CE marking, user information, support period | Only if substantially modified from 11 December 2027 |
You may therefore have a catalogue of products that will never need CE marking under this Regulation, every one of which can generate a 24-hour obligation next month.
The good news is that reporting readiness for a legacy product is a much smaller job than compliance. It needs three things:
Where readiness cannot be achieved, the options are to invest, to withdraw, or to accept the exposure as a recorded decision by top management. Note that withdrawal is not a complete answer: Article 69(3) attaches to products already placed on the market, so ceasing supply does not remove units in the field.
Notifications go through the end-point of the CSIRT designated as coordinator of the Member State where you have your main establishment in the Union — defined as the Member State where decisions related to the cybersecurity of your products are predominantly taken. Not where you are incorporated, not where your headquarters are.
Where that cannot be determined, it is the Member State with the highest number of your Union employees. Where you have no Union establishment at all, Article 14(7) sets a cascade: the Member State of your authorised representative acting for the most products, then your largest importer, then your largest distributor, then where most of your users are. If you land on the last limb, you may keep reporting to the same CSIRT for subsequent events — take that option, because deriving it annually from shifting user numbers is worse than fixing a counterparty.
Determine this in advance and write it down. Working out which CSIRT to notify during the first 24 hours of an incident is a failure of preparation, not a task.
The CRA reporting deadline does not pause at weekends. An organisation that works office hours only, with no tested out-of-hours route, will breach Article 14 the first time a researcher’s email lands on a Friday evening.
Test the route end to end and record the elapsed time from simulated awareness to a submission-ready notification. If that exceeds a few hours in a rehearsal, it will exceed 24 in reality.
Filing under Article 14 satisfies Article 14. It does not satisfy:
Nor does any of those discharge Article 14. Track all of them from one entry.
Four things, in order:
The EU CRA Toolkit carries nine documents on Article 14 alone, including the awareness determination record, the two workflows kept separate, the legacy product readiness assessment, and the platform and CSIRT governance. The wider Regulation is covered in the EU CRA guide, and the conformity assessment position — which decides whether you need a notified body — in CRA conformity assessment.
August 16, 2026
August 16, 2026
August 16, 2026
August 16, 2026
August 16, 2026