Cyber Resilience Act im Maschinenbau: Warum dein Kundenportal jetzt Pflichtinfrastruktur wird

Im Maschinenbau ist der Cyber Resilience Act kein Thema für deine Entwicklungsabteilung. Er ist ein Vertriebsthema, und zwar seit dem 11. September 2026. An diesem Tag ist die Meldepflicht der Verordnung wirksam geworden. Wer von einer aktiv ausgenutzten Schwachstelle in seinem Produkt erfährt, meldet sie den Behörden und informiert die betroffenen Nutzer. Die Frage dahinter klingt banal: Über welchen Kanal erreichst du jeden Kunden, der eine deiner vernetzten Maschinen betreibt?

Wenn die ehrliche Antwort „eine Excel-Liste im Service, ein CRM mit Lücken und das Prinzip Hoffnung“ lautet, hast du ein Problem, und der Data Act legt eine zweite Pflicht obendrauf. Kunden haben ein Recht auf die Daten ihrer Maschinen, und bei Produkten, die nach dem 12. September 2026 in Verkehr kommen, muss dieser Zugang ab Werk eingebaut sein. Zwei Verordnungen, ein gemeinsamer Nenner: Du brauchst einen digitalen Ort, an dem Kunde und Maschine eindeutig zusammenkommen. Dieser Ort ist das Kundenportal.

Die Stichtage von Cyber Resilience Act und Data Act für Maschinenbauer

Stand Oktober 2026, alle Daten stammen aus den Verordnungstexten. Der CRA ist am 10. Dezember 2024 in Kraft getreten, das bestätigt die Übersichtsseite der EU-Kommission, seine Pflichten gelten gestaffelt nach Artikel 71 CRA. Der Data Act (Verordnung (EU) 2023/2854) gilt seit dem 12. September 2025, seine Staffelung regelt Artikel 50 Data Act.

Dieser Text ersetzt keine Rechtsberatung; ob und wie dein konkretes Produkt erfasst ist, klärst du mit einer Kanzlei oder deinem Verband.

Der CRA definiert sein „Produkt mit digitalen Elementen“ als Software- oder Hardwareprodukt samt seiner Datenfernverarbeitungslösungen (Artikel 3 CRA). Dazu zählt, was du selbst oder unter deiner Verantwortung entwickelt hast und ohne das die Maschine eine ihrer Funktionen nicht erfüllen könnte. Eine Werkzeugmaschine mit Steuerung, eigenem Fernwartungsmodul und eigenem Cloud-Dashboard ist damit nicht ein Produkt, sondern ein Bündel, und das Bündel fällt in den Anwendungsbereich.

CRA-Meldepflicht: 24 Stunden, 72 Stunden und deine Kunden

Artikel 14 ist der Teil des CRA, der für dich als Hersteller heute schon gilt, und er hat gegenüber den Behörden drei Taktstufen. Sobald du von einer aktiv ausgenutzten Schwachstelle erfährst, geht innerhalb von 24 Stunden eine Frühwarnung an das zuständige CSIRT und an die ENISA, über die zentrale Meldeplattform.

Innerhalb von 72 Stunden folgt die eigentliche Meldung mit Art der Ausnutzung und ersten Gegenmaßnahmen, spätestens 14 Tage nach Bereitstellung eines Fixes der Abschlussbericht (Artikel 14 CRA). Für schwerwiegende Sicherheitsvorfälle gilt derselbe Rhythmus, der Abschlussbericht dann binnen eines Monats.

Das ist die Behördenseite. Die Kundenseite steht in Absatz 8 desselben Artikels, und sie ist für dich die eigentlich teure. Sobald du Kenntnis hast, informierst du die betroffenen Nutzer über die Schwachstelle und über die Maßnahmen, die sie selbst ergreifen können, bei Bedarf in strukturierter, maschinenlesbarer Form. Eine Stundenfrist nennt das Gesetz hier nicht. Informierst du aber nicht rechtzeitig, kann das CSIRT deine Kunden selbst informieren, wenn es das für erforderlich hält.

Dein Schlüsselkunde erfährt von der Lücke in seiner Anlage dann von einer Behörde. Spätestens in der nächsten Lieferantenbewertung dürfte sein Einkauf danach fragen.

Die Meldepflicht gilt dabei nicht erst für Maschinen, die ab Dezember 2027 ausgeliefert werden. Artikel 69 Absatz 3 CRA erstreckt Artikel 14 ausdrücklich auf alle erfassten Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden. Deine installierte Basis fällt also darunter, inklusive der Anlage von 2019 mit dem Fernwartungsrouter, von der niemand mehr weiß, wer sie heute betreibt.

