Cyber Resilience Act: 24 hours to report, and the clock does not start with the CVE

The Cyber Resilience Act has sat on everybody's calendar for two years with one date written on it: 11 December 2027. What almost nobody had noted down is that today a single article — Article 14 — starts to apply, and that it is the only one the regulation itself stretches backwards so that it reaches everything you have already sold. As of this morning, a manufacturer has 24 hours to file the first warning about a vulnerability somebody is exploiting. And the deadline does not start when the CVE is published or when the news breaks: it starts when you find out. Which makes it a lawyers' matter only in part. The rest is who reads what, and at what time of day. And it starts on a Friday.

What starts today, and what does not

Article 71 of Regulation (EU) 2024/2847 says three things in two lines: the regulation applies from 11 December 2027, Article 14 from 11 September 2026, and Chapter IV (notified bodies) from 11 June 2026. That is all. Today you are not bound by CE marking, the essential requirements in Annex I, the declaration of conformity or the support period. Today you are bound by one thing: telling somebody what is happening to you, the right somebody, on time.

The only article that looks backwards

Here is the detail we think matters most today and have barely seen discussed. Article 69(2) contains the good news everybody repeats: what you placed on the market before 11 December 2027 is not subject to the regulation, unless from that date it undergoes a substantial modification. That is the paragraph that has reassured a lot of people with an old catalogue. The very next paragraph, 69(3), opens literally with "by way of derogation from paragraph 2" and states that the obligations laid down in Article 14 shall apply to all products with digital elements within scope that were placed on the market before 11 December 2027.

Translated: that version you sold in 2019 and that is still installed at fourteen customers does not have to meet a single technical requirement of the CRA. But if somebody is exploiting it and you find out from today onwards, you have 24 hours. The limit is worth adding, because it has had to be clarified too: if you already knew before today that it was being exploited, there is no duty to report backwards. What starts the clock is finding out, full stop. The legislator installed the sensor first and the product rules second. Without the sensor, nobody knows what is going on out there.

The clock: 24, 72 and 14

• 24 hours — early warning. Without undue delay and in any event within 24 hours of the manufacturer becoming aware. Minimum content: indicate, where applicable, which Member States your product is available in. That field, which looks bureaucratic, is the one that catches out a lot of people who do not have the list.
• 72 hours — notification. General information about the product, the general nature of the exploit and of the vulnerability, corrective or mitigating measures taken and measures users can take, plus an indication of how sensitive you consider the notified information to be.
• 14 days — final report. And here is a nuance almost everyone gets wrong: the 14 days do not run from the warning, they run from the moment a corrective or mitigating measure is available. If there is none, that clock has not started. The other two have.
• Severe incident: same 24 and 72, but the final report goes to one month from the 72-hour notification. And the CSIRT may ask you, where necessary, for an intermediate report along the way.

Two phrases decide whether it applies to you

The first one is in Article 3. The regulation defines separately an "exploitable vulnerability" — one that has the potential to be effectively used by an adversary under practical operational conditions — and an "actively exploited vulnerability", which is a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner. Only the second one starts the clock. And notice what the difference rests on: "reliable evidence". Not a suspicion, not a headline; evidence. If your product produces no logs that let you confirm or rule that out, you are not calmer. You just cannot see.

The second phrase is in paragraph 5, the one defining when an incident is "severe": when it 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 when it has led or is capable of leading to the introduction or execution of malicious code. In other words: the regulation does not measure the damage done, it measures capability. The near miss counts too. That is the sentence that will surprise more than one person the first time they have to decide, at eleven at night, whether that thing "was nothing".

Paragraph 8, which almost nobody has read

All the coverage these past days is about the three deadlines pointing towards the authorities. Article 14 has one more paragraph, number 8, and it is the one that interests us most as people who make a living keeping things running: after becoming aware, the manufacturer shall inform the impacted users — and where appropriate all users — of the vulnerability or incident and, where necessary, of the measures they can deploy; where appropriate, in a structured, machine-readable format. And then comes the sentence: "where the manufacturer fails to inform the users in a timely manner, the notified CSIRTs may provide such information to the users" when considered proportionate and necessary.

Our reading, not the regulation's: that sentence weighs more than the fine. A penalty takes years and your legal adviser sees it. Having the CSIRT tell your customers about a problem of yours that you had not told them about gets around the same afternoon, and it shows at the next renewal. If you have to choose where to start building this, start there: with how you give notice, not with how you fill in the form.

We opened the form

The notification does not go by email: it goes through the single reporting platform established by Article 16 and operated by ENISA. We logged in today at 17:05 Spanish time: portal.cra-srp.enisa.europa.eu responds. It landed on time, which over the summer looked doubtful. What is on the other side, according to ENISA's own FAQ, is worth knowing beforehand rather than with the clock running:

• You get in with an EU Login account with multi-factor authentication, and accounts are personal: whoever files uses their own. There is a primary assigned representative and secondary ones, with different permissions.
• The representative-to-manufacturer association is validated by the designated CSIRT, and ENISA warns that the procedure and processing time vary between CSIRTs and remain each one's responsibility. Verification runs in parallel and does not prevent filing while pending.
• There is no API in the initial release: you file by hand, through the interface. And voluntary reporting under Article 15 is not available yet either; it will come in a later phase.
• If you pick the wrong coordinator CSIRT, the notification may be invalidated and has to be resubmitted to the right one. With a 24-hour deadline, that is not an administrative detail.
• The 72-hour counter is wrong in this release, and ENISA says so plainly: it shows the due date 48 hours after you submit the early warning, so a notification can be displayed as overdue before 72 real hours have passed. They will fix it later by calculating it from the date you became aware. In the meantime, the deadline that counts is yours, not the traffic light on the screen.
• If the platform is unavailable, ENISA says to wait until it is back; you may contact your CSIRT directly if urgency demands it, but the notification must still be submitted through the platform once it returns.

And one ENISA recommendation we half disagree with. To avoid flooding CSIRTs with validation work, it advises registering and starting validation only when you need to file. You can see why they say it, and they add that with an active EU Login account, signing up takes a few minutes. But on the day you need to file you will have 24 hours, a room full of nervous people and, quite probably, the person who holds the account will be away. The EU Login account with MFA, for at least two people, we would create today. It is free and it makes work for nobody.

Who does a Spanish company notify?

The CSIRT designated as coordinator of the Member State where the manufacturer has its main establishment in the Union. And note how paragraph 7 defines that, because it is not the registered office: it is the Member State where the decisions related to the cybersecurity of its products are predominantly taken. If that cannot be determined, the one with the establishment holding the highest number of employees in the Union. With no establishment in the Union, there is a cascade of four criteria: authorised representative, importer, distributor and, last, where most users are located. For a group with development split across two countries, that is a real question worth answering in writing beforehand, not at three in the morning.

For Spain, the list of coordinator CSIRTs published by ENISA points to INCIBE-CERT, with two separate addresses: one for incident response and one for vulnerability coordination. That matches the split we already know — INCIBE-CERT for private entities, CCN-CERT for the public sector — and it arrives, incidentally, with the NIS2 transposition still going through parliament. The CRA is a regulation and waits for nobody: it applies directly. We already wrote about that asymmetry when what was arriving was the NIS2 supplier questionnaire, and it is happening again.

And if I am not a manufacturer?

The regulation calls a manufacturer anyone who develops or has developed a product with digital elements and markets it under its own name or trademark, and adds a rider that changes the answer for many: "whether for payment, monetisation or free of charge". The plugin you give away counts too. And "product with digital elements" includes, by definition, its remote data processing solutions: the cloud-side part without which the product could not perform one of its functions. That is where many software companies discover their service is not as "pure SaaS" as they thought, and also where others confirm they are outside. That line is drawn by a lawyer with your contract in front of them, not by us.

If you are not a manufacturer and only buy software, nothing binds you today. But two things change for you. First: you will get more notices, and sooner, some about products you had long forgotten, and somebody has to read them and decide. Second: your suppliers have a new, concrete obligation as of today, and that can go into a contract in one line. We would write it like this: "in the event of an actively exploited vulnerability or a severe incident with an impact on the security of the product, the supplier shall inform everyWAN within a maximum of X hours of becoming aware, on the terms of Article 14(8) of Regulation (EU) 2024/2847". It is the same question the NIS2 questionnaire was already asking, but now with a rule behind it.

The fine going around, and its small print

The figure that has been in the press these days is correct and worth putting in context. Article 64(2) places non-compliance with Article 14 in the top band, the same one as the essential requirements in Annex I: up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher. Put another way: failing to report on time is priced the same as building insecurely. Now the small print, also in the same article: the actual penalty rules are laid down by the Member States, and paragraph 10 exempts microenterprises and small enterprises from fines for missing the 24-hour deadline — only that one; the 72-hour notification and the final report do not appear in the exemption. Curiously, that exemption is drafted as a derogation from paragraphs 3 to 9, and the Article 14 fines sit in paragraph 2. We are not lawyers and we are not going to interpret that: if your plan depends on that exemption, have somebody who is take a look at it.

What we would set up, in order

