The EU Started a 24 Hour Clock on September 11. If You Ship Connected or AI Enabled Equipment to Europe, It Covers Machines You Already Sold.

1. What changed for manufacturers on September 11, 2026?

On September 11, 2026, Article 14 of the EU Cyber Resilience Act became applicable. From that date, any manufacturer of a product with digital elements sold in the EU has to notify European authorities when it becomes aware that a vulnerability in that product is being actively exploited, or that a severe incident has hit the product’s security. The CRA’s main product security, vulnerability handling and conformity obligations apply from December 11, 2027. Reporting came fifteen months earlier, and it is live now.

The EU Cyber Resilience Act, Regulation (EU) 2024/2847, is the European Union’s horizontal cybersecurity law for hardware and software products that connect to a device or network. Its first operative duty, Article 14, requires manufacturers to report actively exploited vulnerabilities and severe incidents through ENISA’s Single Reporting Platform. The first notice is due within 24 hours of awareness, and the duty applies to products already on the market.

The timing comes straight from the regulation. Article 71(2) of the Cyber Resilience Act says the regulation applies from December 11, 2027, “However, Article 14 shall apply from 11 September 2026.” The European Commission confirmed the start in its September 11 announcement. It stressed that the reporting obligations apply “to all products with digital elements made available in the EU, including those already on the market.”

ENISA, the EU cybersecurity agency, switched on the filing system the same day. Its launch notice describes the initial operating capability of the Single Reporting Platform and says ENISA will keep expanding the platform “over the coming months.” In other words, the clock is running on a filing system that is itself still being built. That is one more reason not to leave your first filing until the day you need it.

This article is written for the small and mid sized US manufacturer that sells connected equipment, controllers, sensors, vision systems or embedded software into Europe. That covers direct sales and sales through an EU distributor. If you have read our earlier piece on Tier 1 AI questionnaires and the EU Machinery Regulation, think of this as the incident response chapter that piece did not cover.

2. Does the reporting duty apply to a small US manufacturer?

Yes, if you make or have made a product with digital elements that is sold in the EU under your name or trademark, Article 14 applies to you regardless of company size or where you are headquartered. The CRA has no general small business exemption from Article 14. Company size affects certain support, proportionality and penalty provisions, which section 7 covers.

Three definitions do most of the work. Article 3(1) defines a product with digital elements as “a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately.” Article 2(1) limits the regulation to products whose intended purpose or reasonably foreseeable use “includes a direct or indirect logical or physical data connection to a device or network.” Article 3(13) defines the manufacturer as the person who develops or manufactures the product, or has it made, “and markets them under its name or trademark, whether for payment, monetisation or free of charge.”

That combination generally captures far more of a typical machine builder’s catalog than most owners expect, subject to the statutory exclusions and the requirement that the product is made available in the course of a commercial activity. A packaging line with an Ethernet port to a plant historian is generally in scope. So, typically, are a CNC retrofit kit with a USB configuration interface and a torque controller that pushes data to a cloud dashboard. A firmware tool you give away can be covered too, because Article 3(22) reaches supply “whether in return for payment or free of charge,” but giving it away does not by itself settle whether it is supplied in the course of a commercial activity. The word “indirect” matters too. A device that only talks to a gateway, which then talks to the network, still has an indirect data connection.

The exclusions are narrow and sector specific. Article 2 carves out products covered by the EU medical device and in vitro diagnostic regulations, motor vehicle type approval under Regulation (EU) 2019/2144, certified civil aviation products, marine equipment, products built exclusively for national security or defence or specifically designed to process classified information, and identical spare parts. Free and open source software supplied outside any commercial activity also falls outside the regulation’s market scope. A general industrial equipment maker will rarely fit any of these.

Two further rules widen the net. First, Article 69(3) applies Article 14 “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.” That means every unit you have already shipped to Europe. Second, the Commission’s guidance on applying the CRA, published July 27, 2026 as C(2026) 5252, states at paragraph 210 that “the reporting obligations continue to apply after a product with digital elements is no longer supported.” A controller you stopped patching in 2022 can still generate a 2026 reporting duty.

The contract manufacturing row deserves a caution. Being outside Article 14 does not mean being outside the problem. A brand owner with a 24 hour clock needs facts from whoever wrote the firmware or assembled the board. Expect that requirement to show up in supply agreements as a flow down clause with its own short deadline.

3. Why is AI enabled equipment squarely in scope?

AI enabled industrial equipment is in scope because almost all of it depends on a data connection. Models need inputs, updates and somewhere to send results, and that connection is the CRA’s test for coverage. Adding AI to a product rarely takes it out of the CRA. It usually adds attack surface the manufacturer now has to watch.

