The Cyber Resilience Act stops being a future problem in about four months. The first deadline — manufacturer vulnerability reporting — lands on 11 September 2026. The full obligations land on 11 December 2027. Most of the OT world found out about this about a year too late.
Meanwhile, the cars in the parking lot have been shipping under ISO 21434 since 2021. The aerospace world has shipped under some form of DO-178 since the eighties. The panic isn’t proportional to the news.
Four laws, one machine
Read CRA on its own and it looks bad. Read it next to the rest and it looks worse.
CRA covers the digital elements. The new Machinery Regulation, Regulation (EU) 2023/1230, which applies on 20 January 2027, covers the machine itself, and now writes cybersecurity into the essential health and safety requirements. NIS2, Directive (EU) 2022/2555, covers whoever runs the thing. RED Delegated Regulation 2022/30 covers anything that talks over the air.
Four overlapping legal instruments on the same piece of hardware. The surprise isn’t any single regulation. It’s the overlap.
What CRA actually wants
Skip the recitals. Skip the annexes. CRA asks for five things: secure-by-design product development, a software bill of materials, a working vulnerability handling process with disclosure to ENISA, security updates over a defined support period, and conformity assessment proportional to risk class.
That’s the whole regulation in one breath. None of it is new.
We have done all of this for thirty years
Open ISO 26262. Open ISO 21434. Open DO-178C. Open IEC 62443. Different industries, similar paragraphs. Decomposition. Lifecycle process. Configuration management. Vulnerability management. Traceable updates.
Aerospace ships software under stricter constraints than CRA dares to mandate, on a regulatory regime older than most of the people writing CRA-readiness blog posts. Automotive has its own cybersecurity standard, with its own type approvals, and has lived inside it for half a decade. The methods exist. The textbooks exist. The people who have actually shipped under them exist.
They mostly do not work in OT.
OT’s real problem isn’t the regulation
CRA doesn’t hurt because it asks for too much. It asks for the bare minimum. CRA hurts because the typical HMI is a Windows box on a flat network, the typical SCADA stack is a monolith built when “threat model” was a phrase nobody used in plant engineering, and the typical PLC has been in the field so long that nobody can name the engineers who built its firmware.
The standards aren’t the problem.
CRA isn’t a cybersecurity regulation pretending to be product law. It’s an architecture regulation pretending to be cybersecurity.
You can’t bolt secure-by-design onto a system that wasn’t designed. You can’t ship security updates for a binary nobody knows how to rebuild. You can’t disclose a vulnerability in a stack you can’t enumerate. You can’t decompose a monolith you have been calling a platform for fifteen years.
That’s the actual cost. Not the compliance work. The thirty years of architectural debt the compliance work is finally pricing in.
Stop pretending
The uptime argument doesn’t work. Cars run uptime, and they have to drive themselves now. The legacy argument doesn’t work. Aerospace flies legacy. The air gap was never real, and any vendor still using the phrase in 2026 is telling on themselves.
CRA killed those excuses. The Machinery Regulation buried them. The playbook from automotive and aerospace transfers. The people who have lived inside it are findable. The standards that say how are public.
The next post in this series goes into the legal mechanics: Annex III and IV classification, the 24-hour reporting clause, the conformity assessment route a typical SCADA vendor will end up on, and what “support period” actually means once you read the small print. Until then, read ISO 21434. Read IEC 62443. They were always going to be the answer.
References: Regulation (EU) 2024/2847 (Cyber Resilience Act). Regulation (EU) 2023/1230 (Machinery Regulation). Directive (EU) 2022/2555 (NIS2). Commission Delegated Regulation (EU) 2022/30 (RED cybersecurity). ISO 26262, ISO 21434, DO-178C, IEC 62443.