Für Maschinen, die ab dem 11. Dezember 2027 in Verkehr gebracht werden, gilt zusätzlich Artikel 13. Er verlangt einen Unterstützungszeitraum von mindestens fünf Jahren, Sicherheitsupdates, die nach Bereitstellung mindestens zehn Jahre abrufbar bleiben, und eine zentrale Anlaufstelle, über die Nutzer dir Schwachstellen melden können (Artikel 13 CRA). Bestandsmaschinen trifft das nur bei einer wesentlichen Änderung. Praktisch läuft beides auf eine dauerhafte, adressierbare Beziehung zu jedem Betreiber hinaus. Eine E-Mail-Adresse im ERP ist keine Beziehung.

Data Act im Maschinenbau: Datenzugang wird zur Design-Pflicht

Der Data Act dreht die Perspektive. Beim CRA schuldest du Information, beim Data Act schuldest du Daten. Ein „vernetztes Produkt“ ist dort jeder Gegenstand, der Daten über seine Nutzung oder Umgebung erzeugt und übertragen kann (Artikel 2 Data Act); die EU-Kommission nennt in ihrer Erläuterung zum Data Act Industriemaschinen ausdrücklich als Beispiel. Nutzer ist, wer die Maschine besitzt, gemietet oder geleast hat, also dein Kunde.

Nimm als fiktives Beispiel einen Betreiber, der im Service anruft. Er will die Betriebsstunden, Fehlercodes und Energieverbräuche seiner drei Anlagen aus den letzten zwölf Monaten, weil er ein Energieaudit vorbereitet. Heute zieht jemand eine CSV aus dem Dashboard des Steuerungslieferanten, sofern der Zugang noch funktioniert, und schickt sie per Mail.

Der Data Act macht aus dieser Gefälligkeit einen Anspruch, und zwar auf zwei Wegen. Die drei Anlagen stehen schon im Feld. Kann der Betreiber nicht selbst zugreifen, musst du als Dateninhaber seit dem 12. September 2025 die ohne Weiteres verfügbaren Daten ohne unangemessene Verzögerung bereitstellen, kostenlos, maschinenlesbar und, wo technisch machbar, kontinuierlich und in Echtzeit (Artikel 4 Data Act). „Ohne Weiteres verfügbar“ meint im Alltag eines Serviceleiters die Daten, die die Steuerung ohnehin loggt.

Bestellt derselbe Betreiber eine vierte Anlage, die nach dem 12. September 2026 in Verkehr gebracht wird, gilt Artikel 3 Absatz 1. Produktdaten und verbundene Dienstdaten müssen dann standardmäßig zugänglich sein, einfach, sicher, unentgeltlich, strukturiert, maschinenlesbar und, wo technisch machbar, direkt (Artikel 3 Data Act).

Welche Daten die Maschine erzeugt und wie er sie abruft, musst du oder dein Händler ihm schon vor Vertragsschluss sagen. Geschäftsgeheimnisse bleiben über vereinbarte Schutzmaßnahmen geschützt, verweigern darfst du den Zugang nur in eng begrenzten Fällen.

In einfachen Worten: Der Data Act verlangt eine authentifizierte Schnittstelle, über die ein bestimmter Kunde die Daten einer bestimmten Maschine zieht, als Download oder per API. Das ist technisch dieselbe Infrastruktur wie der Kanal für CRA-Sicherheitshinweise, nämlich ein Login, eine Zuordnung von Kunde zu Seriennummer und ein Backend mit Zugriff auf Maschinendaten und Dokumente.

Ein Portal, zwei Pflichtfunktionen: Sicherheitshinweise und Datenzugang

Ich plädiere deshalb nicht für zwei Compliance-Projekte, sondern für eines mit zwei Pflichtfunktionen. Das Portal hat einen harten Kern und eine weiche Hülle.

Zum harten Kern gehören eine Maschinenakte pro Seriennummer mit Betreiber, Softwarestand, Konformitätserklärung und Support-Zeitraum, eine Benachrichtigungsfunktion, die Sicherheitshinweise gezielt an die Betreiber betroffener Baureihen ausspielt und das Lesen protokolliert, sowie ein Datenzugang mit Export und API-Token. Dazu kommt eine Meldestrecke, über die Kunden dir Auffälligkeiten melden, als ein Teil der zentralen Anlaufstelle aus Artikel 13, neben Telefon und E-Mail.

Die weiche Hülle kennst du aus dem B2B-Commerce, mit Ersatzteilen, Serviceanfragen, Rechnungen und Nachbestellungen. Es gibt keinen Grund, beides getrennt zu bauen. Ein Self-Service-Portal auf Shopware-B2B-Basis bringt Rollen und Freigaben mit; Maschinenakte und Sicherheitshinweise kommen als eigene Module dazu. Wo der Standard nicht reicht, etwa bei Echtzeitdaten aus der Steuerung, sitzt ein eigener Service daneben.

Im ERP liegen Seriennummern, Auftragshistorie und Kundenstamm, dort entsteht die Wahrheit darüber, wer welche Maschine gekauft hat. Deshalb entscheidet die Anbindung an dein ERP über den Wert des Portals. Ohne diese Kopplung baust du eine zweite Datenwelt, die schnell vom ERP abweicht.