The most important provision for AI products is the definition of remote data processing. Article 3(2) describes it as data processing at a distance “for which the software is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions.” Picture a defect detection camera that sends images to a model your company hosts in the cloud. If the camera cannot grade parts without it, the hosted inference service is very likely part of your product.

The Commission’s guidance makes this concrete for industrial equipment. Its Example 55 describes a complex industrial machinery product whose cloud back end the Commission treats as a remote data processing solution, and therefore as part of the product. The practical consequence follows directly. A severe incident in your AI cloud service, such as an intrusion that lets an attacker tamper with the model’s outputs to customers’ machines, can be a severe incident affecting your product. It is not merely an IT event at your hosting provider.

The AI software stack is also now showing up in the exploitation data. By our count of the CISA Known Exploited Vulnerabilities catalog data feed of September 30, 2026, the catalog held 1,730 entries, with 246 added so far in 2026. Eleven of them were for AI application orchestration, model gateway and machine learning operations software: Langflow, LiteLLM, MLflow and Ray. That grouping is our own classification, not a CISA category. Ten of those eleven were added in 2026. Manufacturers that embed open source AI frameworks in an edge device or a support portal should treat that trend as a direct signal.

AI also brings weakness classes that traditional firmware reviews were never built to catch. The OWASP Gen AI Security Project’s Top 10 for LLM Applications lists prompt injection first, followed by sensitive information disclosure and supply chain risk. Suppose a maintenance assistant on an HMI can be made to issue commands it was never meant to issue. That reads naturally as a weakness that “can be exploited by a cyber threat,” which is the CRA’s definition of a vulnerability in Article 3(40). No regulator or court has yet ruled on that application. It is our reading of the text, and it is the conservative way to run your triage.

One provision ties the two European regimes together directly. Article 12 of the CRA says that products with digital elements classified as high risk AI systems under the AI Act “shall be deemed to comply with the cybersecurity requirements set out in Article 15” of the AI Act when they meet the CRA’s Annex I essential requirements. The deeming is limited. It applies only where the product meets the CRA’s Annex I requirements, the manufacturer’s processes comply, and the EU declaration of conformity demonstrates the level of cybersecurity the AI Act requires. It expressly leaves the AI Act’s accuracy and robustness requirements untouched, and it says nothing about the rest of the AI Act. Section 8 returns to how the timelines interact.

4. What actually starts the 24 hour clock?

The 24 hour clock starts when the manufacturer becomes aware, after an initial assessment, with 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. It does not start the moment a rumor arrives, and it does not wait for a full investigation to finish.

Two definitions set the threshold. Article 3(42) defines an actively exploited vulnerability as one “for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.” Article 14(5) treats an incident as severe where it affects, or is capable of affecting, the product’s ability to protect “the availability, authenticity, integrity or confidentiality of sensitive or important data or functions.” It is also severe where 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.

The awareness test comes from the Commission guidance, not the regulation itself. That guidance is expressly nonbinding, but ENISA’s own platform FAQ points reporters to it. Paragraph 213 says a manufacturer receiving a suspicious report “should assess the suspicious event immediately.” It is regarded as aware when, after that initial assessment, “it has a reasonable degree of certainty” that exploitation or a severe incident has occurred. The guidance aligns that reading with the GDPR breach notification guidelines and NIS2 implementing rules. A team that has handled a personal data breach will recognize the logic.

There is a real limit on retroactivity. Paragraph 217 says a manufacturer “is not required to report vulnerabilities of whose active exploitation it had already become aware before 11 September 2026.” But if you knew of a flaw before that date and only learned of its exploitation after it, the flaw is now reportable. Write down today what you knew and when. That record is your evidence if the timing is ever questioned.

Third party components are the trickiest part, and the guidance is helpful here. Paragraph 218 says an exploited flaw that originates in a third party component and is exploited in your product must be reported by you. A flaw that “cannot be exploited” in your product, because the vulnerable code is unreachable, is not a mandatory report for you. Neither is one that “has not been exploited” in your product. The catalog shows why this matters. It listed 31 Linux kernel entries at September 30, 2026, three of them added after September 11. A kernel flaw appearing on that list is a trigger to assess, not an automatic filing.

Article 13(6) runs in parallel and applies even when no report is required. When you identify a vulnerability in an integrated component, including an open source one, you must report it to whoever maintains that component. Strictly, most of Article 13 applies from December 11, 2027. Building the habit now costs little, and it is what a well run response team does anyway.

5. What goes into each of the three reports?

