The EU Cyber Resilience Act: What OT and Industrial IoT Teams Must Do Now

On 11 September 2026, the first binding deadline under the EU Cyber Resilience Act (Regulation 2024/2847) came into force: manufacturers of "products with digital elements" must now report actively exploited vulnerabilities and severe security incidents to ENISA and their national CSIRT on a strict 24-hour/72-hour/14-day clock. Full compliance — CE marking, conformity assessment, and the Annex I security requirements — isn't due until 11 December 2027, but the reporting obligation is live today, and it already applies to a lot of hardware sitting on factory floors: PLCs, industrial gateways, IIoT sensors, HMIs, and the automation and control systems that run them.

This catches a lot of manufacturing and plant IT teams off guard, because the CRA was written as general product-cybersecurity law, not an OT regulation. If you build, integrate, or operate industrial automation and control systems (IACS) sold into the EU, or you're a plant owner relying on a vendor's continued support, this is now your problem too. Here's what the law actually requires, how it slots alongside standards you may already know like IEC 62443, and what to do before the 2027 wall hits.

What the CRA Actually Covers

The CRA applies to any "product with digital elements" placed on the EU market — essentially any hardware or software with a network or data connection. That sweeps in a huge amount of industrial equipment that previously had no EU-wide cybersecurity law attached to it: edge gateways, industrial routers, remote I/O modules, PLCs, HMI panels, and the firmware and embedded software inside them. It does not cover products already regulated under sector-specific rules with equivalent requirements (certain medical devices and automotive systems, for example), but general industrial automation and IIoT hardware is squarely in scope.

The regulation puts obligations on manufacturers (the entity placing the product on the market under its own name, which can be the OEM, a systems integrator building under its own brand, or a company substantially modifying a product), not directly on end users. But plant operators aren't off the hook: your vendor's CRA obligations determine how long you'll receive security updates, what documentation you can demand, and what happens if a device you depend on turns out to have an actively exploited flaw with no manufacturer left to patch it.

Risk Classes: Why Most Industrial Hardware Isn't "Default" Tier

The CRA splits products into three tiers, and the tier determines how strict the compliance route is:

• Default — most consumer and general-purpose products. Self-assessment against Annex I is generally sufficient.
• Important (Class I) — includes operating systems, firewalls, routers, and many industrial automation and control systems and IIoT devices not elevated to Class II. Still largely self-assessed, but against a stricter baseline, with harmonised standards expected to carry a presumption of conformity.
• Important (Class II) — includes industrial IoT devices and IACS used by entities designated as "essential" under the NIS2 Directive (think critical infrastructure operators). Class II requires third-party conformity assessment by a Notified Body.
• Critical — a small, narrowly defined category (e.g., certain hardware security modules and smart meter gateways) requiring EU cybersecurity certification.

The practical effect: if your plant or your customer's plant counts as an "essential entity" under NIS2 (energy, water, healthcare, and large manufacturing operators in several sub-sectors can qualify), the IACS and IIoT hardware you run may push your vendors into Class II, with mandatory third-party assessment. That changes supplier selection criteria and lead times for new equipment procurement starting now, well ahead of the 2027 deadline, because Notified Body assessment slots and documentation take time to arrange.

The Clock Already Running: Vulnerability Reporting

The September 2026 obligation is narrow but urgent. If a manufacturer becomes aware that a vulnerability in a product it has placed on the market is being actively exploited, it must notify ENISA and the relevant national CSIRT within:

• 24 hours — an early warning
• 72 hours — a full vulnerability notification
• 14 days — a final report (or within one month for a severe incident not tied to a single exploited vulnerability)

This applies even to legacy products still on the market and under support. For plant operators, the practical question to ask every automation vendor right now is simple: do you have a PSIRT (Product Security Incident Response Team) capable of meeting a 24-hour window, and will you notify your customers at the same time you notify ENISA? Many smaller industrial equipment vendors don't yet have this process built — and if they don't, your incident response plan needs to assume you may hear about an actively exploited vulnerability in your own plant before your vendor tells you.

SBOMs: New Paperwork for Every Gateway and Sensor

The CRA requires manufacturers to maintain a machine-readable Software Bill of Materials (SBOM) covering, at minimum, the top-level dependencies of each product, as part of the technical documentation. The regulation doesn't mandate a specific format, but SPDX and CycloneDX are the formats actually used in practice. Documentation, including the SBOM, must be retained for ten years after the product is placed on the market, or for the support period if longer.

For an industrial automation vendor, this means every firmware build for every PLC, gateway, and remote terminal unit needs an SBOM generated as part of the build pipeline, not reconstructed after the fact from a spreadsheet. For an integrator assembling a control panel from multiple vendors' components, it means collecting and reconciling SBOMs across every embedded device in the enclosure — a task that's realistically impossible without supplier contracts that require SBOM delivery on every firmware release.

A Worked Example: Retrofitting a 15-Year-Old PLC Fleet

Consider a mid-sized automotive parts plant in Germany running a fleet of PLCs installed in 2011, now being connected to a new unified namespace layer as part of an IT/OT convergence project. Three things change under the CRA:

1. Procurement. When the plant replaces end-of-life PLCs, the new units — if the plant qualifies as an essential entity under NIS2, which many automotive-sector suppliers do — may need to come from vendors offering Class II-assessed hardware. That narrows the vendor shortlist and should be flagged in the capital request now, not after a unit fails.
2. Incident response. The plant's OT security plan needs an explicit path for "vendor notifies us of an actively exploited vulnerability in a PLC we run" — including who owns the decision to segment or isolate that PLC's network zone (the same zone-and-conduit model from IEC 62443 and the Purdue Model) while a patch is pending.
3. Contract terms. Maintenance contracts with the PLC and gateway vendors should now require SBOM delivery with every firmware update and a committed vulnerability-notification SLA — language that, before September 2026, most industrial supply contracts simply didn't include.

None of this requires buying new software platforms. It requires updating procurement checklists, maintenance contracts, and incident-response runbooks — paperwork and process changes a plant engineering team can start this quarter.

What to Do Before December 2027

• Inventory first. You can't assess CRA exposure without knowing what's actually connected. If you don't already maintain an asset inventory tying firmware versions to network zones, that's the prerequisite, not a parallel task.
• Ask every automation vendor for their CRA classification and PSIRT process. Default, Class I, or Class II — get it in writing, along with their vulnerability-notification SLA.
• Add SBOM delivery to maintenance contracts on renewal, not as a separate negotiation.
• Map CRA risk classes against your existing IEC 62443 zones. The two frameworks reinforce each other: 62443 segments your network by risk; the CRA tells you how much assurance to expect from the devices inside each zone.
• Build the 24-hour notification path into your incident response plan, assuming vendors are inconsistent about proactively telling you.

The CRA won't replace IEC 62443, NIST-style OT security programs, or the practical lessons in the OT network segmentation guide — it sits alongside them as a product-law floor that forces vendors to document and disclose. For manufacturing and IT teams working through IT/OT convergence, the deadline that matters isn't December 2027; it's now, because the vendor conversations, contract renewals, and procurement criteria that determine whether you're ready take longer than a year to fix once you start.

If you're building out broader IT/OT security literacy on your team, the OT Security course track and the glossary are good starting points for getting everyone speaking the same language before the next audit.