*Industry news | September 14, 2026*

The date that matters to you is not 11 December 2027. It is 11 September 2026, three days ago. On that Friday, the reporting duties under the EU Cyber Resilience Act started to apply, and they apply to the equipment already bolted into your cabinets, not to the equipment you might buy next year. If a controller, HMI or drive on your floor has a data connection and someone actively exploits a vulnerability in it, the company that made it now has 24 hours to raise an early warning and 72 hours to file a full notification with an EU platform. Nobody sent you a letter about it. Your spare parts shelf and your capital plan were both built around the December 2027 date, because that is the date everyone quoted, and that date is still real for the CE marking side of things. It just is not the date that governs reporting. Those two dates now sit three months and roughly fifteen months apart, and the gap between them is where a plant gets caught out.

Here is the operational version. Reporting started. Your installed base is inside it. Your patch path for most of that installed base probably does not exist. Those three sentences together are the whole story, and the rest of this piece is about what a maintenance or plant manager can actually do with them.

What changed on September 11

The Cyber Resilience Act is Regulation (EU) 2024/2847. It entered into force on 10 December 2024. Article 71(2) is the article that sets out when the pieces switch on, and it does so in stages rather than all at once. Chapter IV, the part about notified bodies, has applied since 11 June 2026. Article 14, the reporting duty, applies from 11 September 2026. The main conformity regime, meaning the Annex I essential requirements, the technical documentation and the CE marking, applies from 11 December 2027.

On the Friday just gone, what became live is the obligation on manufacturers to report. From 11 September 2026, a manufacturer must report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. This is the Article 14 reporting duty. In plain terms: if a connected product the manufacturer sells is being exploited in the wild, the manufacturer has to tell the authorities, and it has to do it fast.

Fast means measurable. Once the manufacturer becomes aware, it files an early warning within 24 hours, a full notification within 72 hours, and a final report no later than 14 days after a corrective measure is available for an actively exploited vulnerability, or within one month of the 72-hour notification for a severe incident. Reporting is done once, through the CRA Single Reporting Platform, or SRP, which was established by ENISA under Article 16 and was operational on 11 September 2026. The notification goes to the CSIRT of the manufacturer's main establishment and gets shared with ENISA and the other national CSIRTs. ENISA published the list of CSIRT coordinators covering all 27 member states on 4 September 2026, which tells you the plumbing was being finished right up to the deadline.

There is one detail circulating that gets misread, and it matters because it separates a public-relations problem from a legal one. Commission Delegated Regulation (EU) 2026/881, adopted on 11 December 2025, lets a receiving CSIRT delay onward dissemination on cybersecurity grounds. Read that carefully. It restricts who sees a report. It does not change when it is filed. Nothing in that delegated regulation pauses the manufacturer's own filing clock. If you are talking to a vendor who suggests the clock might be paused, the clock is not paused.

Then there is Article 14(8), which adds a separate duty to inform impacted users. If the manufacturer does not do that in time, the notified CSIRTs may inform users themselves where they judge it proportionate and necessary. That is the part to keep in your back pocket during a warranty conversation, because it is the regulation's own answer to the question of who eventually tells the plant. If the maker stays quiet too long, the regulator can go around them.

Why legacy equipment is caught

The assumption I hear most often, and I have heard it in almost those words from people who should know better, is that anything sold before December 2027 is grandfathered and therefore irrelevant to this regulation. That is half true, and the half that is false is the expensive half.

Article 69(2) grandfathers products placed on the market before 11 December 2027 unless they undergo a substantial modification after that date. So an untouched machine, sitting there doing its job with the original firmware and no significant changes, is outside the CE marking and Annex I essential requirements. Fine. For an unmodified line you are not going to get dragged into a conformity project, and nobody is going to ask you to re-document a panel that was built in 2011.

Article 69(3) overrides that specifically for reporting. The Article 14 duty applies to all in-scope products with digital elements placed on the market before 11 December 2027, with no age cutoff and no carve-out for old equipment. Sit with the phrase "no age cutoff" for a second. It does not say five years, it does not say ten years, and it does not say "still supported." It says all in-scope products placed on the market before that date.

