← Back to the blog
October 2026

Cyber Resilience Act: since 11 September 2026 manufacturers have 24 hours to report an exploited vulnerability — what it means for MES vendors and factories

Since 11 September 2026, software manufacturers, MES vendors included, must send an early warning of an actively exploited vulnerability within 24 hours and a full notification within 72 hours to the CSIRT and ENISA. Who Article 14 of the CRA covers and what factories should ask of their vendor.

📅 October 5, 2026🏭 OmniMES✒ Martin Szerment
Cyber Resilience Act: since 11 September 2026 manufacturers have 24 hours to report an exploited vulnerability — what it means for MES vendors and factories

A hypothetical scenario: Friday, 5:40 pm. An integrator finds an administrator account on a customer's MES server that nobody created. An hour later the cause is clear: someone exploited a flaw in the login library. Until this summer, whether the software vendor reported that to anyone was mostly a matter of contract and goodwill. Since 11 September 2026 there is a clock on it: 24 hours to send an early warning to the national CSIRT and ENISA.

It is the first obligation of the EU Cyber Resilience Act (Regulation (EU) 2024/2847, the CRA) to apply before the rest follows in December 2027. It covers every manufacturer of software on the EU market, MES vendors included, and reaches back to versions installed years ago.

The CRA timeline

The regulation entered into force on 10 December 2024 (European Commission, 2026). It applies in three stages (Article 71(2); Hogan Lovells Cadwalader, 2026):

  • 11 June 2026 — Chapter IV on the notification of conformity assessment bodies (Articles 35 to 51);
  • 11 September 2026 — Article 14, reporting of actively exploited vulnerabilities and severe incidents;
  • 11 December 2027 — everything else, including the Annex I essential requirements, technical documentation, the declaration of conformity and CE marking.

What triggers a report

Article 14 covers two kinds of event, not every vulnerability.

An actively exploited vulnerability is one for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission (Article 3(42)). A flaw found by your own testers, or reported by a researcher but not exploited in the wild, does not trigger Article 14; it falls under the Annex I vulnerability handling rules from December 2027.

A severe incident having an impact on the security of the product affects, or could affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or has led or could lead to the execution of malicious code (Article 14(5)). An MES example: a breached build server pushing a tampered package through the update channel.

Three deadlines

StageActively exploited vulnerabilitySevere incident
Early warningwithin 24 h of becoming aware; Member States where the product is availablewithin 24 h of becoming aware
Notificationwithin 72 h: product information, nature of the exploit and vulnerability, corrective or mitigating measureswithin 72 h: nature of the incident, initial assessment, measures taken
Final reportwithin 14 days of a fix or mitigation being available: description and severity, the malicious actor, the security updatewithin one month of the notification: description, likely root cause, mitigation applied and ongoing

Source: Article 14(2) and (4).

The manufacturer must also inform impacted users, and where appropriate all users, about the vulnerability or incident and the mitigations, where appropriate in a structured, machine-readable format (Article 14(8)).

When the clock starts

The 24 hours run from the moment the manufacturer becomes aware. The Commission guidance of 27 July 2026 puts that at the point where, after an initial assessment, the manufacturer has a reasonable degree of certainty that the vulnerability is being exploited or that the incident has compromised the product (Jones Day, 2026; Kirkland & Ellis, 2026). Exploitation already known before 11 September 2026 does not have to be reported retroactively (Jones Day, 2026).

So log the moment of awareness: the call "we are now reasonably certain" belongs in the ticketing system, with a timestamp and a name.

Where reports go

ENISA's Single Reporting Platform went live on 11 September 2026 (ENISA, 2026). The manufacturer files once, through the CSIRT designated as coordinator in the Member State of its main establishment, and ENISA receives the report simultaneously (Article 14(7)). That CSIRT shares it with CSIRTs in other Member States where the product is available (ENISA, 2026). In Poland the coordinator is CSIRT NASK, whose tasks CERT Polska carries out (Polish Ministry of Digital Affairs, 2026; CERT Polska, 2026).

Who is in scope

The MES vendor, old versions included