Angenommen, ein Hersteller von Verpackungsmaschinen (fiktives Beispiel) erfährt am Montagmorgen von einer ausgenutzten Schwachstelle im Fernwartungsmodul einer Baureihe, 340 Anlagen im Feld. Mit Portal filtert der Produktmanager die betroffenen Seriennummern, setzt den Sicherheitshinweis samt Workaround ab, sieht bis Mittwoch, welche Betreiber ihn geöffnet haben, und telefoniert nur den Rest ab.

Ohne Portal beginnt am Montag die Suche nach aktuellen Ansprechpartnern, quer durch ERP, CRM, Service-Tickets und die Postfächer der Außendienstler, bei 340 Anlagen, von denen ein Teil inzwischen den Besitzer gewechselt hat. Am Donnerstagmorgen ist die 72-Stunden-Meldung an die Behörde fällig, und niemand weiß belastbar, welche Betreiber den Hinweis bekommen haben.

Vom Pflichtkanal zum Aftersales-Umsatz

Hier wird aus der Pflicht ein Geschäftsmodell. Jeder Sicherheitshinweis führt deinen Kunden in dein Portal, jeder Datenexport auch. Du bekommst damit regelmäßige Kontakte mit dem Betreiber, die kein Vertriebler erzwingen muss, und weißt, welche Maschine wie alt ist und welchen Softwarestand sie hat.

Wer im Portal das Update für seine Steuerung sieht, sieht daneben die Verschleißteile dieser Baureihe, den fälligen Wartungsvertrag und das Retrofit-Angebot. Die Maschinenakte, die du brauchst, um Artikel 13 und 14 praktisch zu erfüllen, trägt auch einen Ersatzteilshop mit Explosionszeichnungen. Und der Export, den der Data Act verlangt, ist auch der Weg, über den du Condition Monitoring als Dienst verkaufst. Ein Beispiel ist ein Alarm, sobald die Lagertemperatur einer Spindel die Schwelle überschreitet, samt Vorschlag für das nächste Wartungsfenster.

Auch die nächste Regulierung kann auf dieser Maschinenakte aufsetzen. Der Digitale Produktpass wird schrittweise je Produktgruppe einen digitalen Datensatz verlangen, je nach Rechtsakt pro Modell, Charge oder Einzelstück, abrufbar über einen Datenträger wie einen QR-Code. Wer heute eine saubere Seriennummernlogik aufsetzt, hat einen guten Teil davon schon.

Der Data Act hat allerdings eine unbequeme Seite, die du einpreisen solltest. Dein Kunde darf die Maschinendaten an Dritte weitergeben, etwa an unabhängige Wartungsanbieter, und die EU-Kommission nennt mehr Wettbewerb im Service ausdrücklich als Ziel der Verordnung. Wenn ein freier Servicedienstleister künftig dieselben Betriebsdaten sieht wie du, entscheidet der Betreiber nach Komfort. Er bleibt bei dem Portal, in dem er Maschine, Softwarestand und passendes Ersatzteil am schnellsten findet.

Was ich an deiner Stelle jetzt tun würde

Meine Empfehlung ist unspektakulär und deshalb umsetzbar.

1. Ein Inventar. Welche deiner Produkte haben Software, Konnektivität oder eine Cloud-Anbindung, welche davon stehen wo im Feld, und wen erreichst du dort heute? Diese Liste ist die Grundlage für jede Meldung und jede Nutzerinformation nach Artikel 14. Wenn sie bisher nur in den Köpfen des Service existiert, ist sie der erste Arbeitsauftrag.
2. Ein Portal-Minimum vor dem Vollausbau. Login, Maschinenakte je Seriennummer, Benachrichtigung mit Lesebestätigung, Datenexport. Mit dem ERP als gesetzter Quelle sollte sich das in einigen Monaten umsetzen lassen. Ersatzteilshop, Serviceverträge und Echtzeitdaten baust du danach auf dieselbe Basis.
3. Den internen Meldeprozess üben, bevor der Ernstfall ihn erzwingt. Leg fest, wer die Frühwarnung auch am Wochenende freigibt, und spiel den Ablauf einmal mit einer angenommenen Schwachstelle durch.

Cyber Resilience Act und Data Act werden gern als Bürokratie beschrieben, und ein Teil davon ist es. Der größere Teil ist eine Antwort auf eine Frage, die der Maschinenbau lange offen gelassen hat: Wer kennt eigentlich den Betreiber der Maschine, nachdem sie das Werk verlassen hat? Seit dem 11. September 2026 musst du sie beantworten können, ab dem 11. Dezember 2027 gilt der CRA vollständig. Beantworte sie gründlich, dann gehört dir der Kanal, und nicht dem freien Servicedienstleister, der ihn sonst besetzt.