The Cyber Resilience Act applies in full from 11 December 2027, but not everything waits for that date. From 11 September 2026, six weeks from now, manufacturers of products with digital elements will have to notify actively exploited vulnerabilities and severe incidents within 24 hours of becoming aware of them, through a single platform run by ENISA. On 27 July the European Commission published its guidance on how to apply the regulation and, on the same day, ENISA updated its own answers about the platform. The obligation has a fixed date; the tools for meeting it are arriving now.
What applies on 11 September, and what does not
Article 71 of Regulation (EU) 2024/2847 sets three dates, not one. The regulation applies from 11 December 2027; Chapter IV, that is Articles 35 to 51 on the notification of conformity assessment bodies, applies from 11 June 2026; Article 14, which governs the reporting obligations of manufacturers, applies from 11 September 2026. What becomes due on 11 September is therefore neither the essential cybersecurity requirements of Annex I, nor conformity assessment, nor CE marking: it is the reporting obligation alone.
That sequence has a consequence worth putting on the record. Article 64 sets the ceiling for a breach of Article 14, namely administrative fines of up to 15 million euro or, where the offender is an undertaking, up to 2.5 per cent of its total worldwide annual turnover for the preceding financial year, whichever is higher. That article, however, applies together with the rest of the regulation from 11 December 2027. The duty to report comes fifteen months before the penalty regime that backs it, and before market surveillance as well, yet it remains a full legal obligation with a 24 hour deadline.
Two triggers, three deadlines
Article 14 identifies two triggering events. The first is an actively exploited vulnerability contained in the product, of which the manufacturer becomes aware. The second is a severe incident having an impact on the security of the product. In both cases the notification must be submitted simultaneously to the CSIRT designated as coordinator and to ENISA, through the single reporting platform established under Article 16.
For vulnerabilities there are three deadlines. An early warning without undue delay and in any event within 24 hours of becoming aware, indicating, where applicable, the Member States in whose territory the product has been made available. A vulnerability notification within 72 hours, setting out general information on the product concerned, the general nature of the exploit and of the vulnerability, any corrective or mitigating measures taken and those users can take, together with the degree of sensitivity the manufacturer attaches to the information notified. A final report within 14 days of a corrective or mitigating measure being made available, describing the vulnerability, its severity and impact, whatever is known about the malicious actor and the details of the security update. For severe incidents the scheme is the same, with two differences: the 24 hour early warning must indicate at least whether the incident is suspected of being caused by unlawful or malicious acts, and the final report is due within one month of the 72 hour notification.
What counts as a severe incident is set out in paragraph 5, and the definition is broad: an incident qualifies if 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 if it has led or is capable of leading to the introduction or execution of malicious code in the product or in a user’s network and information systems. Paragraph 8 adds a second recipient: from the moment it becomes aware of the facts, the manufacturer must also inform the affected users and, where appropriate, all users, if necessary in a structured, machine-readable format. If it fails to do so promptly, the CSIRTs that received the notification may do it instead.
The obligation covers what is already on the market
The least visible point sits in the transitional provisions. Article 69(2) provides that products placed on the market before 11 December 2027 are subject to the requirements of the regulation only if, from that date, they undergo a substantial modification. Article 69(3), however, introduces an express derogation: the obligations laid down in Article 14 apply to all products with digital elements falling within the scope of the regulation that were placed on the market before 11 December 2027. The reporting perimeter is therefore not the future catalogue but the installed base, including what was sold years ago and is still supported.
The same logic drives the extension in personal scope: ENISA notes that open source software stewards are also subject to reporting obligations, to the extent that they are involved with products. For anyone with a long catalogue and a long history, the first task is not technical but a matter of inventory, namely knowing which supported products fall within scope and who answers for each of them.
There is one channel, and it has no address yet
Article 16 tasks ENISA with establishing the single reporting platform and running its day to day operations, with an architecture allowing Member States and the Agency to set up their own electronic notification endpoints. Article 14(7) specifies that the notification is submitted through the endpoint of the CSIRT designated as coordinator of the Member State where the manufacturer has its main establishment in the Union, and simultaneously to ENISA. No alternative channel is provided: the platform is how the obligation is discharged.
In the answers updated on 27 July, ENISA states that the platform is scheduled to be operational by 11 September 2026 and that a testing period is expected before that date. The public address is not yet known and will be published on the same page before the platform goes live. Access will require an EU Login account, which can be created in advance; the validation that a given person may report on behalf of a given manufacturer will be carried out by the coordinating CSIRT after first access, in parallel with the reporting process and without preventing it. To avoid overloading CSIRTs, ENISA advises registering and starting validation only when a specific notification actually has to be submitted.
What is missing is the implementing act that Article 14(10) allows the Commission to adopt in order to further specify the format and procedures for submitting notifications: as at 31 July 2026 no such act appears to have been adopted. The only second level act published is Delegated Regulation (EU) 2026/881, in force since 10 May 2026, which sets the terms and conditions of the cybersecurity grounds on which a CSIRT may delay circulating a notification to other CSIRTs.
The Commission guidance, and what it weighs
The guidance published on 27 July consists of Communication C(2026) 5252 and its annex. It clarifies when certain products fall within scope, including remote data processing solutions and free and open source software; what constitutes a substantial modification; how support periods should be understood and applied; and how to meet reporting obligations and risk assessment requirements. Those are precisely the four matters that Article 26 requires the Commission to address when it issues guidance, with particular attention to microenterprises and small and medium-sized enterprises. The document contains 67 practical examples, use cases and flowcharts, and ENISA points out that section 9.1 explains in detail the reporting obligations of manufacturers and open source software stewards.
The Commission expressly describes the guidance as non-binding and announces that, in line with Article 26, it will consider issuing further guidance. The qualification matters: guidance reduces interpretive uncertainty, it does not move a date and it does not replace the text. It is worth reading alongside the maturity assessment model ENISA published on 13 July for small and medium-sized enterprises, because the stated audience is the same.
Six weeks, and what can be done now
The dates do not move, and the guidance does not move them. What a manufacturer can do between now and 11 September does not depend on the platform opening: identifying which coordinating CSIRT is competent on the basis of the main establishment in the Union, preparing EU Login credentials, taking stock of the supported products that fall within scope, including those placed on the market years ago. Above all, deciding who inside the organisation has the authority to characterise a fact as an actively exploited vulnerability or a severe incident and to start the notification. The 24 hours run from awareness, not from the fix, and before it is a technical problem this is a question of decision making chains, of the same kind that the European framework is moving towards the boardroom. The Cyber Resilience Act timetable is, after all, the mirror image of the AI Act one, where the technical tool arrived ahead of the deadline: here it is the obligation that arrives first.
