EU Cyber Resilience Act for OT: The 24-Hour Reporting Rule That Hits PLC and Robot Makers on 11 September 2026

Diagram of the EU Cyber Resilience Act reporting cascade: an actively exploited vulnerability in an industrial controller obliges the manufacturer — not the plant operator, drawn greyed out and unconnected — to report through the ENISA single reporting platform, followed in sequence by a 24-hour early warning, a 72-hour notification, and a 14-day final report.

On 11 September 2026, the vulnerability and incident reporting obligations in Article 14 of the EU Cyber Resilience Act — Regulation (EU) 2024/2847 — start applying to manufacturers of products with digital elements placed on the EU market. If you build PLCs, HMIs, industrial gateways, robot controllers or the cloud platform that manages a robot fleet, and any of it is sold into the EU, you are the regulated party: not your customer, not the plant operator. From that date, an actively exploited vulnerability in one of your products triggers a 24-hour early warning to ENISA and the coordinating national CSIRT, followed by a 72-hour notification and a 14-day final report. The rest of the regulation — CE marking, conformity assessment, the full Annex I essential requirements — follows on 11 December 2027.

By The Whitepaper Skeptic — OT security architecture reviews mapping how device faults reach vendors

Quick Facts

Question	Answer
What law is this?	Regulation (EU) 2024/2847, the Cyber Resilience Act, in force since 10 December 2024
What changes on 11 September 2026?	Article 14 reporting obligations apply — actively exploited vulnerabilities and severe incidents must be reported through the ENISA Single Reporting Platform
What is the reporting cascade?	24-hour early warning → 72-hour notification → 14-day final report for an actively exploited vulnerability (final report due after a corrective measure is available); one month for the final report on a severe incident
When does everything else apply?	11 December 2027 — CE marking, conformity assessment, and full Annex I essential requirements
What is the penalty ceiling?	Article 64(2): up to €15,000,000 or, for an undertaking, up to 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher — for non-compliance with the Annex I essential requirements and the obligations in Articles 13 and 14

What Actually Switches On in September 2026 — and What Doesn't

Two dates carry almost all of the practical weight, and they are frequently collapsed into one in vendor marketing.

11 September 2026 turns on reporting. Article 14 obligations begin: a manufacturer that becomes aware of an actively exploited vulnerability in one of its products, or of a severe incident affecting the security of one of its products, files through the ENISA Single Reporting Platform, which routes the report simultaneously to the coordinating national CSIRT and to ENISA. Nothing about CE marking or conformity assessment applies yet.

11 December 2027 turns on everything else — the Annex I essential requirements, the technical documentation, the conformity assessment route, and the CE marking that makes the product legally placeable on the EU market.

The gap between those two dates is the awkward part. For fifteen months, a manufacturer has a legally binding obligation to report exploited vulnerabilities in products that have not yet been assessed against the security requirements those reports implicitly measure them against. That is not a drafting accident: the reporting regime is the part the EU wanted running first, because it produces visibility across the market immediately, while conformity assessment infrastructure (notified bodies, harmonised standards) is still being built out.

Neither date has been pushed. Client alerts published through mid-2026 by firms tracking the file — Crowell & Moring and Hogan Lovells among them — consistently describe 11 September 2026 as holding, and the European Commission's own CRA reporting page carries the same date.

CRA vs. NIS2 vs. IEC 62443: The Comparison That Resolves Most of the Confusion

The single most common question in this space is whether NIS2 compliance already covers the CRA. It does not, and the reason is structural rather than a matter of overlapping scope: NIS2 regulates entities and CRA regulates products.

Dimension	CRA — Regulation (EU) 2024/2847	NIS2 — Directive (EU) 2022/2555	IEC 62443
Who is bound	The manufacturer placing a product with digital elements on the EU market (plus importer and authorised-representative duties for non-EU manufacturers)	The operating entity — essential and important entities running services in scope	Nobody, by law. A voluntary standards series adopted by contract, tender requirement, or certification scheme
What triggers it	Placing a product on the EU market	Being classified as an essential or important entity in a member state	Being asked for it by a customer, an integrator, or your own product roadmap
What you must produce	Conformity assessment, CE marking, Annex VII technical documentation, an SBOM drawn up under Annex I Part II point 1, a defined support period, a coordinated vulnerability disclosure policy	Risk-management measures for your own network and information systems, plus incident reporting on your own service	Process evidence (62443-4-1) and product security capability levels (62443-4-2), typically demonstrated through a certification body
Reporting clock	24 hours / 72 hours / 14 days for an actively exploited vulnerability in your product, via the ENISA Single Reporting Platform	Incident reporting on incidents affecting your own service. Article 23 of Directive (EU) 2022/2555 runs its own cascade for a significant incident: early warning within 24 hours of becoming aware, incident notification within 72 hours, final report within one month	None. There is no regulator to report to
If you ignore it	Up to €15 million or 2.5% of worldwide annual turnover; ultimately, loss of market access in the EU	Member-state enforcement against the entity, including management liability provisions	You lose tenders. That is the entire enforcement mechanism

