CRA und Maschinenverordnung für Anlagenbauer und Integratoren: Was ab 2026 gilt

Ab 2026 greifen zwei EU-Verordnungen ineinander, die jeden betreffen, der Anlagen baut und in Verkehr bringt: der Cyber Resilience Act (CRA) und die neue Maschinenverordnung (EU) 2023/1230 (MVO). Beide fordern Cybersicherheit, beide münden in eine CE-Kennzeichnung. Sie regeln aber Unterschiedliches, gelten zu unterschiedlichen Zeitpunkten, und keine ersetzt die andere.

Ab dem 11. September 2026 müssen aktiv ausgenutzte Schwachstellen nach Artikel 14 CRA gestaffelt gemeldet werden – Frühwarnung binnen 24 Stunden, Schwachstellenmeldung binnen 72 Stunden und Abschlussbericht binnen 14 Tagen an das zuständige CSIRT und die ENISA, auch für Anlagen, die bereits im Feld stehen. Was das für Rollen, Fristen und die eigene Schwachstellen-Pipeline bedeutet, der Reihe nach.

Wann werden Sie als Anlagenbauer oder Integrator zum „Hersteller"?

Der CRA knüpft die Pflichten an die Rolle des Herstellers. In diese Rolle fallen Integratoren regelmäßig: Wer Komponenten zu einer Anlage zusammenführt und diese unter eigenem Namen in Verkehr bringt (Art. 3 Nr. 13), gilt als Hersteller des Gesamtprodukts. Das Gleiche gilt bei einer wesentlichen Änderung an einem Bestandsprodukt (Art. 22).

• Einzelstück oder Sonderanfertigung schützt nicht – die Pflicht gilt pro Produkt, nicht erst ab Stückzahl.
• Ein reiner Bugfix ist in der Regel keine wesentliche Änderung. Eine neue Funktion oder mehr Angriffsfläche dagegen schon.
• Die Folge: volle Herstellerpflichten für das Gesamtprodukt, inklusive der zugekauften Fremd- und Open-Source-Komponenten.

Für die meisten Anlagenbauer ist das keine offene Frage. Der Auslöser ist nicht, wie neuartig das zusammengeführte System ist, sondern eine einfache Frage: Liefern Sie eine definierte Maschine, Linie oder Anlage unter Ihrem Namen – mit Ihrem Typenschild und Ihrer Konformitätserklärung? Wenn ja, sind Sie Hersteller, unabhängig davon, ob darin eine Standard-SPS mit Sensoren und Aktoren steckt oder etwas Hochspezialisiertes. Denn nicht die CE-Kennzeichnung macht den Hersteller; es ist umgekehrt: Wer unter eigenem Namen in Verkehr bringt, ist Hersteller und bringt deshalb die CE-Kennzeichnung an und zeichnet die Konformitätserklärung. Wer für die Gesamtanlage heute schon eine Konformitätserklärung unterschreibt – unter der MVO bzw. der alten Maschinenrichtlinie als Hersteller der „Gesamtheit von Maschinen" ohnehin der Fall – hat die Herstellerrolle für dieses Produkt bereits übernommen. Der CRA begründet diese Rolle nicht neu; er fügt ihr eine zweite Anforderungsdimension hinzu, sobald die Anlage digitale Elemente enthält.

Die Europäische Kommission beschreibt diesen Fall am Beispiel einer Lebensmittelverpackungsmaschine: Sie kann zugleich eine Maschine im Sinne der MVO und ein Produkt mit digitalen Elementen im Sinne des CRA sein. In diesem Fall sind beide Anforderungssätze zu prüfen und zu erfüllen, und beide Konformitätsbewertungen sind separat zu durchlaufen; die Erfüllung des einen ersetzt das andere nicht.

