Article 14 is two reporting duties, not one, and their final reports run on different clocks

On 11 September 2026, Article 14 of the Cyber Resilience Act starts applying. It arrives fifteen months before the rest of Regulation (EU) 2024/2847, which is generally applicable from 11 December 2027, and it does not wait for you to finish your conformity work.

That gap is the whole problem. A manufacturer who is nowhere near CE marking, who has no technical documentation and no conformity assessment, is still fully subject to Article 14 from September. Being mid-way through is not a defence to a missed 24-hour window.

Most summaries of Article 14 say the same thing: "24 hours, 72 hours, 14 days." That is one of the two sequences, and reading it as the whole Article produces three predictable errors:

• treating Article 14 as one duty when it is two, with different triggers,
• computing the 14-day final report from the moment you became aware, which invents a deadline the Regulation does not impose,
• watching CVEs only, when the second duty can fire with no vulnerability involved at all.

This is written for the person who will actually have to file, and the advisor who has to tell a client what September means.

• Decide whether you are a manufacturer of a product with digital elements placed on the EU market. If you are not, none of this applies, and that determination should be written down rather than assumed.
• Identify which CSIRT receives your filings. It is determined by main establishment under Article 14(7), not by where you incorporated.
• Write down two escalation paths, not one: actively exploited vulnerability, and severe incident.
• Fix the clock arithmetic in whatever runbook you have. The two final reports do not run from the same event.
• Assign the 24-hour duty to a rota, not to a person. A 24-hour clock that starts on a Friday night is the one that gets missed.
• Note that Article 14 binds products already on the market on 11 September 2026, not only what you ship afterwards.

The two duties

Article 14(1) covers an actively exploited vulnerability in your product. Article 14(3) covers a severe incident having an impact on the security of your product. They are separate obligations with separate triggers, and both notify simultaneously to the CSIRT designated as coordinator and to ENISA, via the single reporting platform established under Article 16.

The second one is the one teams miss, because a severe incident does not require a vulnerability. Article 14(5) defines it in two limbs, either of which is sufficient:

• it negatively affects, or is capable of negatively affecting, the ability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or
• it has led, or is capable of leading, to the introduction or execution of malicious code.

Read "or is capable of" carefully. An incident that could have had those effects qualifies even where it did not. A monitoring setup that only watches published vulnerabilities cannot see this category at all.

The two clocks, which are not the same shape

This is the part that gets reported wrong, and it is worth getting right because both sequences begin with an identical 24-hour early warning.

For an actively exploited vulnerability, Article 14(2):

For a severe incident, Article 14(4):

Two differences matter. The severe-incident final report is due within one month of the 72-hour notification, not 14 days. And the vulnerability final report runs from the remedy being available, not from awareness. A runbook that computes 14 days from awareness will file early against a deadline that does not exist, and will have nothing useful to say if the fix is not ready.

The 24-hour early warning for a severe incident also carries an extra field the vulnerability one does not: it must state at least whether the incident is suspected of being caused by unlawful or malicious acts.

The duty nobody reads, because it sits after the filings

Article 14(8) is a duty owed to users, not to a regulator. After becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer must inform impacted users, and where appropriate all users, of the vulnerability or incident, and where necessary of the risk mitigation and corrective measures they can deploy.

It sits after the notification paragraphs, which is exactly why it gets skipped. Filing correctly with your CSIRT and saying nothing to your customers is not compliance with Article 14. It is compliance with most of it.

Where your filing actually goes

Article 14(7) routes the notification to the electronic notification end-point of the CSIRT designated as coordinator in the Member State where you have your main establishment, meaning where decisions on product cybersecurity are predominantly taken. For manufacturers with no establishment in the Union there is a fallback sequence.

This is worth settling in advance, in writing. Twenty-four hours is not enough time to work out who to file with while also working out what happened.

One more clock you do not control

Article 14(6) lets the coordinating CSIRT request an intermediate report on status updates, where necessary. You cannot schedule that in advance and you cannot predict it. What you can do is make sure a process exists that is capable of answering it, which in practice means someone owns the incident record between the 72-hour filing and the final report.

What this means if you sell to manufacturers

If you advise product companies, September is a conversation you can open now with a date attached. Your client does not need to be CE-marked, does not need technical documentation, and does not need a conformity assessment to be caught by this. They need to be a manufacturer of a product with digital elements on the EU market, and they need a runbook by 11 September.

That is an unusually clean engagement: a fixed date, a bounded deliverable, and a client who cannot argue the deadline is 2027.

The obligations, with the text they rest on

Every duty above is in the CRA obligation map, each with the Official Journal text it comes from and the date it applies. The Article 14 page is reporting obligations of manufacturers.

Two things that may save you time before September:

• If you are not certain the CRA applies to you at all, the CRA scope check answers that in your browser, with the article each step rests on. It is free, needs no account, and stores nothing.
• If you only want the deadline arithmetic on one page, the Article 14 reporting clocks are set out with their sources.

None of this is legal advice, and a determination is a starting point rather than a conformity decision. Where it says the CRA applies, the obligations that follow are the manufacturer's, and no tool discharges them.