Read across the "who is bound" row and the practical consequence becomes obvious: a European plant operator can be fully NIS2-compliant and still be buying non-compliant equipment, and a Korean or American PLC vendor with no EU legal entity at all can be squarely in CRA scope through nothing more than an EU distributor. Our earlier piece on NIS2 and OT security for manufacturers covers the operator side of that pair; this article is the manufacturer side, and the two obligations run in parallel rather than substituting for each other.

Does the CRA Apply If You're Not in the EU?

Yes, if your product reaches the EU market. The CRA attaches obligations to the act of placing a product on the EU market, not to where the manufacturer is established, and it builds in importer and authorised-representative duties precisely so that a non-EU manufacturer cannot sit outside the enforcement chain. A robot controller built in Korea, a gateway built in Taiwan, and a fleet-management platform hosted in the US are all in scope once they are sold into or made available in the EU.

This is where the readiness data gets uncomfortable. The Linux Foundation and OpenSSF's 2026 CRA Awareness and Readiness Report (June 2026, n=843 respondents, plus analysis of 12,000+ open source projects) found that 66% of respondents were entirely unfamiliar or only slightly familiar with the CRA, that unfamiliarity ran to roughly 72% in the US and Canada, and that 41% had still not determined whether the regulation applied to them at all. The 66% figure is up from 62% a year earlier — awareness is not improving. For a regulation whose reporting clock starts in September 2026 and whose non-compliance ceiling is 2.5% of worldwide turnover, "we haven't determined whether it applies to us" is a position with a cost attached.

Annex III Doesn't List PLCs — Your Gateway Is the Product to Worry About

The classification decides whether you can self-assess or must involve a third party — the difference between an internal documentation exercise and a procurement decision with lead times. And for most industrial controllers the answer is more forgiving than the compliance-blog consensus suggests.

Annex III of the adopted regulation is a closed list: 19 class I categories and 4 class II categories. There is no entry for industrial automation and control systems, and the words PLC, DCS, CNC and SCADA do not appear in it. Article 7 sets the test — a product is "important" only where its core functionality matches an Annex III category (Article 8 runs the parallel test against Annex IV, for the critical tier). A controller whose core functionality is executing control logic matches nothing on the list, lands in the default category, and takes the self-assessment route.

If you have read the opposite somewhere, you probably read the 2022 draft. The widely quoted two-tier IACS wording — class I for "IACS not covered by class II," class II for IACS intended for essential entities — is from the Commission's original proposal, COM(2022) 454 of September 2022, and it was dropped during the legislative process. The tell in the circulating quotations is the square-bracketed cross-reference to the NIS2 annex, which is proposal-stage placeholder notation that no adopted regulation would carry. It propagates because EUR-Lex's HTML rendering of 2024/2847 is easy to read up to the annexes and much less easy after.

The real exposure for an industrial vendor is not the industrial category that does not exist. It is the functional categories that do:

What you ship	Annex III category it can match	Route
PLC, HMI panel, robot controller, servo drive, CNC — control logic as core functionality	None	Default — self-assessment
Industrial gateway, managed Ethernet switch, cellular edge router	Class I — routers, modems intended for the connection to the internet, and switches	Class I
Fleet-management or device-management server whose job is configuring and monitoring networked devices	Class I — network management systems	Class I
Remote-access appliance that terminates VPN tunnels into the cell	Class I — VPN products	Class I
Security-related microcontroller or microprocessor sold as a component in its own right	Class I — microcontrollers / microprocessors with security-related functionalities	Class I
Device whose core functionality is firewalling or intrusion detection — an embedded or DIN-rail industrial firewall	Class II — firewalls, intrusion detection and prevention systems	Class II