Eine Grenze gibt es: Wer als reiner Monteur einzeln CE-gekennzeichnete Geräte beim Kunden verkabelt, ohne sie zu einem eigenen, unter seinem Namen gelieferten Produkt zu verbinden, ist nicht Hersteller eines neuen Produkts. Diese Grenze verläuft entlang von Inverkehrbringen und Inbetriebnahme und wird vor allem bei sehr großen, erst auf dem Kundengelände errichteten Komplettanlagen unscharf – nach dem (rechtlich unverbindlichen) Leitfaden-Entwurf der Kommission fallen auch komplexe Systeme aber nicht automatisch heraus, sondern sind risikobasiert zu bewerten. Für eine definierte Maschine oder eine abgegrenzte Linie greift dieser Vorbehalt nicht: Sie ist als Produkt in Verkehr gebracht. Größe macht die Einordnung damit nicht sicherer, sondern an der Außenkante eher unschärfer.

Das verbreitete Argument „wir stecken nur eine SPS mit Aktoren und Sensoren zusammen" ändert daran nichts: Sobald das Ergebnis als Ihre Maschine unter Ihrem Namen ausgeliefert wird, ist es Ihr CRA-Produkt. Das bedeutet aber nicht, dass Sie jede fremde Komponente bis ins Detail selbst analysieren müssen. Der CRA ist als geschichtetes Modell angelegt: Jede CRA-pflichtige Komponente hat einen eigenen Hersteller, der für ihre Advisories und Updates haftet. Auf deren CE-Kennzeichnung und Vendor-Advisories dürfen Sie sich stützen; die Sorgfaltspflicht bei der Integration bleibt (Art. 13 Abs. 5). Schwachstellenmanagement und Konformitätserklärung für die Gesamtmaschine liegen jedoch bei Ihnen (Art. 13 Abs. 1) – die Pflicht gilt für das Produkt in seiner Gesamtheit, einschließlich aller integrierten Komponenten.

CRA und Maschinenverordnung greifen parallel

MVO und CRA gelten parallel. Beide führen zur CE-Kennzeichnung, beide gehören in die Konformitätserklärung. Sie verfolgen aber unterschiedliche Schutzziele, und das bestimmt, wie tief jeweils zu analysieren ist.

• Die MVO schützt Menschen. Cybersicherheit ist hier nur safety-gerahmt relevant: geschützt werden muss, was zu einer gefährlichen Situation führen kann (Anhang III, 1.1.9 Schutz gegen Korrumpierung und 1.2.1 Steuerungen).
• Der CRA schützt das Produkt. Es geht um IT-Sicherheit über die gesamte Angriffsfläche – Vertraulichkeit, Integrität, Verfügbarkeit – und das über den kompletten Support-Zeitraum.

Inhaltlich sind die safety-relevanten Bedrohungen der MVO eine Teilmenge des CRA-Security-Scopes. Wer den CRA sauber umsetzt, deckt die Cyber-Substanz der MVO inhaltlich weitgehend ab. Die folgende Gegenüberstellung zeigt die Abgrenzung:

Aus dem unterschiedlichen Zeithorizont folgt eine praktische Unterscheidung: Die MVO-Pflicht ist mit der Konstruktionsdokumentation beim Inverkehrbringen abgeschlossen. Der wiederkehrende Aufwand aus Monitoring und Triage über Jahre entsteht dagegen aus dem CRA.

Ganz deckungsgleich ist das aber nicht. Eine saubere CRA-Erfüllung kann die MVO-Anforderungen 1.1.9/1.2.1 abdecken – allerdings nur „sofern nachgewiesen" über eine harmonisierte Norm, und die ist noch nicht im EU-Amtsblatt gelistet. Hinzu kommt ein konzeptioneller Unterschied: Ein für den CRA akzeptables Restrisiko, das eine Safety-Funktion aushebeln könnte, muss unter der MVO trotzdem konstruktiv beseitigt werden. Für safety-kritische Bedrohungen liegt die MVO-Schwelle damit höher. Und eine MVO-Pflicht hat im CRA gar kein Gegenstück: das manipulationssichere Logging safety-relevanter Eingriffe (Firmware-Updates, Konfigurationsänderungen) über mindestens fünf Jahre.

Die Timeline: Was ab wann gilt

Für die Planung sind drei Daten maßgeblich. Die erste Frist ist nicht die CE-Kennzeichnung, sondern die Meldepflicht:

