newsonline24

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 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% 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:

1. Sicherheit bleibt aktuell – ohne Stillstand: Security-Patches ohne funktionale Auswirkung bedeuten geringes Risiko und keinen vollständigen Retest der Maschinenapplikation.
2. 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.
3. 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 es edge.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

1. „Exploitable“ ist der Hebel: Nicht jede CVE zählt, sondern deren Ausnutzbarkeit. Wer das versteht, reduziert den Patch-Aufwand drastisch, und arbeitet rechtskonform.
2. 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.
3. Dezember 2027 ist fix: Wer jetzt anfängt, hat noch Spielraum für einen strukturierten Rollout. Wer wartet, nicht.