Class II is the one that removes your options: at that tier the assessment involves a third party rather than your own file. Class I sits in between — under Article 32(2), self-assessment survives only where you have fully applied harmonised standards, common specifications, or a European cybersecurity certification scheme at assurance level at least "substantial"; apply them only in part, or not at all, and you are pushed onto the same third-party modules as class II. As the standards section below covers, the harmonised-standards route is not yet open for any product category, because no CRA harmonised standard has been cited in the Official Journal.

On the plant networks I've reviewed, the cell-boundary box is exactly where these functions collapse into one SKU: a single DIN-rail unit doing routing, VPN termination, firewalling and remote device management, sold by the same vendor whose PLC line is comfortably in the default category. That one product can sit two tiers above the rest of the catalogue. Where functions are bundled, Article 7's core-functionality test is a documented judgement, not a lookup — write down why you concluded what you concluded, because a market surveillance authority asking about it later will be asking about your reasoning.

Classify against Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025, in force since 21 December 2025, which sets the technical descriptions of each Annex III class I, class II and Annex IV category. That is the operative text — not a vendor summary, and certainly not the 2022 proposal.

The 24-Hour Clock vs. How an OT Disclosure Actually Travels

Whether September 2026 is a documentation update or a real operational change depends on something no compliance summary covers: how a defect report physically moves. In the OT security architecture reviews I've run, the path a suspected security defect takes from a plant floor to the vendor's product-security team was almost never direct. It ran: an operator or controls engineer notices anomalous device behaviour → they raise it with the system integrator who commissioned the line, because that is who they have a support relationship with → the integrator escalates to the vendor's regional support desk as a reliability ticket, because that is the category it looks like from the outside → and only if someone in that chain recognises a security signature does it reach anyone with the authority to classify it as a vulnerability. Three handoffs, each with its own ticket queue and its own business hours, before the clock the CRA cares about would even be recognised as having started.

Article 14(1) requires a manufacturer to notify "any actively exploited vulnerability contained in the product with digital elements that it becomes aware of," and Article 14(2)(a) sets the early warning at "within 24 hours of the manufacturer becoming aware of it." Recital 68 explains what "actively exploited" means: a manufacturer establishes that a security breach affecting its users has resulted from a malicious actor making use of a flaw. So the clock is pinned to awareness — but the regulation does not say at which point in a support chain a manufacturer is deemed to have become aware. Whether that chain of custody constitutes "awareness" at hop one or hop four is not a legal abstraction — it is the difference between an in-time report and a late one.

Three concrete things this changes for a device maker:

Your PSIRT intake has to be reachable from outside your support hierarchy. A published security contact and a coordinated vulnerability disclosure policy stop being nice-to-haves and become the mechanism that makes the 24-hour clock survivable.
Integrators need to be told what a security escalation looks like. The people who will see the anomaly first are usually not your employees, and today they have no reason to route it any differently than a fault report.
Your internal incident response plan now has a regulator-facing output. Most OT IR playbooks are built to restore production, not to produce a filing for a national CSIRT within a day — a gap our OT incident response plan guide is a reasonable starting point for closing.

For robot-fleet vendors specifically, the exposure runs through the cloud platform as much as through the machine: a fleet-management backend is itself a product with digital elements, and a compromise there affects every deployed unit at once — the scenario covered in AI robot fleet hacking and the cloud-controller attack surface.

Five Years of Support vs. a Twenty-Year Installed Base

Article 13(8) sets the floor: "the support period shall be at least five years. Where the product with digital elements is expected to be in use for less than five years, the support period shall correspond to the expected use time." During that period the manufacturer must handle vulnerabilities and supply security updates. Article 13(9) then adds a much longer tail: each security update "which has been made available to users during the support period, remains available after it has been issued for a minimum of 10 years or for the remainder of the support period, whichever is longer." Note what that second clock does and does not do — it obliges you to keep an update retrievable for a decade after you shipped it; it does not extend the five-year window in which you owe new fixes.

For consumer software, five years is generous. For industrial equipment, it is a floor set well below reality: PLCs and drives routinely stay in production for fifteen to twenty years, which means a compliant manufacturer can meet the legal minimum and still leave the majority of an installed base's service life uncovered. Buyers should read the support-period end date as a contractual data point, not a reassurance.