Entscheidend ist die Reihenfolge: Die Meldepflicht greift über ein Jahr vor der CE-Pflicht, und sie gilt rückwirkend für Anlagen, die heute schon laufen. Wer erst Ende 2027 beginnt, hat den ersten Stichtag bereits verpasst. Der Aufbau des Monitorings über die Lieferkette ist deshalb zeitkritisch.

Umsetzung in der Praxis: die Schwachstellen-Pipeline

Das Vorgehen lässt sich verhältnismäßig halten: eigene Tiefenanalysen vermeiden, sich auf kuratierte Advisories der Direktlieferanten stützen, diese vertraglich absichern, auf die eigene Anlage mappen und nur das Integrations-Delta selbst prüfen. Im Einzelnen sechs Schritte:

1. HW-BOM auf Firmware-Versionen mappen – für alle neuen Anlagen ab sofort. Ergebnis ist eine Matrix aus Anlagen × Komponenten × Zulieferern. Wichtig: Eine Hardware-Stückliste ist keine SBOM. Der CRA verlangt eine Software-Stückliste mit CVE-fähigen IDs (CPE/PURL und Version).
2. Direktlieferanten-Feeds monitoren – nicht die Feeds der Sub-Komponenten. Primär maschinenlesbar über CSAF; Long-Tail-Lieferanten ohne CSAF über RSS, E-Mail oder manuell, normalisiert auf eine einzige Sicht.
3. Meldung auf Anlage mappen – über Lieferant, exakte Komponente, Version und CPE. Der Eintrag muss CVE-matchbar sein, nicht bloß „genannt".
4. Deployment-Bedingungs-Check statt Re-Triage – sagt der Lieferant „not affected unter Bedingung X", prüfen Sie nur, ob Ihre Verdrahtung diese Bedingung einhält. Keine Architektur- oder Source-Tiefenanalyse fremder Closed-Komponenten.
5. PSIRT-Entscheid – ist die Schwachstelle im konkreten Anlagenkontext ausnutzbar? Wenn ja: Maßnahme festlegen, Kunden informieren und gegebenenfalls die 24h-/72h-Meldung an die ENISA auslösen.
6. Getriggerte Stichprobe als Fallback – nicht zufällig, sondern anlassbezogen: bei aktiv ausgenutzten Lücken (KEV) und gleichzeitigem Schweigen des Lieferanten über die SLA hinaus selbst gegenchecken. Plus ein periodischer Audit der Lieferanten-Reaktionsfähigkeit.

Verhältnismäßig bleibt der Aufwand vor allem durch eine Grenze: Ein geschlossenes Lieferanten-Modul wird als Grenzknoten behandelt und nicht weiter aufgelöst. Rohe Sub-Komponenten-Feeds erzeugen sonst vor allem Rauschen – ein roher Jetson-Feed etwa bringt rund 5.500 Kernel-CVEs pro Jahr, davon etwa 85 % ohne Score. Das Produkt-Level-VEX des Direktlieferanten senkt die Fehlalarme am stärksten, weil es den Mapping-Schritt schon erledigt hat.

Vertraglich gehört in jeden Direktlieferanten-Rahmen eine Klausel, die je Release ein maschinenlesbares CSAF/VEX fürs Produkt – inklusive Sub-Komponenten-Schicht – in definierter SLA zusichert. Damit entfällt die eigene Tiefenanalyse.

Was tun mit Lieferanten, die kein CSAF liefern?

CSAF ist das maschinenlesbare Standardformat, aber ein großer Teil der DACH-Zulieferkette wird es 2026 nicht bereitstellen. Mittelständische Komponentenhersteller veröffentlichen Advisories heute als PDF, als Newsletter, als Eintrag auf einer Support-Seite oder gar nicht. Wer sich nur auf CSAF-fähige Lieferanten stützt, lässt die Lücken offen, aus denen später meldepflichtige Fälle entstehen.