A product with digital elements is a software or hardware product together with its remote data processing solutions (Article 3(1)). An MES installed on a customer's server qualifies, and the company that develops it and sells it under its own name is the manufacturer (Article 3(13)).

Under Article 69, products placed on the market before 11 December 2027 only become subject to the CRA's requirements after a substantial modification (paragraph 2). Article 14 is the exception and covers all in-scope products, including earlier ones (paragraph 3). For example, an MES version rolled out in 2019 and never updated must be reported on, although the CRA itself imposes no duty to patch it.

Cloud and SaaS

Recital 12 places SaaS, PaaS and IaaS cloud services under NIS2. The CRA covers remote data processing only insofar as the product needs it to perform its functions (Recitals 11 and 12). Kirkland & Ellis advises a case-by-case assessment (Kirkland & Ellis, 2026). Vendors selling both on-premise and hosted are better off with one process for both.

Open-source components

Open-source software developed outside a commercial activity is excluded, and open-source software stewards face a lighter regime, reporting only from 11 December 2027 (ENISA, 2026; Kirkland & Ellis, 2026). The MES vendor shipping those components gets no such relief: it must exercise due diligence when integrating third-party code (Article 13(5)) and report flaws it finds there to the maintainers (Article 13(6)). Under the Commission guidance, an exploited vulnerability in a third-party component is reportable when it is exploitable in, and has been exploited in, the manufacturer's own product (Kirkland & Ellis, 2026).

Integrators

Anyone who substantially modifies a product and makes it available becomes its manufacturer for the modified part, or for the whole product if the change affects its overall cybersecurity (Article 22).

The factory

A plant has no Article 14 obligations as a user, but may voluntarily notify vulnerabilities, incidents and near misses (Article 15). If it falls under NIS2, it runs its own clock: early warning of a significant incident within 24 hours, notification within 72 hours, final report within a month (Article 23 of Directive (EU) 2022/2555). One breach through an MES flaw can therefore produce two reports from two organisations.

The Digital Omnibus package does not change this. Its AI part was adopted as Regulation (EU) 2026/1744, in force since 27 July 2026, and amends the AI Act among others, but not the CRA (European Commission, 2026; Law & Technology, 2026). Its data and cybersecurity part would create a single entry point for incident reports, built by ENISA on its CRA platform experience, covering NIS2, GDPR, DORA, the CER Directive and the European Digital Identity Regulation but not the CRA (European Commission, 2025). As of 20 September 2026 that part was still a proposal (European Parliament, 2026).

The numbers

ENISA Threat Landscape 2025 covers 4,875 incidents between July 2024 and June 2025. Vulnerability exploitation accounted for 21.3% of initial intrusion vectors, second only to phishing at about 60%, and new vulnerabilities were weaponised within days of disclosure. Ransomware claims hit manufacturing more than any other sector (14.9%) (ENISA, 2025).

According to IBM, manufacturing was the most attacked industry for the fifth year running, with 27.7% of the incidents X-Force observed, and vulnerability exploitation caused 40% of incidents in 2025 (IBM X-Force, 2026).

Our own assessment, not data: an MES vendor is more likely to face a reportable event in a component it ships (operating system image, web server, broker, library) than in its own code.

In the OpenSSF and Linux Foundation survey of June 2026 (843 respondents), 66% were not at all or only slightly familiar with the CRA, up from 62% a year earlier. Only 32% of manufacturers produce SBOMs for all products, and about four in ten respondents did not know whether the regulation applies to them (OpenSSF, 2026; Linux Foundation, 2026).

Breaching the essential requirements or Articles 13 and 14 can cost up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher (Article 64(2)). Micro and small enterprises cannot be fined for missing the 24-hour early warning (Article 64(10)(a)); the 72-hour deadline has no such carve-out.

Who already does this well

Siemens ProductCERT receives, investigates, coordinates and reports security issues in Siemens products and publishes advisories as a CSAF feed for automated ingestion (Siemens).

CERT Polska has assigned CVE identifiers since 1 August 2023 and coordinates vulnerability disclosure, publishing CVE records 90 days after passing details to the vendor (CERT Polska). When a researcher reports a flaw in a Polish MES through CERT Polska, the vendor is on a clock regardless of the CRA.