Now combine that with the scope rule. Products with digital elements whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network are in scope. Your plant runs Siemens, Rockwell, Mitsubishi and a long tail of other brands, mostly as controllers, HMIs, drives and I/O blocks. The ones that sit on Ethernet or on any fieldbus that reaches the plant network, or that anyone can plausibly connect a laptop to, tick that box. There are explicit exclusions, and they are narrow and specific: medical devices, vehicle type approval, civil aviation products, marine equipment, products developed exclusively for national security or defence, and identical spare parts. A packaging line controller is not on that list.

So here is what that means for a plant running controllers and HMIs installed between 2005 and 2020. You are not the obligated party. The manufacturer is. But the equipment you own is the subject of the obligation, and it is subject to it without any age limit. A thin-client panel PC commissioned in 2008 is as much a candidate for a reported exploited vulnerability as a unit shipped last month, as far as the reporting duty is concerned. The item on your floor has not changed. What changed is that the company that made it now has a legal clock attached to what happens to it.

There is a practical consequence buried in that, and it is the one I would want my own team to understand. In a reporting regime with a 24-hour clock, the manufacturer's willingness and ability to know what is happening in old equipment becomes a compliance asset. Vendors who cannot see into a decade-old build are not off the hook. They have to report what they know. But the flow of information runs through their support and security channels, and if your plant is not in that stream, you will be the last to know.

The part that should worry a plant manager more than the reporting

Reporting is somebody else's deadline. The patch question is yours, and it is worse.

Think about the sequence. A vulnerability in an out-of-support controller gets actively exploited. The manufacturer becomes aware, and it starts a 24-hour clock and then a 72-hour clock. Under Article 14 it has to say what it knows. What it does not have to do is fix the thing. The Commission has been explicit that a manufacturer may genuinely be unable to investigate a vulnerability in a legacy product, because build environments cannot be recreated, dependencies are unavailable, or the people who knew the code have left. In that case the manufacturer must still notify, but is not required by the regulation to meet the other obligations, such as vulnerability handling. The duty is to report what is known, not to reopen a decade-old build.

Read that as an operations manager and the sentence has teeth. An out-of-support controller will not get a patch. It may well get reported. So there is now a defined path where the world learns that your line is exploitable, the maker files the paperwork on time, and nothing physically changes at your plant. The report is a disclosure event, not a remedy.

That reframes the support period from a nice-to-have procurement line into a security date, and it shifts where the risk sits. Under Article 13(8), a manufacturer must define a support period for vulnerability handling, at least five years or the expected in-use period if shorter, starting when the product is placed on the market, and must disclose the support period end date at the point of purchase in at least month and year format. Under Article 13(9), each security update must remain available for at least 10 years after issuance, or for the remainder of the support period, whichever is longer, and security updates must be supplied free of charge, with a narrow exception for tailor-made business products.

A minimum support period of five years is a floor set by regulation, and it is short. Five years from a purchase order in 2026 lands in 2031. Five years from a 2019 order landed in 2024, which is already behind us. I have panels in this plant older than some of the people who now run them. So the stated support end date, in month and year, is now the closest thing you have to an expiry label on a control asset, and it belongs in the asset register next to the model number, not in a supplier's marketing deck.

The migration argument follows from that without any engineering. If the support end date is the last date you can expect a vulnerability fix, and the reporting regime reaches back before 2027 with no age cutoff, then an end-of-support date is a security date. A dated security date is a procurement problem. It is not an IT problem, because IT does not buy the controller, does not stock the spare, and does not own the line when the migration window closes. It sits on the maintenance manager's desk, and eventually on the capital committee's desk.

What the plant has to do

None of this requires you to become a compliance officer. It requires four pieces of work that a manager can assign to named people, and one of them can start this week.

Build an asset list of connected control equipment, with the support period end date next to each item. The word "connected" is doing real work there. Anything on the plant network, anything on a fieldbus that bridges to it, anything an integrator or a vendor laptop plausibly touches. If you have a CMMS or an asset register that already holds the tag numbers, extend it rather than starting a parallel spreadsheet, because a second list will rot.

Ask suppliers and distributors for the declared support end date in writing. For anything bought from now on, treat that date as a specification alongside I/O count and price. Nobody negotiates a controller without knowing how many digital inputs it has. From this quarter, the support end date belongs in the same conversation, in months and years, in writing, on the quote if you can get it. A verbal answer is not a support statement.