Diese unstrukturierten Quellen müssen aktiv eingesammelt und auf dieselbe Sicht normalisiert werden wie die CSAF-Feeds: RSS- und Mailing-Listen abgreifen, Support-Seiten beobachten, eingehende E-Mail-Advisories auswerten und das Ergebnis auf Lieferant, Komponente und Version mappen. Dieses Einsammeln und Vereinheitlichen über das gesamte Spektrum von CSAF bis E-Mail automatisieren wir bei Werkspilot. Für Lieferanten, die dauerhaft nicht reagieren, bleibt die getriggerte Stichprobe als Fallback (siehe Schritt 6).

Das Patch-Geschäft, das aus dem CRA entsteht

Der CRA wird oft nur als Kostenposition gesehen. Aus ihm entsteht aber auch ein Geschäftspotenzial für Anlagenbauer. Grund ist eine Asymmetrie in der Lieferkette: Die Schwachstellen-Updates der Komponentenhersteller sind kostenlos; sie sind nach CRA verpflichtet, diese über den Support-Zeitraum bereitzustellen. Was die Komponentenhersteller nicht liefern, ist die Arbeit, die beim Anlagenbauer anfällt:

• Integration des Updates in die konkrete Anlagenkonfiguration – ein Firmware-Update für eine Komponente ist nicht automatisch für die Gesamtanlage freigegeben.
• Absicherung und Regression – sicherstellen, dass das Update keine Safety-Funktion aushebelt und die Anlage weiter spezifikationskonform läuft.
• Tests und Wiederinbetriebnahme im Feld, dokumentiert für den CRA-Nachweis.

Diese drei Schritte fallen wiederkehrend an, über den gesamten Support-Zeitraum von mindestens fünf Jahren, und lassen sich beim Kunden vertraglich abbilden. Wer das Monitoring ohnehin betreibt, erkennt zuerst, welche Anlage von welcher Schwachstelle betroffen ist, und kann den Patch-Service proaktiv anbieten. Aus der regulatorischen Pflicht wird damit ein planbarer, wiederkehrender Service-Umsatz.

Das laufende Monitoring über die Lieferkette

Daneben verlangen MVO und CRA eine nachvollziehbare Risikobeurteilung der Cybersicherheit; das übliche Werkzeug dafür ist eine STRIDE-Bedrohungsanalyse je Anlagentyp; die wird einmal erstellt und dann gepflegt. Der laufende Aufwand steckt im täglichen Monitoring über die Lieferkette.

Bei manueller Bearbeitung scheitert dieses Monitoring an der 24h-Frist. Zur Größenordnung: Schon aus einem gut gepflegten Lieferanten-Feed kommen einige Hundert CVEs pro Jahr; über den gesamten Lieferantenstamm summiert sich das auf tausende gematchte Meldungen pro Jahr, von denen am Ende eine Handvoll wirklich meldepflichtig ist. Dieser Trichter lässt sich von Hand nicht bewältigen, zumal der Komponenten-Pool rund 20 % pro Jahr wächst. Das Sichten, Mappen und Dokumentieren bindet über einen mittelgroßen Anlagenpark schnell mehrere Personentage pro Monat – mit jeder neuen Anlage mehr; und wenn ein Fall aktiv ausgenutzt wird, muss dieselbe Arbeit binnen Stunden geleistet werden.

Diese Pipeline automatisiert Werkspilot: Lieferanten-Feeds von CSAF bis E-Mail kontinuierlich erfassen, neue Schwachstellen automatisch mit den Anlagen im Feld abgleichen, zentral bewerten und auf Knopfdruck fristgerecht an die Kunden und die ENISA melden. Aus tausenden Meldungen bleibt am Ende das, was die eigenen Anlagen wirklich betrifft, nachvollziehbar dokumentiert für den Prüffall.

Wenn Sie sehen möchten, wie das für Ihre Anlagen konkret aussieht, vereinbaren Sie ein Gespräch.

Dieser Beitrag fasst den Stand der Regulierung zum Zeitpunkt der Veröffentlichung zusammen und ersetzt keine Rechtsberatung. Maßgeblich sind die Verordnungstexte selbst.