Article 14 requires three staged submissions for each event: an early warning, a notification and a final report. Each one adds detail to the last, so a 24 hour early warning can be thin. ENISA’s platform is built around a single record that you update at each stage, rather than three separate filings.

The early warning is designed to be filed before you know everything. Each deadline is an outer limit, because Article 14 requires every submission “without undue delay and in any event within” the stated hours, so waiting until hour 23 is not automatically compliant. A timely early warning containing the required information you have is better than one held back until the investigation is complete. The regulation says each later report is due “unless the relevant information has already been provided,” so you can fold stages together when you already know enough.

Reporting to authorities is only half the duty. Article 14(8) requires you to inform “the impacted users,” and where appropriate all users, of the vulnerability or incident and of any mitigations they can apply. If you fail to do it “in a timely manner,” the CSIRTs may notify your users themselves. For an industrial manufacturer, that means an EU national cyber agency could contact your customer’s plant manager before you do.

The Commission softens how this works in practice. Guidance paragraph 220 says the user notice is to be applied in a risk based and proportionate way, and that it “does not imply that such information must be made public.” That matters for equipment in sensitive or essential environments, where publishing technical detail could help an attacker. A targeted notice to affected customers is often the sensible route. User notification and public vulnerability disclosure are separate processes, and the timing of any public disclosure depends on the risk, whether a mitigation exists and coordination with the CSIRT. From December 11, 2027, Annex I Part II separately requires public disclosure of fixed vulnerabilities once a security update is available.

6. Where does a manufacturer outside the EU file?

Every CRA report goes through ENISA’s Single Reporting Platform, addressed to one national CSIRT acting as coordinator and shared at the same time with ENISA. A manufacturer without an EU establishment picks that CSIRT using a fixed order of tests set out in Article 14(7).

The order runs like this. First comes the Member State where your authorised representative is established, if you have one acting for the largest number of your products. If not, it is the Member State of the importer that places the most of your products on the market. If neither applies, it is the Member State of the distributor that makes the most of your products available. Failing all three, it is the Member State with the highest number of your users. Most US manufacturers selling through a European distributor will land on the third or fourth test. Make the decision once, document why, and record it in your incident plan.

Access requires preparation even though platform registration does not. ENISA’s platform FAQ, updated October 3, 2026, says each Assigned Representative needs a personal EU Login account with multi factor authentication, which can be created in advance. A manufacturer has one Primary Assigned Representative, who registers by selecting the coordinating CSIRT and entering the company’s details, and up to 20 Secondary Assigned Representatives, whom the Primary invites. CSIRT validation of that association runs in parallel and does not block filing while it is pending.

Germany’s Federal Office for Information Security, BSI, adds in its September 11 release that registration and submission “can be completed in a matter of minutes” and that reports must be written in English. Hogan Lovells’ client alert walks through the same mechanics.

Minutes still matter when the window is 24 hours. Create the EU Login accounts now for your intended primary and backup reporters, and keep the manufacturer details the platform asks for on file. Do not register on the platform or start CSIRT validation early, though. ENISA advises manufacturers to do that only when they need to submit a notification, to limit the validation workload on CSIRTs.

Keep your own clock as well. The same FAQ says the platform’s counters “do not replace the responsibility” of manufacturers to meet the Article 14 deadlines. In the current release, the 72 hour counter shows a due time 48 hours after the early warning is submitted, not 72 hours after awareness. Track every legal deadline from your own awareness timestamp.

Do not assume your EU importer or distributor will file for you. Article 14 places the reporting duty on the manufacturer, and any filing arrangement you agree with a partner does not move that responsibility. Articles 19 and 20 do require importers and distributors to inform the manufacturer “without undue delay” when they become aware of a vulnerability. But those articles fall under the general December 11, 2027 application date, so a distributor’s duty to tell you is not yet legally in force. Put it in your distribution agreement now. Note also that some vendor marketing claims distributors already have Article 14 duties as distributors. The regulation text does not support that. The exception is Article 21, which treats an importer or distributor that sells a product under its own name or trademark, or substantially modifies it, as the manufacturer for Articles 13 and 14.

7. What are the penalties, and does the small business exemption help?

Article 64(2) sets a fine ceiling of EUR 15 million or 2.5 percent of total worldwide annual turnover, whichever is higher, for Article 14 failures, but on the plain text of Article 71(2) that fine framework generally applies from December 11, 2027, not today. Qualifying small companies also get a narrow exemption covering only the 24 hour early warning deadline, not the reporting duty itself.