Put every automation vendor's security advisory channel on someone's job description. Not a shared inbox nobody reads, and not a personal email that leaves when the person does. A named role, with a backup, and a bench check that both people can log in. Vendor advisories are how you find out that a vulnerability has moved from theoretical to actively exploited, and that is the trigger point for everything in this article.

Sort the equipment into what can still be patched and what cannot. That split is not a compliance exercise. It is your migration queue. Everything inside a support period goes on the maintain list. Everything outside it goes on the migration list, ordered by how much the line costs you when it stops. That is the whole triage. You do not need a risk model to draw that line; you need the support dates from step two and a view on criticality, which you already carry in your head.

Fold 11 December 2027 into the capital plan rather than treating it as an IT matter. That is the date the full conformity regime applies, and it is also the deadline that has been quoted at you for two years, which is exactly why it is the wrong date to plan around alone. If your migration queue only gets funded when the 2027 date starts to bite, you will be executing migrations under time pressure with no negotiation room on lead times or price. Funding the queue a year early is cheaper than funding it in the last quarter of 2027, and the security argument is now the reason to do it rather than a slogan.

There is one more thing that belongs in a manager's head, and it is about relationships rather than process. Your route to a support statement is usually the distributor or reseller who sold you the module, or the integrator who specified it. Those people have the manufacturer relationship you do not, and they can get a written answer where your general inquiry goes nowhere. This is a reason to keep a small number of parts and support relationships in decent condition rather than chasing the cheapest quote on every single transaction. When you need a support end date in writing, a documentation response or a last-time-buy allocation, you find out quickly who actually wants your business.

Timetable

Date | What applies

11 June 2026 | Chapter IV of the regulation, on notified bodies, applies.

11 September 2026 | Article 14 reporting duties apply. Manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.

Once a manufacturer becomes aware | The reporting clock runs: early warning within 24 hours, full notification within 72 hours, and a final report no later than 14 days after a corrective measure is available for an actively exploited vulnerability, or within one month of the 72-hour notification for a severe incident.

11 December 2027 | The full manufacturer conformity regime applies, including Annex I essential requirements, technical documentation and CE marking.

Two notes on that table. First, the reporting row in the middle is not a one-off event. It is a standing obligation that fires each time a manufacturer becomes aware of an actively exploited vulnerability or a severe incident, which is why the clock, not the date, is the thing to keep in view. Second, the two dated rows are not the same project. The September 2026 row is about disclosure and it is already running. The December 2027 row is about conformity and it is what your capital plan has to absorb.

Penalties, briefly

Article 64 sets the money. For breaching the Annex I essential requirements or the Article 13 and Article 14 obligations, administrative fines run up to EUR 15 million or, for an undertaking, up to 2.5 percent of total worldwide annual turnover for the preceding financial year, whichever is higher. Other obligations carry up to EUR 10 million or 2 percent. Supplying incorrect, incomplete or misleading information to notified bodies or market surveillance authorities carries up to EUR 5 million or 1 percent. Member States set the rules on penalties, so the practical enforcement shape will vary by country.

That is the manufacturer's exposure. It is not yours, and I would not invent a number for what it costs a plant, because it does not. What it does do is explain behavior. A supplier facing a potential EUR 15 million fine, or 2.5 percent of group turnover, has a hard reason to build a real vulnerability process: intake channels, triage, an ability to say something within 24 hours. It also has a hard reason to be careful about what it writes down. Expect documentation requests around supported life, update availability and known-issue status to get more serious over the next eighteen months, and expect a vague verbal answer to be replaced by a templated written one. That is a good outcome for a buyer, on balance, because a manufacturer that has to measure something tends to manage it. The buyer's job is to ask the question in a form that produces a dated answer rather than a brochure.

I would not read too much else into the penalty numbers. Nobody is being fined today, and I am not aware of any enforcement wave arriving before the conformity regime starts in 2027. The reason to care now is that the September date is live and the incentive it creates reaches into how much information you get about your own plant.

The spare parts angle