The operational half of this problem is unchanged by the regulation. Shipping an update is not the same as the update being applied — air-gapped sites, validated processes, and production windows that open twice a year mean an available patch and an installed patch are separated by months, as covered in why you can't just patch a PLC. What the CRA changes is which side of that gap you are legally responsible for: the supply of the update, on a defined timeline, whether or not any customer installs it.

What You Can Reuse From IEC 62443 — and What Has No Equivalent

If you have already built out an IEC 62443-4-1 secure development lifecycle or certified components to 62443-4-2, a meaningful share of your CRA evidence already exists in a different filing cabinet. This mapping is where the reuse is, and where it stops.

Existing IEC 62443 artefact	Maps toward	Reusable or new?
62443-4-1 secure development lifecycle process evidence (requirements, secure design, implementation practices)	Annex I Part I product security requirements and the supporting technical documentation	Largely reusable — the process evidence is the same evidence, presented for a different audience
62443-4-1 security verification and validation testing records	Demonstrating the product meets essential requirements	Largely reusable
62443-4-1 defect management and security update management practices	Annex I Part II vulnerability handling requirements	Reusable in substance, but the CRA adds hard external timelines the standard does not impose
62443-4-2 component security capability levels	Evidence toward the product-level essential requirements	Partly reusable — a capability level is not a conformity assessment
Component/dependency inventories maintained for 62443	The Annex I Part II point 1 SBOM obligation	Reusable if machine-readable and current; many 62443 inventories are neither
—	Article 14 reporting to ENISA and the coordinating CSIRT	Entirely new. There is no 62443 equivalent. No part of the standards series asks you to notify a regulator within 24 hours

Two cautions on this table. First, be precise about where the SBOM obligation actually lives, because it sits in two places and neither of them is a duty to your customers. The obligation to create it is Annex I Part II point 1, among the vulnerability handling requirements: identify and document vulnerabilities and components "including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies." The SBOM then forms part of the Annex VII technical documentation, which point 2 requires to cover the vulnerability handling processes, and which a market surveillance authority can demand on a reasoned request. Recital 77 is explicit that manufacturers should not be obliged to make the SBOM public, and nothing in the regulation gives a buyer a right to it. Asset owners approaching SBOM from the ingestion side (the framing in our SBOM for industrial control systems piece) should understand that the CRA creates the artefact without creating a right of access to it.

Second, and more important: IEC 62443 certification is not CRA compliance. ENISA publishes a CRA Requirements Standards Mapping and CEN/CENELEC JTC13 work on harmonised standards is ongoing, but whether 62443-4-1 and 4-2 will be adopted as, or formally mapped to, CRA harmonised standards is not settled. Treat 62443 as reusable evidence, never as a substitute conformity route. Anyone selling you the latter is selling you a claim the regulation does not currently support.

The harmonised standards track is also the piece of the timeline most likely to move. A draft Commission amendment published in July 2026 pushes the deliverable deadlines under standardisation request M/606 back by two months on both tracks: the Type A horizontal standards and the Type B vulnerability-management standards move from 30 August 2026 to 31 October 2026, and the product-specific Type C standards from 30 October 2026 to 31 December 2026. Two qualifications matter. The corresponding implementing decision had not been published in the Official Journal as of 31 August 2026, so those new dates are proposed rather than legally fixed. And no CRA harmonised standard has yet been cited in the Official Journal at all — which means the Article 27 presumption of conformity is currently available for no product category, industrial or otherwise.

The Reporting Platform Isn't Live Yet

Here is the operational fact a compliance officer can act on this month. Checked on 31 August 2026 — eleven days before the Article 14 obligations begin on 11 September — ENISA's Single Reporting Platform was still not live: no public submission URL, no published list of the national CSIRTs designated as coordinators, and no API for automated submission. ENISA maintains that the platform will be operational by 11 September 2026, and registration itself runs through EU Login, so an account can be created ahead of go-live.

The guidance has been arriving in pieces rather than as a package: step-by-step registration and notification instructions on 31 July 2026; an update on 3 August 2026 clarifying that CSIRT validation is not a precondition for reporting and that cross-border sharing remains a manual step; and a fourth guidance page on 14 August 2026 covering interface functions, including that an unverified account can file only ten notifications and that drafts are not visible to a backup contact. If you are relying on a backup filer, that last detail is the kind of thing you want to discover now rather than at hour twenty-three.

