From 11 September 2026, Article 14 of the Cyber Resilience Act turns a security finding into a filing deadline. Not a policy. Not a control. A clock that starts without asking you, fifteen months before the rest of Regulation (EU) 2024/2847 applies.
Most teams have now read the deadlines. Far fewer have walked the week. This post does the second thing: one hypothetical vulnerability, discovered on a Tuesday morning, followed from the moment somebody notices to the moment the file closes. If you want the legal structure first, read Article 14 is two reporting duties, not one. This is the operational half.
Most runbooks fail in three predictable ways:
- Nobody owns the word "aware". The 24-hour clock runs from awareness, and if awareness is undefined it gets decided retrospectively by whoever is being asked why the filing was late.
- The runbook assumes a weekday. A 24-hour clock that starts at 18:00 on a Friday is the one that gets missed, and it is not a smaller obligation for having started inconveniently.
- It stops at 72 hours. Two duties survive the notification: telling your users under Article 14(8), and a final report whose clock has not started yet.
Written for the person who will actually file, and for the advisor who has to tell a client what September means.
TL;DR, what to do today (60 minutes)
- Write down who can declare awareness, by role, and what evidence that declaration is recorded against.
- Confirm your coordinating CSIRT. It follows your main establishment under Article 14(7), not your place of incorporation.
- Start ENISA platform registration now. The Single Reporting Platform is not live yet, and registration is not something you can do at hour one.
- Draft the 24-hour filing as a form with blanks, not as a document to be written under pressure.
- Assemble the Member State list for each product you place on the EU market. The 24-hour notification asks for it and nobody has it to hand.
- Put the 24-hour duty on a rota, not on a named person.
Run the free CRA reporting readiness check if you want the gaps listed rather than guessed. It needs no account and stores nothing.
The scenario
You make a product with digital elements that is placed on the EU market. On Tuesday at 10:15, a support engineer escalates a customer report: something in the wild is being used against your authentication flow, and it is working.
Nothing about that sentence is a filing yet. Everything after it is timed.
The final report is the row people get wrong. It does not run from Tuesday. It runs from the day a corrective or mitigating measure is available, which may be next week or may be next month.
Tuesday, 10:15 to about 12:00: deciding that you are aware
The Regulation gives you no definition of awareness, which means your definition is the one that will be examined. Two failure modes sit here.
The first is deciding awareness too late on purpose, by routing the report into a triage queue and treating the clock as starting when an engineer confirms it. That is a decision you will have to defend in writing.
The second, and the more common one, is having no moment at all: three people know something and none of them believes they are the person who knows it officially.
Real-world example: a support ticket says "customers are reporting logins they did not make". Engineering treats it as a support issue for two days while support waits for engineering. There is no single hour anyone can point to, so the honest answer to "when did you become aware" becomes Tuesday, and you have already missed Wednesday.
The fix is unglamorous. One named role, reachable on a rota, who can say the words and start a timestamped record. Our reporting workflow and responsibility matrix is the version we use, and it is public.
Wednesday, 10:15: the early warning
Article 14(2)(a) requires an early warning notification of the actively exploited vulnerability, without undue delay and in any event within 24 hours of becoming aware, indicating where applicable the Member States on whose territory you are aware the product has been made available.
Read what that does and does not ask for. It does not ask for a root cause. It does not ask for a fix, a CVE, a severity score, or a patch date. It asks that you say something is being exploited, and where your product is.
The Member State list is the part that surprises teams. It is a distribution question, not a security question, and the person who can answer it is usually in sales operations or channel management rather than in the incident channel. Answer it once now, per product, and keep it current. At hour twenty-two it is a phone call you cannot make.
Real-world example: a firmware vendor sells through three distributors into eleven Member States. Their incident lead can describe the exploit in two sentences and cannot name a single Member State without opening a CRM they do not have access to. The technical half of the filing takes ten minutes and the commercial half takes six hours.
The notification goes simultaneously to the CSIRT designated as coordinator and to ENISA, through the single reporting platform under Article 16.
Friday, 10:15: the vulnerability notification
Article 14(2)(b) is due within 72 hours of awareness, and it asks for more, though still in the register of "as available":
- general information about the product concerned,
- the general nature of the exploit and of the vulnerability,
- any corrective or mitigating measures you have taken,
- corrective or mitigating measures users can take,
- where applicable, how sensitive you consider the notified information to be.
That fourth item is the one to prepare in advance, because it is the only line in the Article that your customers will read back to you. "Disable the affected endpoint until further notice" is a mitigation users can take. "We are investigating" is not.
The sensitivity indication is a right you should use deliberately. It exists so that a filing made in the middle of an active exploitation does not become the thing that spreads it.
The clock that has not started
If no corrective or mitigating measure is available on Friday, no final-report deadline exists yet. That is not a grace period. Article 14(6) lets the coordinating CSIRT request an intermediate report on status updates whenever it considers it necessary, and you cannot predict that request.
What you can do is make sure the incident record stays owned between the 72-hour filing and the eventual final report. In practice that means it does not go back into the sprint board.
When a measure is available, the final report is due within 14 days of that availability, and Article 14(2)(c) sets its minimum contents: a description of the vulnerability including its severity and impact; where available, information about any malicious actor that exploited it; and details of the security update or other corrective measures made available.
The duty that has no deadline and the largest blast radius
Article 14(8) requires you to inform impacted users, and where appropriate all users, of the vulnerability, and where necessary of the risk mitigation and corrective measures they can deploy. It carries two clauses that get skipped.
First, it says where appropriate in a structured, machine-readable format that is easily automatically processable. If your only customer channel is a status page written by hand, you should read that clause now rather than in the week you need it.
Second, if you fail to inform users in a timely manner, the notified CSIRTs may provide that information to your users themselves, where they consider it proportionate and necessary. Silence does not keep the incident private. It only removes you from the room where it is described.
If it is a severe incident instead
The same Tuesday can produce the other duty. Article 14(3) covers a severe incident having an impact on the security of the product, defined in Article 14(5) as one that negatively affects, or is capable of negatively affecting, the product's ability to protect availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led or is capable of leading to the introduction or execution of malicious code.
Three practical differences from the vulnerability track:
- the 24-hour early warning must state at least whether the incident is suspected of being caused by unlawful or malicious acts,
- the 72-hour filing asks for an initial assessment, not only a description,
- the final report is due within one month of the 72-hour notification, not 14 days from a fix.
No vulnerability is required for any of this. A monitoring setup that watches CVEs cannot see this duty at all.
Where the filing goes, and why to settle it this week
Article 14(7) routes your notification to the electronic end-point of the CSIRT designated as coordinator in the Member State of your main establishment in the Union, which the Regulation defines as where decisions on the cybersecurity of your products are predominantly taken. Where that cannot be determined, it is the Member State with your largest EU headcount.
If you have no main establishment in the Union, the Article sets an explicit fallback order: the Member State of the authorised representative acting for the most products, then the importer placing the most on the market, then the distributor making the most available, then where the most users are. Under that last limb you may keep reporting subsequent events to the same CSIRT you first reported to, which is worth taking if it applies to you.
Settle this in writing now. Twenty-four hours is not enough time to determine a legal routing question and describe an exploit.
What is not ready on the regulator's side
Checked 2 September 2026. ENISA's Single Reporting Platform is not yet live. ENISA's own page says the platform "will be used by CSIRTs and manufacturers for mandatory reporting" as of 11 September 2026 onwards, and it now publishes onboarding guidance for assigned representatives: user registration and notification submission, both updated 3 August 2026, and interface functions, updated 14 August 2026, plus a factsheet in English.
The honest reading: the reporting duty starts on a date certain, and the mechanism you must use to discharge it is arriving on the same date. Do not plan to discover the registration flow during your first incident. Work through the ENISA guidance now, while nothing is on fire, and confirm your end-point with your national CSIRT.
The takeaway checklist
Nine items. If all nine are true before 11 September, you have a runbook rather than an intention.
- A named role, on a rota, can declare awareness and start a timestamped record.
- The coordinating CSIRT for your main establishment is identified in writing, with the Article 14(7) reasoning recorded.
- ENISA platform registration is under way, with a named assigned representative.
- A Member State availability list exists per product and has an owner who keeps it current.
- The 24-hour template exists with blanks, and somebody has filled it in once as a dry run.
- The 72-hour template includes a field for measures users can take, written in customer language.
- Article 14(8) user notification has a channel, and somebody has checked whether a machine-readable format is appropriate for your product.
- The severe-incident branch is in the same runbook, including the unlawful-or-malicious-acts question.
- Somebody owns the incident record between the 72-hour filing and the final report.
FAQ
Does Article 14 apply to products already on the market on 11 September 2026?
Yes. Article 14 applies from 11 September 2026 to manufacturers of products with digital elements placed on the EU market, and it does not carve out products that shipped earlier. Being mid-way through conformity work is not a defence to a missed 24-hour window.
Do I need to be CE marked before Article 14 applies to me?
No. The rest of Regulation (EU) 2024/2847 applies from 11 December 2027. Article 14 arrives fifteen months earlier and does not wait for technical documentation, a conformity assessment, or a CE mark.
When exactly does the 24-hour clock start?
From the manufacturer becoming aware of the actively exploited vulnerability, under Article 14(2)(a). It does not start when a scan runs, when a ticket is triaged, or when a fix is scoped. Because the Regulation does not define awareness, your own written definition is what will be examined.
Is the final report due 14 days after I become aware?
No, and this is the most commonly repeated error about Article 14. For an actively exploited vulnerability the final report is due no later than 14 days after a corrective or mitigating measure is available. For a severe incident it is due within one month of submitting the 72-hour notification.
What if I have no establishment in the European Union?
Article 14(7) sets a fallback order: the Member State of your authorised representative for the most products, then your largest importer, then your largest distributor, then where most of your users are. Determine it before September rather than during an incident.
Sources
- Regulation (EU) 2024/2847, Article 14, on EUR-Lex: ELI and CELEX 32024R2847
- The obligation, with the Official Journal text it rests on: reporting obligations of manufacturers
- The full CRA obligation map, each entry with the Official Journal text it rests on and the date it applies: CRA rule pack
- Not sure the CRA applies to you at all: the CRA scope check runs in your browser, free, with no account
Legalithm materials are operational guidance only and do not constitute legal advice.
Disclaimer
Legalithm materials are operational guidance only and do not constitute legal advice. A determination is a starting point rather than a conformity decision. Where the CRA applies, the obligations are the manufacturer's, and no tool discharges them.