Identical spare parts are excluded from the scope of the regulation. That exclusion is real and it is specific, and it is relevant to what a parts supplier sells. If you buy an identical replacement module to swap into a cabinet that already has that module, the spare part itself is not a product with digital elements under this regulation.

Do not turn that into a compliance answer, because the controller those parts go into is not excluded. The exclusion carves out the spare part; it does not carve out the device the part sits in. A plant cannot retire its exposure by buying one more identical module for the shelf. When that controller becomes the subject of a report because a vulnerability in it is being actively exploited, the spare part exclusion does nothing for you at all.

The real answer is one of two things. Either a support period that runs long enough that you never hit the wall, or a migration plan with a date on it. There is no third option that involves a purchase order and a shelf.

That said, the spares side and the migration side are not in conflict, and a manager should not treat them as such. Keeping critical systems running while migration is scheduled is the whole job, and an out-of-support line usually needs stocked spares precisely because it cannot be patched. Think it through from the operations side. If a controller is end-of-support, there is no firmware fix coming, so a failure of that controller is a hardware event you have to answer with hardware. The migration may be eighteen months out in the capital plan, and the line still has to run every shift in between. That means the last-time-buy question, the stock level and the sourcing route for that controller become more important, not less, in the period between the security date passing and the migration date arriving. A spare on the shelf is not a fix for the vulnerability. It is how you survive the exposure long enough to migrate away from it, which is a different and legitimate thing.

There is a further reason to keep the parts route warm, and it is not about the regulation at all. A migration program takes years to execute in a plant of any size. In that window, brownfield lines break the way brownfield lines always break, at the worst possible moment, on the shift with the least cover. The plant that has a documented parts route and a sensible stock position moves through its migration without the two problems colliding.

This week's checklist

1. Start the connected asset list. Get tag numbers, manufacturer, model and a rough install year for every controller, HMI, drive and I/O block that reaches the plant network. Assign one owner and set a date to have the first pass done. The support end date column can be blank for now.

2. Send a written support period question to the top five vendors or distributors by installed base. Ask for the support period end date for each product family, in month and year, in writing. Note the date you asked and put a follow-up on the calendar.

3. Name the person who owns vendor security advisories, and the backup. Confirm both can actually access the channels for your main automation brands. If not, get the subscriptions set up this week.

4. From now on, treat the support end date as a specification on new purchases, alongside I/O count and price. Add it to the standard inquiry template so it stops being an optional question.

5. Run the first triage pass: mark everything inside its support period as maintain, everything outside as migrate, and rank the migrate list by what a stop costs the line. You now have a migration queue with a security rationale behind it.

6. Put 11 December 2027 in the capital plan as a dated line item with a budget number attached, not a note. The conformity regime starts that day and it is the deadline that funds your migration queue.

7. Note the September 2026 fact in whatever risk log or plant review you run. Reporting is live, it reaches back with no age cutoff, and it is the reason your support end dates now get read as security dates.

None of this is paperwork for its own sake. It is the same set of facts a maintenance manager would want anyway, which is what the equipment is, how long it will be supported, what it costs to keep running, and when it gets replaced. The regulation just put dates on the columns.

If you need a fast read on what is still serviceable and what should be heading for the migration queue, the controller and drive pages at tztechio.com/plc and tztechio.com/industrial-automation are a reasonable place to check part availability against your asset list, and the brand pages for Siemens and Allen-Bradley cover most of what sits in a European legacy panel. Start with the asset list. The rest follows from it.

--------------------------------------------------------------------------------------------

🏢 About TZ Tech

TZ Tech is a leading supplier of industrial automation, electrical, instrumentation, and telecommunications components. We specialize in sourcing ready-to-ship distributor stock, allowing us to offer highly competitive pricing and short lead times. Thanks to our extensive inventory, we can even source rare and discontinued parts that are hard to find elsewhere.

🛡️ Our Quality Commitment

We understand that quality is your top priority. Every component undergoes a strict screening and inspection process so you can buy with absolute confidence. For legacy or discontinued parts, we believe in complete transparency and will always provide an honest, accurate report on the product's condition. Plus, all brand-new parts come backed by a full 1-year warranty.

✉️ Get in Touch

Have a project or a part you need? Send us your inquiry today! Our team is dedicated to providing a fast response within 6 hours (excluding weekends).