28. Juli 2026

8 MIN.

CRA: Wenn Security und Maschine getrennte Wege gehen

Der Problemraum: CRA und seine Konsequenz

Drei Risiken treffen Maschinenbauer gleichzeitig:

Marktzugang – CE-Kennzeichnung als Bedingung
Ohne CRA-Konformität gibt es ab Dezember 2027 keine CE-Kennzeichnung für Maschinen mit digitalen Elementen. Kein Marktzugang in der EU.

After-Sales-Umsatz – Retrofit unter CRA-Vorbehalt
Wesentliche Änderungen an Bestandsmaschinen lösen die CRA-Pflicht aus. Nicht-konforme Retrofits kosten Service-Geschäft.

Patch-Schulden – 13 Jahre Security-Pflicht
Der CRA fordert Security-Patches über die erwartete Produktlebensdauer. Bei Spezialmaschinen nach deutschen AfA-Tabellen sind das bis zu 13 Jahre (Art. 13(8)).

Und die Uhr läuft schneller als viele planen. Bereits ab September 2026 gilt die 24-Stunden-Meldepflicht an die ENISA für aktiv ausgenutzte Schwachstellen – 14 Monate vor der vollen Konformitätspflicht. Die Bußgelder liegen bei bis zu 15 Mio. Euro oder 2,5 Prozent des weltweiten Umsatzes pro Verstoß (Art. 64).

Entscheidend ist die Natur der Pflicht: CRA-Compliance ist kein Projekt mit Enddatum. Folgende Anforderungen laufen so lange, wie die Maschine im Feld ist:

Die Größenordnung: Die EU-Kommission schätzt die Compliance-Kosten der Hersteller EU-weit auf 29 Mrd. Euro (Impact Assessment SWD(2022) 282). Eine Befragung von Industrieausrüstern erwartet einen Anstieg des Produktentwicklungsbudgets von bis zu 20 Prozent pro Jahr (Risto et al., ARES 2025).

Das OEM-Geschäftsmodell trägt das nicht. Es ist auf Einmalverkauf gebaut, mit Umsatz über Features und Service und Engineering-Fokus auf Kundenwert. Der CRA erzwingt das Gegenteil: dauerhafte Schwachstellenpflege über bis zu 13 Jahre, Security-Patches kostenlos bereitzustellen, gebunden an knappe und teure Fachkräfte. Patch Debt bindet genau die Engineering-Kapazität, die in Produkt und Kundenwert fließen sollte.

Der Schlüsselbegriff: „Exploitable“

Hier liegt das entscheidende Missverständnis, und die entscheidende Chance.

Der CRA fordert keine Null-CVEs. Annex I, Teil I, Nr. 2(a) verlangt Produkte „without known exploitable vulnerabilities“. Der Maßstab ist die Ausnutzbarkeit, nicht die bloße Existenz einer Schwachstelle. Und der Auslöser ist das Risiko: Annex I, Teil II, Nr. 2 fordert, Schwachstellen „in relation to the risks posed“ ohne Verzug zu behandeln. Kein Patch für jede CVE.

Der Unterschied ist praktisch relevant:

Vulnerability – Eine dokumentierte Schwäche in der Software. Sie ist vorhanden, unabhängig davon, ob sie im konkreten Einsatz überhaupt erreichbar ist.

Exploitable Vulnerability – Dieselbe Schwäche, die unter realen Einsatzbedingungen tatsächlich ausgenutzt werden kann. Drei Faktoren machen den Unterschied: Erreichbarkeit, ein praktikabler Angriffsweg und eine wirksame Schutzmaßnahme.

Der CVSS-Score allein entscheidet das nicht. Eine Schwachstelle mit CVSS 9.8 in einer Bibliotheksfunktion, die nur über physischen Zugriff auf ein isoliertes, nicht vernetztes Feldbus-Segment erreichbar ist, ist im CRA-Sinne nicht exploitable. Eine Schwachstelle mit CVSS 6.5 in einer remote erreichbaren Management-Schnittstelle mit bekanntem, funktionierendem Angriffsweg ist es sehr wohl.

Die Zahlen dahinter: 119 neue CVEs pro Tag (BSI Lagebericht 2025), von denen rund 1,1 Prozent je in freier Wildbahn ausgenutzt werden (VulnCheck, 2014–2023). Das sind etwa 1,3 pro Tag. Wer nach Ausnutzbarkeit priorisiert statt nach Volumen, arbeitet an einer völlig anderen Menge.

Ausnutzbarkeit hat einen Ort

Daraus folgt die eigentliche Architekturfrage: Wo mitigiert man Ausnutzbarkeit?

Eine Schwachstelle wird nicht in jeder Codezeile ausnutzbar, sondern am Zugang zur Maschine. Wer die Mitigation in der Funktionssoftware verortet, muss jedes Release und jede Generation einzeln nachziehen: bewerten, patchen, auf Seiteneffekte, Regressionen und Breaking Changes testen, freigeben, kommunizieren. Pro Schwachstelle. Pro Version.

Wer sie am Zugang verortet, braucht eine Stelle. Einmal umgesetzt, wirksam über alle Maschinen und Generationen hinweg.

„where technically feasible, new security updates shall be provided separately from functionality updates“
– Annex I, Teil II, Nr. 2 CRA