The timing point needs care. Article 71(2) applies only Article 14 and Chapter IV early, and Article 64 is not on that list. Some commentators nonetheless read Article 64(2)’s express reference to Article 14 as making fines available from September 11, 2026, and no court or authority has resolved the question. Either way the duty to report is binding now, a CSIRT can contact your users directly if you do not, and contractual and other regulatory exposure can run in parallel. Treat the gap, if there is one, as time to build the process, not as permission to skip it.

The exemption has a drafting history worth knowing because it trips up even law firm summaries. As first published on November 20, 2024, Article 64(10) began “By way of derogation from paragraphs 3 to 9.” That wording left the top tier fine in paragraph 2, the one tied to Article 14, outside the exemption. A corrigendum published in the Official Journal on July 2, 2025 changed it to “paragraphs 2 to 9.” As corrected, the fines do not apply to “manufacturers that qualify as microenterprises or small enterprises with regard to any failure to meet the deadline” in Article 14(2)(a) or 14(4)(a). Those are the two 24 hour early warning provisions. If you read an analysis saying the exemption does not reach Article 14 fines, check whether it quotes the uncorrected text.

Small and micro are defined by the EU’s SME definition in Recommendation 2003/361. A small enterprise has fewer than 50 staff and turnover or a balance sheet of no more than EUR 10 million. A microenterprise has fewer than 10 staff and no more than EUR 2 million. A 120 person manufacturer is a medium enterprise and gets no exemption at all. Group structures and partner companies count toward the thresholds, so a small subsidiary of a larger group may not qualify.

Size matters outside the fine rules too. Article 33 directs Member States, where appropriate, to provide awareness training, a dedicated advice channel and testing support tailored to micro and small enterprises. Fines are set nationally within the Article 64 ceilings. Article 64(5) tells authorities to weigh the nature, gravity and duration of the infringement, prior fines, and the size and market share of the offender, with express attention to microenterprises and SMEs. Article 64(9) allows fines on top of other corrective measures, which can include withdrawal or recall. For an equipment maker, an order to stop selling a product line in the EU is often the more serious exposure.

Commercial exposure arrives faster than regulatory exposure. A European customer that learns of an exploited flaw in your controller from its national CSIRT before it hears from you will remember. Expect EU buyers to start asking for evidence of a CRA incident process in supplier questionnaires, alongside the AI governance questions covered in our Tier 1 questionnaire guide.

8. How do the CRA, the AI Act and the Machinery Regulation fit together?

The three regimes fit together in a sequence. The CRA’s reporting duty applies now, the Machinery Regulation applies from January 20, 2027, the rest of the CRA from December 11, 2027, and the AI Act’s high risk rules for AI embedded in regulated products on August 2, 2028. For an AI enabled machine, the CRA’s reporting duty is the first product cybersecurity reporting deadline of the three, although some AI Act obligations may already apply depending on the system and the company’s role.

The Machinery Regulation overlap is addressed directly in the Commission guidance. Paragraphs 255 and 256 say that a valid EU type examination certificate issued under the Machinery Regulation’s cybersecurity related essential requirements remains valid for those risks. That covers protection against corruption and the safety and reliability of control systems in sections 1.1.9 and 1.2.1 of its Annex III. It stays valid until the certificate expires, and in any event not beyond June 11, 2028. That relief is about product requirements, not reporting. Nothing in the Machinery Regulation displaces Article 14.

The AI Act interaction runs through Article 12 of the CRA, covered in section 3. Because the AI Act’s high risk deadlines were pushed back by the Digital Omnibus, as explained in our analysis of what the Omnibus delayed and what it did not, many AI equipment makers face the CRA long before any AI Act conformity work. The Commission’s guidance itself, at paragraph 9, flags the interplay between the CRA and the AI Act as a topic for further guidance. Expect more on this.

The incident reporting regimes also differ in who files. The AI Act’s incident rules fall on providers of high risk AI systems and on providers of general purpose AI models with systemic risk. We covered the general purpose model side in our piece on how incident reports flow down to SaaS builders. The CRA’s Article 14 sits on whoever puts the connected product on the market. A machine builder that integrates a third party vision model is the CRA manufacturer of the machine, whatever its AI Act role turns out to be.

For governance design, this argues for one incident process with several regulatory outputs. Build a single intake, triage and decision log, then map its outputs to the CRA, to GDPR breach rules where personal data is involved, and to customer contracts. ISA/IEC 62443 gives the industrial security baseline. The NIST AI Risk Management Framework and ISO/IEC 42001 supply the AI specific risk and accountability layer that a CRA process alone does not cover. None of these frameworks substitutes for the CRA’s product requirements or for actually filing an Article 14 report.

9. How ready are small manufacturers, really?

