In etwa vier Monaten ist der Cyber Resilience Act keine Zukunftsmusik mehr. Die erste Frist — die Meldung von Schwachstellen durch Hersteller — fällt auf den 11. September 2026. Die vollen Pflichten greifen ab dem 11. Dezember 2027. Die OT-Welt hat davon ungefähr ein Jahr zu spät erfahren.
Auf dem Parkplatz draußen liefern die Autos seit 2021 unter ISO 21434 aus. In der Luftfahrt gilt eine Form von DO-178 seit den Achtzigern. Die Panik passt nicht zur Nachrichtenlage.
Vier Gesetze, eine Maschine
CRA für sich allein liest sich schon unangenehm. Im Verbund mit dem Rest liest es sich schlimmer.
CRA regelt die digitalen Bestandteile. Die neue Maschinenverordnung, Verordnung (EU) 2023/1230, die ab dem 20. Januar 2027 gilt, regelt die Maschine selbst und schreibt Cybersicherheit jetzt in die grundlegenden Sicherheits- und Gesundheitsschutzanforderungen. Die NIS2-Richtlinie, Richtlinie (EU) 2022/2555, regelt, wer das Ding betreibt. Die delegierte Verordnung RED 2022/30 regelt alles, was Funk spricht.
Vier sich überschneidende Rechtsakte auf einem Stück Hardware. Die Überraschung ist nicht eine einzelne Verordnung. Es ist die Überlappung.
Was CRA eigentlich will
Erwägungsgründe weglassen. Anhänge weglassen. CRA verlangt fünf Dinge: Security-by-Design in der Produktentwicklung, eine Software Bill of Materials, einen funktionierenden Schwachstellenprozess mit Meldung an ENISA, Sicherheitsupdates über einen definierten Support-Zeitraum und eine Konformitätsbewertung, die zur Risikoklasse passt.
Das ist die ganze Verordnung in einem Atemzug. Nichts davon ist neu.
Wir machen das seit dreißig Jahren
ISO 26262 aufschlagen. ISO 21434 aufschlagen. DO-178C aufschlagen. IEC 62443 aufschlagen. Andere Branchen, ähnliche Absätze. Dekomposition. Lebenszyklusprozess. Konfigurationsmanagement. Schwachstellenmanagement. Nachvollziehbare Updates.
Die Luftfahrt liefert Software unter Auflagen aus, die strenger sind als alles, was sich CRA traut, und das in einem Regulierungsregime, das älter ist als die meisten Leute, die heute CRA-Readiness-Posts schreiben. Die Automobilbranche hat ihren eigenen Cybersicherheitsstandard, ihre eigenen Typgenehmigungen und lebt seit gut fünf Jahren damit. Die Methoden gibt es. Die Lehrbücher gibt es. Die Leute, die das tatsächlich schon gemacht haben, gibt es auch.
Die wenigsten von ihnen arbeiten in OT.
OTs eigentliches Problem ist nicht die Verordnung
CRA tut nicht weh, weil zu viel verlangt wird. CRA verlangt das absolute Minimum. CRA tut weh, weil das typische HMI eine Windows-Kiste in einem flachen Netz ist, der typische SCADA-Stack ein Monolith aus einer Zeit, in der “Threat Model” in der Anlagentechnik niemand gesagt hat, und die typische SPS so lange im Feld ist, dass niemand mehr die Leute benennen kann, die ihre Firmware geschrieben haben.
Das Problem sind nicht die Standards.
CRA ist keine Cybersicherheitsverordnung, die sich als Produktrecht ausgibt. Es ist eine Architekturverordnung, die sich als Cybersicherheit ausgibt.
Security-by-Design lässt sich nicht an ein System schrauben, das nie designt wurde. Sicherheitsupdates lassen sich nicht für ein Binary ausliefern, das niemand mehr neu bauen kann. Schwachstellen lassen sich nicht offenlegen für einen Stack, den man nicht aufzählen kann. Ein Monolith, den man fünfzehn Jahre lang Plattform genannt hat, lässt sich nicht mal eben dekomponieren.
Das sind die echten Kosten. Nicht die Compliance-Arbeit. Die dreißig Jahre architektonische Schulden, die die Compliance-Arbeit jetzt fällig stellt.
Schluss mit der Sonderstellung
Das Uptime-Argument zieht nicht. Autos laufen auch unter Uptime und müssen mittlerweile selbst fahren. Das Legacy-Argument zieht nicht. In der Luftfahrt fliegt Legacy. Der Air-Gap war nie echt, und jeder Hersteller, der das Wort 2026 noch in den Mund nimmt, verrät sich selbst damit.
CRA hat diese Ausreden begraben. Die Maschinenverordnung hat sie zugeschüttet. Das Drehbuch aus der Automobil- und Luftfahrtbranche überträgt sich. Die Leute, die darin gelebt haben, sind auffindbar. Die Standards, die sagen, wie es geht, sind öffentlich.
Der nächste Beitrag dieser Serie geht in die Rechtsmechanik: Klassifizierung nach Anhang III und IV, die 24-Stunden-Meldepflicht, die Konformitätsbewertungsroute, auf der ein typischer SCADA-Hersteller landen wird, und was “Support-Zeitraum” tatsächlich bedeutet, sobald man das Kleingedruckte liest. Bis dahin: ISO 21434 lesen. IEC 62443 lesen. Sie waren immer schon die Antwort.
Quellen: Verordnung (EU) 2024/2847 (Cyber Resilience Act). Verordnung (EU) 2023/1230 (Maschinenverordnung). Richtlinie (EU) 2022/2555 (NIS2). Delegierte Verordnung (EU) 2022/30 (RED-Cybersicherheit). ISO 26262, ISO 21434, DO-178C, IEC 62443.
