CRA: Wenn Security und Maschine getrennte Wege gehen
Der Problemraum: CRA und seine Konsequenz. Aktuell treffen drei Risiken Maschinenbauer gleichzeitig:
(PresseBox) - Erstens, 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. Zweitens, After-Sales-Umsatz – Retrofit unter CRA-Vorbehalt: Wesentliche Änderungen an Bestandsmaschinen lösen die CRA-Pflicht aus. Nicht-konforme Retrofits kosten Service-Geschäft. Und drittes, 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)).
Die Uhr läuft schneller als viele planen, denn 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:
SBOM erstellen und laufend pflegen
Schwachstellen kontinuierlichüberwachen
Risikobewertung je CVE
Sicherheitsupdates ohne Verzug liefern
Conformity Assessment
Regelmäßige Sicherheitstests
ENISA-Meldungen nach 24 Stunden, 72 Stunden und 14 Tagen
Coordinated Vulnerability Disclosure
Technische Dokumentationüber mindestens 10 Jahre oder den gesamten Supportzeitraum
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% 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 undteure 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% 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.
edge.PSL ist
Eine Komponente zur Mitigierung der Ausnutzbarkeit von Schwachstellen, rechtlich untrennbar von der Maschine, technisch unabhängig wartbar
Teil der Maschine, ausgeliefert vom OEM, CE-Erklärung verbleibt beim Maschinenbauer
Unabhängig von der Maschinensoftware aktualisierbar, Security-Patches ohne Eingriff in die Funktion
Konfigurierbarüber einen Blueprint je Maschine, der nur das benötigte Subset ausliefert
edge.PSL ist nicht
Ein Ersatz für die Maschinensoftwareentwicklung des OEM
Die vollständige CRA-Konformitätslösung im Alleingang
Ein Ersatz für Betreiberlösungen (dafür gibt esedge.SHIELDOR)
Ein Outsourcing der Herstellerverantwortung
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 zahlreiche 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.
TRIOVEGA begleitet seitüber 25 Jahren von den Standorten Lübeck und Braunschweig heraus Industrieunternehmen weltweit dabei, das Potenzial der Digitalisierung sicher und nachhaltig zu erschließen. Das Portfolio umfasst einsatzfertige Produkte und Dienstleistungen zur Steigerung von Produktionssicherheit und Effizienz sowie individuell entwickelte Softwarelösungen, die sich nahtlos in die Wertschöpfungsketten der Kunden integrieren lassen. Mit mehrfach ausgezeichneter Innovationskraft und zertifizierter als auch patentierter Cybersicherheitsexpertise steht TRIOVEGA für partnerschaftliche Zusammenarbeit auf Augenhöhe - von der technischen Beratung über die Umsetzung bis zum After-Sales-Service.
TRIOVEGA begleitet seitüber 25 Jahren von den Standorten Lübeck und Braunschweig heraus Industrieunternehmen weltweit dabei, das Potenzial der Digitalisierung sicher und nachhaltig zu erschließen. Das Portfolio umfasst einsatzfertige Produkte und Dienstleistungen zur Steigerung von Produktionssicherheit und Effizienz sowie individuell entwickelte Softwarelösungen, die sich nahtlos in die Wertschöpfungsketten der Kunden integrieren lassen. Mit mehrfach ausgezeichneter Innovationskraft und zertifizierter als auch patentierter Cybersicherheitsexpertise steht TRIOVEGA für partnerschaftliche Zusammenarbeit auf Augenhöhe - von der technischen Beratungüber die Umsetzung bis zum After-Sales-Service.
Datum: 29.07.2026 - 11:27 Uhr
Sprache: Deutsch
News-ID 2264673
Anzahl Zeichen: 0
Kontakt-Informationen:
Ansprechpartner: Isabella Gaafke
Stadt:
Lübeck
Telefon: +49 451397710
Kategorie:
Maschinenbau
Dieser Fachartikel wurde bisher 5 mal aufgerufen.
Der Fachartikel mit dem Titel:
"CRA: Wenn Security und Maschine getrennte Wege gehen"
steht unter der journalistisch-redaktionellen Verantwortung von
TRIOVEGA GmbH (Nachricht senden)
Beachten Sie bitte die weiteren Informationen zum Haftungsauschluß (gemäß TMG - TeleMedianGesetz) und dem Datenschutz (gemäß der DSGVO).