Among respondents to the 2026 readiness surveys, CRA awareness was relatively high but incident response maturity was low, and US respondents trailed on basic awareness. None of these surveys is a representative census of small manufacturers, but they point the same way, and manufacturing is the sector attackers hit most.

Start with the threat side. IBM’s 2026 X-Force Threat Intelligence Index found that manufacturing “accounted for 27.7% of incidents observed by X-Force,” the fifth straight year at the top of the list. It also found that vulnerability exploitation “became the leading cause of attacks, accounting for 40% of incidents.” Exploitation of public facing applications rose 44 percent. Not every attack on a manufacturing company is a reportable event, because Article 14 needs a link to the security of a product you sell. But an exploited vulnerability in that product is exactly what it covers.

ENISA’s SME CRA Survey Report, published June 24, 2026, drew 194 responses from 31 countries and geographic groupings. It found that 66 percent had heard of the CRA. Incident response and product life cycle management scored lowest of five maturity domains, with an average of 2.61 out of 5. More than a third of responding microcompanies, 36 percent, reported no incident response plan, and only 2 percent said their plans are tested and regularly reviewed. ENISA notes the sample was voluntary and probably more engaged than average.

US awareness is lower still. OpenSSF’s summary of the 2026 CRA Awareness and Readiness Report, produced by LF Research with OpenSSF and industry partners, reports that 72 percent of respondents in the United States and Canada were unfamiliar with the regulation. Roughly 4 in 10 respondents overall had not determined whether it applied to them at all. Only 32 percent produced a software bill of materials for all products, and 51 percent passively relied on upstream projects for security fixes.

Industrial firms in Europe name the 24 hour rule as their hardest problem. ONEKEY’s 2026 survey of 200 German industrial companies, reported in its August 2026 release, found 62 percent cited the 24 hour reporting requirement as particularly problematic. Vulnerability management remained unresolved for 62 percent. These are vendor and association surveys with their own methods, not census data, but they agree with ENISA’s government survey on the central point.

The pattern matches what we saw in federal programs for fifteen years. Organizations write the policy first and test the process last, and the first real event becomes the test. The difference under the CRA is that the first real event now carries a 24 hour reporting deadline.

10. A 30 day plan to be able to file in 24 hours

A small manufacturer can build a defensible Article 14 capability in about 30 days by deciding scope, ownership and filing logistics before an incident forces the questions. This plan is a baseline for reporting readiness. It is not full CRA compliance, which requires Annex I security requirements and conformity work before December 11, 2027.

Days 1 to 7: decide what you are answerable for. List every product line with digital elements sold into the EU since you began exporting, including discontinued models, free tools and any cloud or AI service a product needs to function. For each one, record whether you are the manufacturer under your own name or a contract builder for someone else’s brand. Then pick your coordinating CSIRT using the Article 14(7) order and write down the reasoning.

Days 8 to 14: build the filing path. Choose a primary and a backup reporter and create personal EU Login accounts with multi factor authentication for both. Read ENISA’s platform instructions, record your coordinating CSIRT and gather the manufacturer information the platform asks for, but follow ENISA’s advice to register and start validation only when you need to file. Draft early warning, notification and final report templates in English, with the required fields from the table in section 5. Draft a short customer notice template for Article 14(8) as well.

Days 15 to 21: build the awareness engine. Publish a security contact and a coordinated vulnerability disclosure policy so researchers and customers know where to send reports. Set up a timestamped intake log that calculates every legal deadline from awareness, independent of the platform’s counters. Subscribe your team to the CISA catalog feed and to advisories for your major components, including any AI frameworks, model servers and Linux distributions you ship. Create or update a software bill of materials, and add an AI bill of materials listing models, model versions and where inference runs.

Days 22 to 30: rehearse and contract. Run a two hour tabletop exercise built on an exploited flaw in an AI component of a shipped product, and time it against the 24 and 72 hour marks. Add flow down clauses to supplier and contract manufacturing agreements requiring prompt notice of vulnerabilities and exploitation. Add matching notice clauses to EU distribution agreements, since the distributor duty in Article 20 is not yet in force. Finally, map the whole process to ISO/IEC 42001 and ISA/IEC 62443 controls so it becomes part of your management system rather than a binder on a shelf. Neither framework substitutes for the CRA’s product requirements or for the filing itself.

If you sell into the US defense supply chain as well, much of this mirrors the incident discipline in DFARS 252.204-7012, discussed in our CMMC and CUI article. One intake process can serve both regimes.

This article is provided for general informational purposes and reflects the state of the law as of October 2026. It is not legal advice. Regulations in this area are changing quickly. Confirm current requirements and consult qualified counsel before making decisions for your organization.