Die Trennung von Security und Funktion ist damit nicht eine Option unter mehreren, sondern die logische Konsequenz aus dem Begriff der Ausnutzbarkeit und im CRA selbst angelegt.

Das Prinzip: Getrennte Wege gehen

Konkret bedeutet das eine dedizierte Sicherheitsschicht, die auf jeder Maschine identisch ist und unabhängig gewartet wird. Die Funktion ist je Maschine verschieden, die Security-Schicht ist es nie. Security-Updates fließen nur in die Schicht, Funktions-Updates nur in die Maschinensoftware. Eines berührt das andere nicht.

Drei Effekte ergeben sich daraus:

Sicherheit bleibt aktuell – ohne Stillstand
Security-Patches ohne funktionale Auswirkung bedeuten geringes Risiko und keinen vollständigen Retest der Maschinenapplikation.

Der Funktionsumfang bleibt beim Hersteller
Der funktionale Update-Plan richtet sich nach Kundenbedarf, nicht nach Security-Dringlichkeit. Der Kunde entscheidet, ob und wann er ein Release übernimmt.

Die Angriffsfläche schrumpft
Sicherheitsfunktionen werden aus der Maschinensoftware extrahiert und in einer gehärteten Schicht isoliert ausgeführt. Was nicht ausgeliefert wird, kann nicht angegriffen werden.

Und es stellt sich eine strategische Frage: Muss jeder Maschinenbauer diese Schicht selbst bauen und über 13 Jahre pflegen, oder gibt es einen gemeinsamen Ansatz für die Branche? Gebündelte Security-Kompetenz entlastet jeden einzelnen OEM, ohne dass er selbst Security-Spezialist werden muss.

edge.PSL: Unsere Umsetzung dieses Prinzips

edge.PSL ist TRIOVEGAs Protective Security Layer, ausgeliefert als untrennbare Softwarekomponente mit der Maschine, zu einem Bruchteil der Kosten gegenüber einer Eigenentwicklung.

TRIOVEGA unterstützt in Monitoring, Triage, Patch-Delivery sowie SBOM und Dokumentation über 13+ Jahre, mit einer Emergency Lane bei aktiver Ausnutzung und regelmäßigen geplanten Releases.

edge.PSL macht CRA-Konformität wirtschaftlich tragfähig. edge.PSL allein macht nicht CRA-konform. Beim Maschinenbauer verbleiben sichere Softwareentwicklung, physische Schnittstellensicherheit, Gesamt-Risikobewertung, CE-Kennzeichnung und End-of-Support-Entscheidungen.

Das Fundament

edge.PSL basiert auf TRIOVEGAs patentierter edge.SHIELDOR-Technologie, die bereits über hundert Produktionslinien schützt. Software AirGap und L7-Protokolltermination sind die Kerntechnologien: Kein Traffic passiert direkt zwischen IT- und OT-Interface. Gleiche technologische Basis, andere Marktrolle. edge.SHIELDOR schützt den Anlagenbetreiber, edge.PSL hält den Maschinenhersteller marktfähig.

Drei Takeaways

„Exploitable“ ist der Hebel. Nicht jede CVE zählt, sondern deren Ausnutzbarkeit. Wer das versteht, reduziert den Patch-Aufwand drastisch – und arbeitet rechtskonform.

Die Trennung von Security und Funktion macht CRA-Compliance wirtschaftlich. Sie ist keine Designoption, sondern die logische Konsequenz aus dem Begriff der Ausnutzbarkeit – und im CRA selbst angelegt.

Dezember 2027 ist fix. Wer jetzt anfängt, hat noch Spielraum für einen strukturierten Rollout. Wer wartet, nicht.

Jetzt den ersten Schritt machen

Buchen Sie sich einen Termin, um zu besprechen, wie edge.PSL Ihre Maschinen CRA-konform macht, ohne Eingriff in Ihre Maschinensoftware. Wir klären offene Fragen und prüfen gemeinsam, wie ein Deployment bei Ihnen aussehen könnte.

Mehr zu CRA und den Anforderungen für vernetzte Produkte finden Sie in unseren früheren Artikeln: Cyber Resilience Act – neue Herausforderungen in der Entwicklung vernetzter Produkte und CRA-Compliance meistern: Wie die Industrie jetzt Stärke zeigt. Wenn Sie wissen möchten, wo Ihr Unternehmen heute steht, vereinbaren Sie gerne einen unverbindlichen Beratungstermin mit unserem Team.

Autor: Benjamin Pieritz

Benjamin Pieritz bringt über 20 Jahre Erfahrung in industrieller Software mit und kennt Produktion vom Shopfloor aus. In 15 Jahren bei Werum IT Solutions, dem globalen Marktführer für Pharma-Manufacturing-IT (MES), stattete er weltweit hunderte Pharma-Werke aus – vom Engineering über Produktmanagement bis zum Executive Vice President & General Manager von Werum America. Die Übernahme durch die Körber AG brachte tiefen Einblick in den Maschinenbau. Seit 2021 führt er TRIOVEGA und dessen Transformation zum OT-Security-Produktunternehmen.

BUCHEN SIE IHR UNVERBINDLICHES BERATUNGSGESPRÄCH