1. Write down what "becoming aware" means in your company, and who declares it. It is the piece nobody hands you and the one everything else hangs from. We land it on something prosaic: a timestamped ticket. The moment it opens is the moment the clock started, and that timestamp is your evidence. Without it, a year from now nobody will be able to say whether the warning went out in 20 hours or in 40.
2. One single front door, and make sure it is watched. A published security mailbox, a disclosure policy on your website and a real on-call rota behind it. Half the time the warning does not come from your telemetry: it comes in an email from an outsider. If that email lands in a shared inbox read on Mondays, your 24-hour deadline is fiction.
3. The list of what you sell and where. The 24-hour warning asks for the Member States where the product is available. Live versions, customers by country, which third-party component each one carries. If this does not exist, the first hour of the crisis goes into rebuilding it, and that hour came out of the deadline.
4. Two EU Login accounts with MFA, created today. They cost nothing and remove the piece of paperwork that hurts most with an incident on top of you. And with them, decided and written down, which coordinator CSIRT is yours under the Article 14(7) test — where your product's cybersecurity decisions are actually taken — not the one where your registered office is.
5. Telemetry that lets you say "reliable evidence" without crossing your fingers. Logs that survive the incident, somewhere the attacker cannot delete them, and enough signal to tell exploited from exploitable. Without it, the notification ends up written out of guesswork.
6. Rehearse it on an ordinary Tuesday. One hour, a made-up scenario and the stopwatch running: who declares awareness, who drafts, who logs into the platform, who writes to customers. What is not rehearsed does not exist, and we have written that in other words about the continuity plan nobody has rehearsed. A notification procedure with no drill is exactly the same thing: a document.

Notice that of the six points, four are not about cybersecurity: they are about organisation. The same happens with nearly all the European regulation of these two years. When we wrote about what actually applied from the AI Act on 2 August we ended up in the same place: the hard part comes afterwards, and it is having written down who decides what, and in how long.

What we are not claiming

We are not lawyers and this is not legal advice: everything above is a direct reading of the regulation's text, which is public and anyone can check, plus ENISA's operational documentation. We have not filed any notification through the platform — we have none to file, fortunately — so the only thing we can assert about it is that it responds today and what its FAQ says. We do not know how many Spanish companies fall within scope and we are not estimating it. Nor are we saying the platform will fail: we are saying the regulation does not condition the deadlines on it working, and that ENISA has settled that in writing by telling you to wait and file anyway afterwards. And a warning about ourselves: everyWAN sells compliance and continuity services, so we have an obvious interest in this worrying you. That is why we have cited it article by article: so you check the text rather than believe us.

Note on sources

Every fact in this post was checked on 11 September 2026 against the text of Regulation (EU) 2024/2847 (the Cyber Resilience Act), read article by article: Article 3 (definitions 1, 2, 13, 41 and 42), the whole of Article 14 (the three deadlines for actively exploited vulnerabilities and for severe incidents, the minimum content of each notification, the intermediate report in paragraph 6, the main-establishment test and the cascade in paragraph 7, and the duty to inform users in paragraph 8), Article 16 (single reporting platform, dissemination and its exceptions), Article 64 (penalty bands and the paragraph 10 exemption for microenterprises and small enterprises), Article 69 (paragraphs 2 and 3, transitional regime) and Article 71 (application dates: 11 December 2027 in general, Article 14 from 11 September 2026 and Chapter IV from 11 June 2026). The operational part comes from documentation published by ENISA: the single reporting platform page and its FAQ (registration via EU Login with MFA, primary and secondary assigned representatives, validation by the designated CSIRT with times that vary between CSIRTs, verification running in parallel without preventing filing, no API in the initial release, Article 15 voluntary reporting unavailable at launch, invalidation of the notification if the wrong CSIRT is selected, what to do if the platform is unavailable, and the advice to register only when you need to file) and its list of CSIRTs designated as coordinators, which for Spain points to INCIBE-CERT. The application date and the platform's operational status also appear on the European Commission's CRA reporting obligations page. Commission Delegated Regulation (EU) 2026/881 of 11 December 2025 is the one setting out the grounds for delaying dissemination of notifications under Article 16(2). The check that portal.cra-srp.enisa.europa.eu responds is ours, done today at 17:05 Spanish time. The following is OUR reading, not the sources': that Article 14 is the only one the regulation stretches backwards and what that implies for an old catalogue; that paragraph 8 weighs more than the fine; that the "reliable evidence" definition turns compliance into a telemetry problem; the disagreement with ENISA's advice on when to register; the proposed contract clause; and the six points on the list. The cover photograph is "Echo Wall Clock", by bfishadow, published under a Creative Commons CC BY 2.0 licence.