Germany's BSI published its reading of the CRA as technical guideline TR-03183. Part 2, version 2.1.0 from August 2025, requires CycloneDX 1.6 or later or SPDX 3.0.1 or later, and a new SBOM for every software version (BSI; FOSSA, 2025). The CRA itself requires a machine-readable SBOM covering at least top-level dependencies (Annex I, Part II, point 1).

Our approach at OmniMES

Multiprojekt is the manufacturer of OmniMES under the CRA: we install the system on customer premises and run it in the cloud. We take a cautious view of scope: OmniMES, the OmniEnergy module and the OmniPlatform cloud are one product with digital elements, with one vulnerability handling process. We maintain a machine-readable SBOM and provide it on request to customers who have purchased the product and to market surveillance authorities to the extent the law requires. We commit to five years of security support per release, assess conformity through internal control (module A) and plan the EU declaration of conformity and CE marking before 11 December 2027 (see our public CRA documentation).

Limits and friction points

The vendor cannot see on-premise installations. The clock starts when the manufacturer becomes aware, but the evidence sits with the customer: server logs, firewalls, the security team. Without an agreed channel it reaches the vendor late, or never.

Grey areas. "Reasonable degree of certainty", the severity threshold and the line between SaaS and remote data processing all need interpretation. The Commission guidance helps; there is no case law yet.

Three regimes at once. An incident involving personal data can mean a notification to the data protection authority within 72 hours (Article 33 GDPR), a NIS2 report from the factory and a CRA report from the vendor, each with its own recipient, form and definitions.

Small vendors. The clock runs through weekends and holidays, and the fine exemption for micro and small firms covers only the early warning, so an on-call rota is needed anyway.

Legacy versions. Report, yes; patch under the CRA, no (Article 69). A plant running an old MES may learn about an exploited flaw with no guaranteed fix for its version, which argues for planning upgrades.

Fines formally from December 2027. Article 71(2) carves out only Article 14 and Chapter IV from the general application date, so the penalties article (Article 64) applies from 11 December 2027. That is our reading of the text, not an authority's position, and the gap should not be treated as a grace period.

What to ask of your MES vendor

  1. Confirmation of status: that the vendor considers itself a CRA manufacturer, where its main establishment is, and that it has an account on the ENISA platform. Kirkland & Ellis recommends registering before the first incident (Kirkland & Ellis, 2026).
  2. A single point of contact for vulnerability reports. Mandatory from December 2027 (Article 13(17)) and reasonable to ask for now, for instance as a security.txt file under RFC 9116 (securitytxt.org).
  3. An SBOM for the version you run, in CycloneDX or SPDX; without it, an advisory about a library tells you nothing about your server.
  4. A mutual notification clause. The plant reports suspected exploitation within hours; the vendor informs the plant under Article 14(8) and states whether it has notified the CSIRT. Align this with your NIS2 procedure.
  5. Machine-readable advisories, such as CSAF, with a subscription.
  6. A declared support period and a list of patched versions. For products placed on the market from December 2027 the CRA requires at least five years of support (Article 13(8)), and each security update must stay available for at least ten years (Article 13(9)).
  7. On your side: a current inventory of versions (MES, broker, database, operating system) and logs kept long enough for the vendor to find the root cause.

MES vendors need a playbook with templates for each stage, an on-call rota, a log of awareness decisions, and an SBOM per release checked automatically against ENISA's European Vulnerability Database, running since 13 May 2025 (ENISA, 2025).

What follows from this

Article 14 is narrow: only vulnerabilities exploited in the wild and severe incidents, which, in our view, most MES vendors will rarely face. But it requires a process that cannot be built within the first 24 hours: an inventory of customer versions, SBOMs, a reporting channel and an on-call rota.

For the factory, the change is practical. The vendor's deadline runs from the moment it learns about the event, and the evidence usually lives at the plant. The contract with your MES vendor should define that flow of information before the first incident, because there will be no time to negotiate it during one.

Sources