What to do with that, practically: the absence of a platform does not suspend the obligation, so build the report content and the internal decision path now — who declares a vulnerability actively exploited, who signs the filing, what goes in the early warning versus the 72-hour notification — and treat the submission channel as the last mile you plug in when it appears. Teams that wait for the URL will be building the judgment process during their first real incident.

If You Buy This Equipment: What to Put in Your Next RFQ

Plant operators get something out of September 2026 that they did not have before: leverage. Four items belong in the next industrial equipment RFQ, and none of them require the buyer to be a compliance specialist.

A CRA declaration of conformity, or a dated plan to produce one before 11 December 2027. "We're working on it" without a date is a red flag on a product you will run for fifteen years.
The support-period end date, in writing, per product line. Not "five years" — an actual date, so you can compare it against your own replacement cycle.
SBOM on request, with the terms stated up front. The vendor is not legally obliged to hand it over; whether they will is a commercial negotiation, and it is much easier to have before the purchase order than after.
A named PSIRT contact and disclosure policy. If your integrator cannot tell you where a suspected vulnerability goes, the 24-hour clock will not survive your own support chain either.

FAQ

Q: Does NIS2 compliance cover the Cyber Resilience Act? A: No. NIS2 binds operating entities and covers their own networks, systems and services; the CRA binds manufacturers and covers the products they place on the EU market. A fully NIS2-compliant plant operator can still be buying equipment that is not CRA-compliant, and a manufacturer that has never been in NIS2 scope can be fully bound by the CRA. They run in parallel and neither substitutes for the other.

Q: Does the Cyber Resilience Act apply to non-EU manufacturers? A: Yes, if the product reaches the EU market. Obligations attach to placing a product with digital elements on the EU market rather than to where the manufacturer is established, and the regulation assigns duties to importers and authorised representatives specifically so non-EU manufacturers are covered. A Korean, Japanese, Chinese or US vendor shipping PLCs, gateways or robot controllers into the EU is in scope.

Q: What counts as an actively exploited vulnerability under CRA Article 14? A: Article 14's early-warning obligation is triggered by a manufacturer becoming aware of a vulnerability in its product that is being actively exploited — not by the mere existence of a vulnerability, and not by a proof of concept. The statutory wording is in Article 14(1) and 14(2)(a) — notify "any actively exploited vulnerability contained in the product with digital elements that it becomes aware of," with the early warning due "within 24 hours of the manufacturer becoming aware of it" — and Recital 68 frames active exploitation as the manufacturer establishing that a security breach affecting its users resulted from a malicious actor making use of a flaw. The practical difficulty is that the regulation pins the clock to awareness without saying where awareness begins inside a support chain that typically routes anomalies through an integrator and a regional support desk before anyone classifies them as security defects.

Q: How long is the CRA support period for industrial equipment? A: A minimum of five years from placing the product on the market, or the expected product lifetime if that is shorter, with security updates remaining available for ten years after issue or for the remainder of the support period, whichever is longer. There is no industrial-equipment carve-out, which is why the five-year floor sits so awkwardly against PLC and drive installed bases that commonly run fifteen to twenty years.

Q: Are PLCs and SCADA systems Class I or Class II under CRA Annex III? A: Neither. Annex III of the adopted regulation has no category for industrial automation and control systems at all, and the words PLC, DCS, CNC and SCADA do not appear in it. The two-tier IACS class I / class II wording still circulating in vendor summaries comes from the Commission's 2022 proposal, COM(2022) 454, and was dropped during the legislative process. Under Article 7 classification follows the product's core functionality, so a controller whose core functionality is executing control logic falls into the default category and takes the self-assessment route. What does pull an industrial vendor into Annex III is a functional match: an industrial gateway or managed switch, a network management system, a VPN-terminating remote-access appliance, or a security-related microcontroller sold as a component are class I, and a product whose core functionality is firewalling or intrusion detection is class II. Classify against Commission Implementing Regulation (EU) 2025/2392, which sets the technical descriptions of each category.

Sources

Author Bio

The Whitepaper Skeptic has run OT security architecture reviews for industrial and manufacturing sites, and one finding recurred across them: the path a suspected device fault actually travels — plant engineering, then the system integrator, then the vendor's regional support desk — regularly consumed more than a day before anyone reclassified it as a security issue rather than a reliability one. Article 14 does not shorten that path, which is why this article spends more space on when a manufacturer's awareness legally begins than on the 24-hour clock every summary quotes.

Search This Blog

Beyond the Whitepaper