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 und münden in eine CE-Kennzeichnung, regeln aber Unterschiedliches und gelten zu unterschiedlichen Zeitpunkten. Die Meldungen nach Artikel 14 CRA gehen an das zuständige CSIRT und die ENISA.

Sie werden zum Hersteller, sobald Sie unter eigenem Namen in Verkehr bringen

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. Entscheidend ist, ob Sie eine definierte Maschine, Linie oder Anlage unter Ihrem Namen liefern, mit Ihrem Typenschild und Ihrer Konformitätserklärung. Dann sind Sie Hersteller, unabhängig davon, ob darin eine Standard-SPS mit Sensoren und Aktoren steckt oder etwas Hochspezialisiertes; wie neuartig das zusammengeführte System ist, spielt keine Rolle. Die CE-Kennzeichnung folgt aus dieser Rolle und begründet sie nicht: 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 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 den im Juli 2026 angenommenen Leitlinien 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.

Die Herstellerrolle bedeutet 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. Für den Zeitpunkt des Inverkehrbringens gilt dabei nach der Lesart der Kommission: Eine Schwachstelle in einer verbauten Komponente ist bekannt, sobald sie in der EUVD oder einer anderen öffentlichen Datenbank steht – unabhängig davon, ob ein Lieferanten-Advisory eingegangen ist (Beitrag zur bekannten Schwachstelle).

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:

Die MVO-Pflicht ist mit der Konstruktionsdokumentation beim Inverkehrbringen abgeschlossen; der wiederkehrende Aufwand aus Monitoring und Triage über Jahre entsteht aus dem CRA.

Ganz deckungsgleich sind beide Regelwerke 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 Meldepflicht greift über ein Jahr vor der CE-Pflicht

Für die Planung sind drei Daten maßgeblich:

Wer erst Ende 2027 mit dem Aufbau beginnt, hat den ersten Stichtag bereits verpasst; das Monitoring über die Lieferkette ist deshalb der zeitkritische Teil. Was bis zu jedem dieser Daten im eigenen Haus fertig sein muss, stellt der Fahrplan mit den Arbeitspaketen je Stichtag dar.

Die Umsetzung läuft als Schwachstellen-Pipeline in sechs Schritten

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.

Ein großer Teil der Zulieferkette liefert 2026 kein CSAF

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. Für Lieferanten, die dauerhaft nicht reagieren, bleibt die getriggerte Stichprobe als Fallback (siehe Schritt 6).

Aus dem CRA entsteht ein Patch-Geschäft für Anlagenbauer

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.

Der laufende Aufwand steckt im Monitoring über die Lieferkette, nicht in der Bedrohungsanalyse

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.