Tomorrow, 11 September 2026, Article 14 of the European Union's Cyber Resilience Act begins to apply. From that date a manufacturer that becomes aware that a vulnerability in one of its products is being actively exploited has 24 hours to send an early warning to a national incident response team, 72 hours to follow it with a proper notification, and 14 days after a fix is available to file a final report. The same clock, with a one-month final report, runs for severe incidents affecting the security of a product. It is the first piece of the Act to bind manufacturers, and it is the piece with a stopwatch in it.
The best short framing of what this asks came, of all places, in a sponsored piece on BleepingComputer this week. Shane Warden of ActiveState reduced the whole regulation to a single question: "what shipped, and when did we first know there was a problem with it". His point was that engineers have always answered it, informally and under pressure; what is new is that from tomorrow it has to be answered to a regulator, on a clock. That is exactly right, and I want to spend this piece on why the second half of that question is the half that matters from tomorrow, why it reaches British companies that have never read a line of EU law, and what tomorrow does and, just as importantly, does not yet change.
What the Act is, in one breath
Regulation (EU) 2024/2847, the Cyber Resilience Act, is product law. It sits in the same family as the rules that put a CE mark on a kettle, and it treats software and connected hardware the way that family has treated physical goods for thirty years: the person who puts a product on the market answers for it. It was signed on 23 October 2024, published in the Official Journal on 20 November and entered into force on 10 December 2024. It applies to "products with digital elements", which the text defines as "a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately", where the intended or reasonably foreseeable use "includes a direct or indirect logical or physical data connection to a device or network". In practice that is almost anything with a processor or a package manager: the router, the smart lock, the firewall, the operating system, the desktop client, the library your developers pulled in on Tuesday. The carve-outs are the sectors with product rulebooks of their own, chiefly medical devices, cars, civil aviation and marine equipment, and free and open-source software that is not supplied in the course of a commercial activity.
The obligations are graded. Every product must meet the essential requirements in Annex I: shipped without known exploitable vulnerabilities, secure by default, updatable, and so on. Manufacturers must run and document a cybersecurity risk assessment, handle vulnerabilities for a support period that must be at least five years unless the product is expected to be in use for less, keep each security update available for at least ten years after it is issued, publish a coordinated vulnerability disclosure policy, and maintain a software bill of materials "covering at the very least the top-level dependencies". Most products are self-assessed. A list in Annex III of "important" products, which takes in password managers, browsers, VPNs, operating systems, routers, firewalls, hypervisors, and smart door locks and security cameras among others, carries heavier conformity duties, and a shorter Annex IV of "critical" products, hardware devices with security boxes, smart meter gateways and smartcards, may in time require certification. The Commission's Implementing Regulation (EU) 2025/2392, in force since 21 December 2025, fixes the technical descriptions of those categories around a product's core functionality; its own example is that embedding a browser in a news app does not make the news app a browser.
Three dates carry the whole thing. Chapter IV, on the notification of the conformity assessment bodies that will carry out third-party assessments, has applied since 11 June 2026. Article 14, the reporting obligation, applies from tomorrow. Everything else, the essential requirements, the CE marking, the market surveillance authorities and the fines, applies from 11 December 2027. So what starts tomorrow is not the Act. It is one article of it. But it is the article that asks the question.
What actually changes at midnight
Article 14 obliges a manufacturer to notify two things. The first is any "actively exploited vulnerability" contained in its product that it becomes aware of, which the Act defines as a vulnerability "for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner". The second is any "severe incident having an impact on the security of the product with digital elements", meaning 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 the introduction or execution of malicious code in the product or in a user's network.
Both notifications go, simultaneously, to the CSIRT designated as coordinator in the manufacturer's home Member State and to ENISA, the EU's cyber security agency, and both go through a single reporting platform that ENISA is required to build and run. The early warning within 24 hours needs little: which product, that exploitation is under way, and, where the manufacturer knows, which Member States the product has been made available in. The 72-hour notification adds the general nature of the vulnerability and of the exploit, what has been done about it, and what users can do. The final report, due 14 days after a corrective or mitigating measure is available, carries severity, impact, anything known about who exploited it and details of the fix; for an incident it is due one month after the 72-hour notification and carries the likely root cause and the mitigation instead. In parallel, Article 14(8) requires the manufacturer to inform the users affected, and where appropriate all users, of the vulnerability and of anything they can do about it; and if it does not do so in good time, the CSIRTs may tell the users themselves.
Two limits are worth stating, because the mythology has run ahead of the text. This is not a duty to report every vulnerability. The Commission's implementation FAQ is explicit that a zero-day found by a bug-bounty researcher or a test laboratory, with no evidence of malicious use, "is not an actively exploited vulnerability subject to mandatory reporting"; it may be notified voluntarily under Article 15. Nor does the duty land on everyone in the software ecosystem. It lands on the manufacturer, meaning whoever markets the product under its own name or trademark, "whether for payment, monetisation or free of charge". An importer or distributor that rebadges a product under its own brand, or substantially modifies one, becomes the manufacturer for these purposes under Article 21. Open-source software stewards, the foundations and companies that sustain projects intended for commercial use, carry a lighter regime, and the Commission's FAQ, in an entry added on 4 September, confirms that their version of the reporting obligation under Article 24(3) does not apply until 11 December 2027.
When did you know
The 24-hour and 72-hour deadlines in Article 14 are both measured from one moment: the moment the manufacturer "becomes aware". The Regulation does not define it. The Commission's guidance on the application of the Act, approved on 27 July 2026 and running to 67 worked examples, does. It is not binding, formal adoption waits on the translations, and only the Court of Justice can settle the meaning of the text; but it is the Commission's reading, and it is the one manufacturers will be working to for the next fifteen months. A manufacturer is to be regarded as having become aware "when, after such an initial assessment, it has a reasonable degree of certainty" that a vulnerability in its product is being actively exploited, or that a severe incident has compromised the product's security. The guidance borrows the test deliberately from the NIS2 implementing rules and from the data protection board's breach-notification guidelines, so that a company subject to all three is not running three definitions. And it adds the sentence that should be read aloud in every engineering leadership meeting this month: the manufacturer "should assess the suspicious event immediately", and "the emphasis should be on prompt action".
Notice what that does. "Reasonable degree of certainty" is not a loophole; it is a description of a process the manufacturer must be able to show it ran. The triage step that turns a tip-off into awareness is now a legally significant event, and its timestamp is the thing on which everything else depends. ENISA's platform is designed around exactly that. Its field list makes "Date/time when you become aware of the Actively Exploited Vulnerability" a required field of the early warning, carried forward into every later stage. And then comes the footnote that tells you more about the state of the machinery than any press release: "This field will be available in the next release of the Platform." ENISA's own FAQ, updated on 9 September, adds that the platform's 72-hour counter currently shows a due time 48 hours after the early warning is submitted, and will be recalculated from the awareness timestamp "in a future release". So the one field on which the entire regulation turns is the one the platform will start asking for after it opens. That does not move the legal clock by a minute. It means that for the first weeks, or months, the only record of when a manufacturer knew will be the manufacturer's own, which is a reason to keep a very good one.
The FAQ is generous about how a company might come to know. A customer or partner reports unusual activity. A researcher publishes a report of a zero-day being used in targeted attacks. A government agency notifies the vendor. An ethical hacker reports something already being exploited in the wild. And, in a paragraph I read twice, "the manufacturer's telemetry system or honeypot" indicates exploitation of a previously unknown vulnerability in the manufacturer's product. I have run honeypots without a break since 1998. For twenty-eight years what they showed me was interesting. From tomorrow, what they show a vendor about its own product starts the assessment, and the assessment starts the clock.
Two further points matter more than they look. First, there is no retroactive reporting. The guidance says a manufacturer that already knew, before 11 September, that a vulnerability was being exploited does not have to notify it. But a vulnerability the manufacturer knew about before tomorrow, whose exploitation it learns of after tomorrow, is reportable in full: every vendor with a backlog of unfixed but so far unexploited flaws is carrying a set of clocks that have not yet started. Second, third-party components count. If an actively exploited vulnerability in a library or a chip is exploited in your product, you must report it, and the FAQ adds that the component's own manufacturer, if it placed the component on the market, must report it too. The one exception is where the vulnerable code cannot be reached in your product, or has not been exploited in it. To claim that exception inside 24 hours you have to know, quickly and with evidence, whether the vulnerable component is in the product at all.
That is the first half of Warden's question arriving through the back door. The formal obligation to maintain a software bill of materials does not apply until December 2027. The ability to answer "is this in what we shipped?" inside a day is needed from tomorrow. The Linux Foundation and OpenSSF readiness report published in June found that only 32% of manufacturers produce bills of materials for all of their products, a figure unchanged from the year before; that 66% of respondents were unfamiliar or at best slightly familiar with the Act, up from 62% a year earlier; and that just 41% of manufacturers expected to be fully compliant by December 2027. Warden's suggested test is the right one and I would set it as homework: "Pick a product your team shipped 6 months ago, and time how long it takes someone to tell you what's in it and when you first knew about the last critical CVE inside it. If that takes longer than 72 hours, you already have your answer."
The estate already in the field
Here is the part boards most often get wrong, because it runs against the intuition that new law applies to new products. For reporting, it does not. Article 69(3) says in terms that the reporting obligations apply to all in-scope products "that have been placed on the market before 11 December 2027". The guidance goes further: "the reporting obligations continue to apply after a product with digital elements is no longer supported". The FAQ acknowledges the practical difficulty, that the build environment may be gone, the dependencies unavailable, the engineers who knew the code departed, and answers it without sentiment: for such products the manufacturer must still notify, though it is not required to fix.
So the question tomorrow is not "what are we shipping next year?" It is "what have we ever shipped into the EU that is still connected to something?" The router range discontinued in 2021, the industrial controller with a decade of field life ahead of it, the firmware nobody has touched since the acquisition: if it is exploited in the wild and you come to know it, the clock runs. For a UK manufacturer with a long tail of legacy product on the Continent, this is the paragraph to read twice.
The plumbing, on the eve
A reporting duty is only as real as the place you report to, so it is fair to look at the state of the machinery tonight. ENISA's page for the Single Reporting Platform says that from 11 September 2026 it "will be used by CSIRTs and manufacturers for mandatory reporting", and its FAQ, updated on 9 September, finally gave the address, portal.cra-srp.enisa.europa.eu, with the note: "The portal will be available from 11 September 2026." The same update says the platform "underwent several user, security and technical testing exercises" with national CSIRTs, the Commission's expert group and selected manufacturers, and that ENISA "does not currently foresee additional testing before go-live". The list of coordinating CSIRTs for all 27 Member States went up on 4 September: CERT-Bund at the BSI for Germany, CERT-FR for France, the NCSC in Ireland and its namesake in the Netherlands, INCIBE in Spain, and so on. There is a factsheet and step-by-step registration guidance. So the door exists, and it opens on the day the duty starts, with, as we have seen, one important field still to be fitted.
What the guidance tells you is how the thing will work. Access is by EU Login with multi-factor authentication, and the accounts are personal: the FAQ is explicit that there is no corporate authentication, so the people who will file are the people who must register. Each manufacturer nominates one primary "assigned representative", who picks the coordinating CSIRT from a drop-down, accepts a legal agreement and enters the company's details; up to 20 secondary representatives are invited by email once the primary has been verified, and an invitation expires after seven days. The CSIRT validates the association after the fact, and validation is deliberately not a prerequisite for filing: an unvalidated representative can submit up to 20 notifications before it becomes mandatory. There is no API at launch, so "notifications must be submitted through the platform interface", which means that however automated the pipeline behind it, a human will be typing into a browser at the end. Only mandatory reporting is switched on in the first phase; voluntary reporting under Article 15 follows later. If the platform is unavailable, ENISA's answer is to wait and file when it returns, contacting your CSIRT directly in the meantime if the matter cannot wait, and then filing anyway. There is a helpdesk at cra-srp-helpdesk@enisa.europa.eu, which ENISA says exists especially for smaller companies.
Once filed, the receiving CSIRT passes the notification without delay to the CSIRTs of every Member State the manufacturer has said the product is available in. The exceptions were fixed in Delegated Regulation (EU) 2026/881, adopted in December and in force since 10 May: a CSIRT may hold a notification back, for no longer than strictly necessary and only where the risk of circulating it outweighs the benefit, on grounds that include the manufacturer expecting a fix or user guidance within 72 hours, the notification being detailed enough to amount to an exploitation technique in itself, or a coordinated disclosure in which that CSIRT is the trusted intermediary. The Regulation itself provides a narrower "particularly exceptional circumstances" flag, available where a vulnerability has been exploited in one Member State only, where wider dissemination would damage a state's essential interests, or where it would pose an imminent high risk; when it is used, ENISA receives only the outline of the notification until the CSIRT releases the rest. ENISA will, in agreement with the manufacturer, publish fixed vulnerabilities to the European Vulnerability Database, and the Commission must report to Parliament and the Council on how well the platform has worked by 11 September 2028.
One thing this platform is not is the single door the Commission has since proposed for all EU incident reporting. The Digital Omnibus, tabled on 19 November 2025, would build on it to give companies one entry point for their obligations under NIS2, the GDPR, DORA and other acts. It is still a proposal. For the foreseeable future, tomorrow's platform is the platform.
Applicable, or enforceable?
I want to be careful with a word that is being used loosely this week. From tomorrow, Article 14 applies: it is the law, directly, in 27 countries, and a manufacturer that ignores it is in breach. But the machinery that punishes breach is in the later tranche. Article 71(2) brings forward only Article 14 and Chapter IV, and leaves everything else, including Article 64 on penalties and Chapter V on market surveillance and enforcement, to 11 December 2027; the Commission's FAQ says so in plain words: "the provisions on market surveillance and enforcement, as well as all the other provisions set out in the CRA, apply from 11 December 2027". When they do, non-compliance with Article 14 sits in the top tier, up to €15 million or 2.5% of worldwide annual turnover, whichever is higher, with two carve-outs: micro and small enterprises cannot be fined for missing the 24-hour early-warning deadline, and open-source stewards cannot be fined at all.
So what does tomorrow mean, if the fine is fifteen months away? Four things, and none of them is small.
The first is the record. Every notification filed from tomorrow names a product and a version, says which Member States it is known to be available in, and sits on a platform shared by 27 CSIRTs and ENISA; and once the awareness field is fitted, it carries the time the manufacturer knew. When the market surveillance authorities switch on in December 2027, they will inherit fifteen months of evidence about who reported what and when, and, by comparison with the public record of exploitation, who did not. Whether conduct before that date can be penalised is a question for lawyers, and penalties are rarely retrospective; whether it will shape how an authority regards a manufacturer is not. A vendor whose product appears in CISA's catalogue of exploited vulnerabilities in March 2027 with no corresponding notification will find that its silence has a date on it.
The second is the users. Article 14(8) is live tomorrow too, and it gives the CSIRTs the power to tell your customers about your vulnerability if you do not. For a vendor, the calculus around an exploited flaw has changed: the choice is no longer whether it becomes known but whether you are the one who says so.
The third is liability, which arrives through a different door. The new Product Liability Directive treats software as a product, makes the manufacturer liable without proof of fault for damage caused by a defect, including one that arises from the lack of a security update, and must be in national law by 9 December 2026 for products placed on the market after that date. The Commission is careful to say the two regimes do not overlap, and the Act itself says that the mere act of notifying does not increase the notifier's liability. But a court asked whether a product offered the safety a person was entitled to expect will find the absence of a notification, when the exploitation was public knowledge, a very convenient piece of paper.
And the fourth is the door I wrote about when DORA followed British firms home: contract. Your customers in the EU, the banks under DORA and the essential entities under NIS2, have reporting clocks of their own, and they are already writing yours into procurement. The Act's timelines will reach many UK vendors as a schedule to a master services agreement long before they reach them as a letter from a regulator.
The view from this side of the Channel
A British company can be forgiven for filing this under "EU". It should not. The Act attaches to the product and the market, not the headquarters: a manufacturer is anyone who markets a product under its name, and the reporting duty applies to anyone whose product is made available in the Union. There is no size threshold and no requirement to have an EU entity. A UK software house that ships its product to customers in Dublin and Amsterdam is a manufacturer under Article 14 from tomorrow.
The Act does think about where a foreign manufacturer reports. Article 14(7) sends a company with no main establishment in the EU to the CSIRT of the Member State where its authorised representative sits, failing that the Member State of the importer that places most of its products on the market, failing that of the distributor that makes most of them available, and failing all three, the Member State with the most users of its products. An authorised representative, incidentally, is optional; Article 18 says a manufacturer "may" appoint one, and while the representative can hold the documentation and deal with the authorities, the Act does not allow the design, risk-assessment and vulnerability-handling duties of Article 13 to be delegated to it. For many UK firms whose European presence runs through Ireland, the coordinating CSIRT will turn out to be the NCSC in Dublin.
Northern Ireland is the question I am asked most, and the answer has moved this year. The Windsor Framework applies listed EU product law in Northern Ireland, and the Government's first explanatory memorandum on the Act, in December 2024, took the view that its substantive provisions are "freestanding rather than amending or replacing provisions already listed in Annex II of the Windsor Framework, and therefore would not apply to Northern Ireland"; only the Act's amendments to the market surveillance and two- and three-wheeler regulations fall within the Framework as it stands, and those were judged to have "limited practical impact in isolation". Since then the EU has moved to change that. Council Decision (EU) 2025/799 of 14 April 2025 fixed the EU's position to propose, in the Withdrawal Agreement Joint Committee, that the Act be added to Annex 2 of the Framework, and the Government's second memorandum, in May 2026, set out the UK's position: agreement "could only take place following a meeting of the Joint Committee", ministers cannot agree unless the Northern Ireland Assembly passes an applicability motion with cross-community consent (or the narrow exceptions in domestic law apply), and "any decision to apply the substantive elements of the CRA through Article 13(4) would still require agreement from the UK, subject to domestic law". The Specialised Committee recorded on 7 May that its exchange of views on the Act was concluded and would go to the next Joint Committee. I can find no Joint Committee decision adding it. So tomorrow the Act does not apply in Northern Ireland; but the question of whether it will is live, formally tabled, and waiting on Stormont as much as on Brussels.
Against this the UK has a product regime of its own, and the comparison is instructive rather than flattering. The PSTI regime, in force since 29 April 2024 and enforced by the Office for Product Safety and Standards, requires three things of consumer connectable products: passwords that are unique to the product or set by the user, a published way to report security issues, and a published minimum period for security updates. It is a good floor. It does not reach business-only products, does not reach standalone software, does not require a bill of materials, and does not require a manufacturer to tell anybody in government when its product is being exploited. The Software Security Code of Practice that DSIT and the NCSC published last year covers more ground but is, by design, voluntary. The Cyber Security and Resilience Bill, now in the Lords, would write a 24-hour clock into UK law, but for the regulated entities that suffer an incident, the operators of essential services, the digital and managed service providers, the data centres, not for the manufacturers of the products through which they were attacked. I argued this week that the Bill misses the one lever that works; it also, as of tomorrow, leaves open a gap the EU has closed. From tomorrow, the CSIRTs of Europe will be told, within a day, when a widely used product is being exploited. No law will require the vendor to tell the NCSC in London anything. It will hear, as it always has, through goodwill and the grapevine.
There is a practical consequence for UK buyers as well as sellers. The products most exploited at the network edge this year, the firewalls, VPN gateways and remote-access appliances that filled August's threat landscape, and the security appliances that had us patching FortiSandbox to a Sunday deadline, are exactly the kinds of product the Act lists as important. Their manufacturers will be reporting to EU CSIRTs from tomorrow. A UK customer of those products should ask them, this week, which CSIRT they have registered with, who their assigned representative is, and how they intend to meet the duty to inform users, because Article 14(8) speaks of "the impacted users" and attaches no geography to them.
What good looks like on Friday morning
Strip away the drafting and the defensible position is not exotic. It is knowing, for every product you sell into the EU, that you are the manufacturer and which CSIRT is yours, and having the EU Login accounts, with multi-factor authentication, for a primary and a secondary representative set up before you need them. It is a written definition of "aware" inside your own incident process: who runs the initial assessment, what "reasonable degree of certainty" looks like for your products, and who has the authority to start the clock at three in the morning, with the timestamp recorded as a matter of routine. It is an inventory good enough that the question "is the vulnerable component reachable in what we shipped?" can be answered with evidence in hours, for current products and for the tail. It is intake: a coordinated disclosure policy and a single point of contact that a researcher can find, and a habit of watching the exploited-vulnerability catalogues and your own telemetry for your own products. It is a notification template that mirrors the platform's fields, so that the early warning is a copy-and-paste rather than a composition. It is the user communication under Article 14(8) drafted in advance, and the habit, ahead of Article 13(6) making it a duty in December 2027, of reporting upstream to whoever maintains the component. And it is a rehearsal: one tabletop, this month, with a real product and a 24-hour clock on the wall.
For boards
Three questions for the next meeting. For every product we sell into the EU, do we know that we are the manufacturer under this Act, which CSIRT we would report to, and who in this company is registered to do it? If a customer, a researcher or our own telemetry told us at 03:00 tomorrow that a vulnerability in a product we shipped four years ago was being exploited, could we say with evidence by 09:00 what was in it, and who would decide that we were "aware"? For the product lines we sell only in Britain, where no such duty exists, would we be comfortable telling a customer that we would take longer to tell them than European law would give us?
The closing observation
I have spent most of my career on the receiving end of exploited products: in the SOC, watching the exploitation arrive; in the honeypots, watching it being tried; in the boardroom, explaining afterwards why the vendor's advisory came three weeks after the first intrusion. The Cyber Resilience Act's fines are fifteen months off, its harmonised standards are late, its platform opens on the day the duty starts with its most important field still to come, and a great many of the companies it binds have not heard of it. All of that is true, and none of it is the point. From tomorrow, the person who made the product answers, on the record and against a clock, for what time they knew. That is the question the customer has always wanted to ask and never had the standing to. I would rather see it asked imperfectly, with the apparatus still being bolted together, than continue not to be asked at all.
This is general information for directors and operators, not legal advice; whether and how the Act reaches a particular product or company turns on the facts, and the position should be confirmed with your advisers.