Cyber Resilience Act: 3 Urgent Deadlines From 11 September
On 11 September 2026 the first hard duty in the Cyber Resilience Act starts running, and it is not the CE marking everyone has been budgeting for. It is a 24-hour reporting clock, it applies to products you shipped years ago, and the platform you are supposed to report through has not published its address yet.
Every date, deadline and quotation below comes from the Official Journal text, from the European Commission’s own guidance of 27 July 2026, or from ENISA’s platform documentation last updated on 3 and 14 August 2026. Nothing here is legal advice — scope questions under this Regulation are genuinely hard, and the ones that turn on your specific product belong with counsel.
What the Cyber Resilience Act requires from 11 September
The Regulation is Regulation (EU) 2024/2847, and Article 71 sets out the phasing in two sentences. The Regulation “shall apply from 11 December 2027”. However, “Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026”.
Article 14 is the reporting article. From that date a manufacturer must notify any actively exploited vulnerability in its product, and any severe incident affecting the product’s security, simultaneously to the national CSIRT designated as coordinator and to ENISA. Three deadlines follow, and they are cumulative rather than alternative.
Within 24 hours of becoming aware: an early warning notification, indicating where applicable the Member States in which the manufacturer knows the product has been made available. Within 72 hours: a fuller notification covering the general nature of the vulnerability and the exploit, corrective or mitigating measures taken, and measures users can take. A final report no later than 14 days after a corrective or mitigating measure is available — or, for a severe incident, within one month of the 72-hour notification.
There is a fourth obligation that gets forgotten because it is not a deadline. Article 14(8) requires the manufacturer to inform the affected users of the vulnerability or incident and of any mitigation they can apply, “where appropriate in a structured, machine-readable format”. Reporting to the authorities does not discharge the duty to tell the people running your software.
The part of the Cyber Resilience Act with no grandfathering
This is the detail that catches people, and it is one sentence long. Article 69(2) says products placed on the market before 11 December 2027 are subject to the Regulation’s requirements only if they undergo a substantial modification after that date. Article 69(3) then removes Article 14 from that protection: the reporting obligations “shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027”.
The Commission’s guidance of 27 July 2026, C(2026) 5252, goes further at paragraph 210. Unlike the vulnerability-handling obligations, which run only for a product’s support period, “the reporting obligations continue to apply after a product with digital elements is no longer supported”.
Read that twice if you sell software. A product you stopped supporting in 2023, still in use somewhere in the EU, still generates a 24-hour reporting duty if you learn it is being actively exploited. Nothing about end-of-life switches it off.
Whether the Cyber Resilience Act makes you a manufacturer
“Manufacturer” sounds like it means factories. Article 3(13) defines it as anyone who develops products with digital elements, or has them developed, “and markets them under its name or trademark, whether for payment, monetisation or free of charge”. Making something available on the market, at Article 3(22), is supplying it for distribution or use on the Union market in the course of a commercial activity — again, “whether in return for payment or free of charge”.
So a twelve-person software firm that ships a desktop agent, a mobile app or a connected device under its own brand to a customer in the EU is a manufacturer. Money changing hands is not the test. Being established in the EU is not the test either: Article 18 says a manufacturer may appoint an authorised representative, and where a manufacturer has no main establishment in the Union, Article 14(7) simply routes its report by a cascade — the Member State of its authorised representative, failing that its importer, failing that its distributor, failing that where most of its users are.
The boundary that matters most to service businesses is cloud. Recital 43 draws it plainly: cloud functionality a manufacturer builds so that its own product works — controlling a smart home device remotely, for instance — is a remote data processing solution and is in scope. Websites that do not support a product’s functionality, and cloud services designed and developed outside a product manufacturer’s responsibility, are not. Software as a Service, Platform as a Service and Infrastructure as a Service are addressed by the NIS 2 Directive instead.
What counts as actively exploited, and when the clock starts
An actively exploited vulnerability is one for which there is reliable evidence that a malicious actor has exploited it in a system without the owner’s permission. A severe incident, under Article 14(5), is one that “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, or that has led or could lead to malicious code being introduced or executed in the product or in a user’s network.
The Cyber Resilience Act starts its clock when you become aware, and the Commission guidance is unusually specific about what that means. At paragraph 213, a manufacturer is regarded as having become aware when, after an initial assessment of a suspicious event or a third-party report, it has “a reasonable degree of certainty” that a vulnerability in its product is being actively exploited or that a severe incident has compromised its product’s security. Not proof. Not the end of the investigation. Reasonable certainty, after an assessment you are expected to perform promptly.
Two limits in the same guidance are worth knowing, because both cut the other way. Paragraph 217: there is no retroactive reporting — exploitation you already knew about before 11 September 2026 does not have to be notified, though a vulnerability you knew about that is first exploited afterwards does. Paragraph 218: a vulnerability in a third-party component that cannot be reached or has not been exploited in your product is not an actively exploited vulnerability contained in your product, and is not mandatory to report.
The platform you cannot log into yet
Article 16 puts ENISA in charge of a single reporting platform, so that a manufacturer reports once rather than to every affected Member State. ENISA’s own FAQ, updated 3 August 2026, says the platform “is scheduled to be operational by 11 September 2026” and that its public URL “will be communicated and published in due course on this page before the platform goes live”.
Three operational facts from that documentation matter more than the legal text, and none of them appear in the coverage of the Cyber Resilience Act we have read.
Reporting is done by named people. ENISA’s registration guidance describes a Primary Assigned Representative who registers, associates the account with a manufacturer, and invites a Secondary AR who holds an “AR Backup User” role. Both authenticate through EU Login. An invitation that is not accepted within seven days expires.
There is no API. Asked whether the workflow can be automated, the FAQ states that organisations might integrate reporting into their own systems, “however no Application Programming Interfaces will be provided at this stage”. Your first submission will be a person filling in a web form.
And ENISA explicitly advises against setting the account up in advance: manufacturers “are advised to register and initiate the validation process only when they need to submit a specific notification, rather than creating an account pre-emptively”, to avoid loading the CSIRTs with validation work. Registration is not a prerequisite for reporting, and validation happens in parallel — but it does mean the first time anyone at your organisation sees that flow will be inside the 24-hour window, on the worst day of your year.
The one thing you can do today without loading anyone: make sure the two people who would report already hold EU Login accounts, and that you know which CSIRT the cascade in Article 14(7) points you at. Both are free and neither creates a record anyone has to validate.
What changed since the Cyber Resilience Act was published
Three things, all of them dated, and one of them very recent.
Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 sets out the technical description of the important and critical product categories — identity management, VPNs, operating systems, firewalls and the rest. It decides your conformity assessment route in December 2027. It does not change your reporting duty, which applies at every risk tier alike.
Commission Delegated Regulation (EU) 2026/881 of 11 December 2025, published in the Official Journal on 20 April 2026, specifies when a CSIRT may delay passing your notification on to other CSIRTs. One ground is directly useful: where the manufacturer has told the receiving CSIRT that an effective mitigation “is expected to be made available within 72 hours”. Another applies where the notification itself contains enough detail to build an exploit. Say so in the notification; the discretion exists for you to invoke.
And the Commission’s guidance landed on 27 July 2026 — roughly three weeks before this was written, and six weeks before the duty starts. It is non-binding, about eighty pages, and worth more than any summary of it, including this one.
When the Cyber Resilience Act does not apply to you
Most organisations reading this are users of software, not manufacturers of it, and Article 14 says nothing to them. If you buy your systems rather than ship them, the Cyber Resilience Act is a procurement lever — ask a vendor who its Assigned Representatives are and watch the answer — not a compliance project.
The Regulation also carves out whole categories. Article 2 excludes products covered by the medical devices and in-vitro diagnostics Regulations, motor vehicle type-approval, certified civil aviation equipment and marine equipment; spare parts manufactured to replace identical components; and anything developed exclusively for national security or defence.
Non-monetised free and open-source software sits outside too. Recital 55 says the provision of open-source products “that are not monetised by their manufacturers should not be considered to be a commercial activity”, and neither regular releases nor corporate financial support makes it one. Stewards of open-source projects have a lighter regime of their own, and Article 64(10) removes administrative fines for them entirely.
Internal software is not in scope either. A line-of-business application your team wrote for your own staff is not being supplied on the market, so no reporting duty attaches to it — which does not make it safe, only unregulated. That distinction is the same one our note on POPIA compliance keeps drawing: a duty to notify a regulator and a duty to actually secure the thing are separate obligations with separate failure modes.
What we are not going to put a number on
The penalties are in the text and we will quote them: Article 64(2) provides for administrative fines of up to EUR 15,000,000, or 2.5% of total worldwide annual turnover if higher, for non-compliance with the essential requirements and with Articles 13 and 14. Article 64(10) then removes fines for micro and small enterprises specifically “with regard to any failure to meet the deadline referred to in Article 14(2), point (a)” — the 24-hour early warning, and only that one.
What we will not do is tell you how likely a fine under the Cyber Resilience Act is, what share of manufacturers are ready, or how many reports the platform will receive. Those figures are circulating and we could not trace a single one of them to measured data. A percentage with no method behind it is marketing wearing a lab coat, and it is exactly the kind of thing our writing on cyber insurance avoids for the same reason.
Where you are on the Cyber Resilience Act timeline
Before 11 September 2026. Decide whether any product you ship is in scope, name the two people who will report, get them EU Login accounts, and write down which CSIRT the Article 14(7) cascade sends you to. Half a day of work, and it is the only phase in which you get to do it calmly.
From 11 September 2026 to 10 December 2027. Reporting is live and retrospective in reach, while the essential requirements, the technical documentation and the CE marking are not yet due. This is the awkward middle: you can be fully compliant with Article 14 and nowhere near ready for the rest, and that is the correct state to be in for the next fifteen months.
From 11 December 2027. The whole Regulation applies. Conformity assessment, the EU declaration of conformity, the support period you have declared, the software bill of materials, and the CE marking on products with digital elements. Anything you place on the market after that date carries all of it, and the classification set by Implementing Regulation 2025/2392 decides whether you self-assess or involve a notified body.
The part with no expiry date
Strip the dates out and this is the same shape as every other published schedule we write about. The Cyber Resilience Act was in the Official Journal in November 2024. The reporting date has been fixed for nearly two years. The guidance arrived six weeks ahead, the platform documentation a month ahead, and a great many manufacturers will still meet all of it for the first time during an incident — exactly as happened with the certificate schedule we covered under TLS certificate lifetimes, which was also published years in advance and also maintained by almost nobody.
The durable asset here is not a compliance binder. It is a list: what we ship, under whose name, to which markets, who owns each one, and who is authorised to speak for us when something goes wrong at 02:00. That list answers this Regulation, the next one, and most of your customers’ security questionnaires — which is the argument our cybersecurity risk management work makes in every other context.
What to do in the next three weeks
Answer one question first, because the Cyber Resilience Act turns on it: does anything we supply, under our own name, run on somebody else’s hardware in the EU? If the answer is no, close this and go back to identity attacks, which will hurt you sooner. If it is yes, or you are not sure, the rest is a short afternoon.
List the products, including the ones you no longer support — Article 69(3) does not care that you stopped. Name a Primary and a Secondary reporter, and check both can sign in to EU Login today. Write a one-page procedure that says who performs the initial assessment, who decides that reasonable certainty has been reached, and who submits within 24 hours, including on a Sunday. Then read Section 9.1 of the Commission guidance, which is four pages and answers most of what is left.
If you would rather hand the estate to someone and get back the list, the procedure and an honest answer about scope, that is a conversation worth having. The dates in it will be the Official Journal’s, not ours.