CRA, CE und Asset Discovery im Maschinenbau

Was gilt für Maschinenbauer ab 2027?

Die wesentlichen Pflichten des Cyber Resilience Act gelten ab dem 11. Dezember 2027. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle beginnen bereits am 11. September 2026. Für Maschinenbauer ist zuerst zu klären, welche Maschine, Komponente oder Software als Produkt mit digitalen Elementen in den Anwendungsbereich fällt.

Der CRA erfasst grundsätzlich Hardware- und Softwareprodukte, die auf dem EU-Markt bereitgestellt werden und deren vorgesehene oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk einschließt. Ein Maschinenbauer wird zum Hersteller im Sinne des CRA, wenn er ein solches Produkt unter eigenem Namen oder eigener Marke in Verkehr bringt. Produktscope, Rolle in der Lieferkette und mögliche Bereichsausnahmen müssen deshalb pro Produktfamilie dokumentiert werden.

Ist eine automatische Komponenten-Inventur Voraussetzung für die CE-Kennzeichnung?

Nein, weder der CRA noch die Maschinenverordnung formulieren eine automatisierte Vollinventur aller Geräte im Maschinennetz als eigene CE-Voraussetzung. Der CRA verlangt vor dem Inverkehrbringen eine Cybersecurity-Risikobewertung, technische Dokumentation, das passende Konformitätsbewertungsverfahren, die EU-Konformitätserklärung und anschließend die CE-Kennzeichnung.

Das BSI behandelt diese Aufgaben ebenfalls getrennt: Teil 2 der TR-03183 konkretisiert formale und technische Anforderungen an SBOMs, während die Produkt-Risikobewertung und die allgemeinen Herstellerpflichten in einem eigenen Teil behandelt werden. Ein aktuelles OT-Asset-Inventar ist deshalb ein unterstützender technischer Nachweis. Es ersetzt weder die SBOM noch die Risikobewertung, Prüfung oder Konformitätserklärung.

Welche Nachweise müssen Maschinenbauer aufbauen?

Maschinenbauer brauchen eine nachvollziehbare Kette vom definierten Produkt über die Cybersecurity-Risikobewertung bis zu technischen Maßnahmen, Prüfergebnissen und Schwachstellenprozessen. Diese Unterlagen müssen vor dem Inverkehrbringen vorliegen und während des Supportzeitraums aktuell gehalten werden.

• Produktscope und Risikobewertung: vorgesehener Einsatzzweck, Schnittstellen, Netzwerkverbindungen, Datenflüsse, Bedrohungen und begründete Schutzmaßnahmen dokumentieren.
• Komponenten und Lieferkette: Drittkomponenten mit angemessener Sorgfalt bewerten und Software-Abhängigkeiten in einer SBOM nachvollziehbar halten.
• Technische Dokumentation: Architektur, Entwurf, Entwicklung, Produktionskontrollen, angewandte Anforderungen, Tests und Prozesse zur Schwachstellenbehandlung zusammenführen.
• Konformität und CE: das passende Bewertungsverfahren durchführen, die EU-Konformitätserklärung erstellen und die CE-Kennzeichnung erst danach anbringen.
• Support und Schwachstellen: Supportzeitraum festlegen, Sicherheitsupdates bereitstellen, Meldungen verarbeiten und die Betroffenheit eigener Produktversionen bewerten.

Daneben gilt die EU-Maschinenverordnung ab dem 20. Januar 2027. Sie enthält eigene Cyber-Safety-Anforderungen für konformitätsrelevante Software und Daten sowie für die Sicherheit und Zuverlässigkeit von Steuerungssystemen. Relevante legitime oder illegitime Eingriffe in Hardware, Software oder Konfiguration müssen nachvollziehbar werden. Diese Anforderungen sind von der CRA-Konformität zu unterscheiden und im CE-Projekt gezielt zusammenzuführen.

Warum reicht eine SBOM im Maschinennetz nicht aus?

Eine SBOM beschreibt, welche Software-Komponenten zu einer definierten Produkt- oder Softwareversion gehören. Sie zeigt nicht automatisch, welche Steuerungen, HMIs, Industrie-PCs, Antriebe oder Netzwerkgeräte in einer konkreten Maschine tatsächlich installiert sind, kommunizieren oder mit einem abweichenden Stand betrieben werden.

• SBOM: maschinenlesbare Zusammensetzung der Software und ihrer Abhängigkeiten. Sie enthält nicht automatisch eine Aussage zu Schwachstellen oder deren Ausnutzbarkeit.
• OT-Asset-Inventar: beobachteter Bestand mit Hersteller, Modell, Rolle, Standort, IP- und MAC-Adresse, Protokollen, Ports, Firmware- oder Softwareversion und, sofern verfügbar, Seriennummer.
• Schwachstelleninformationen: dynamische CVEs und Hersteller-Advisories, die gegen Produkt-, Software- und Firmwarestände abgeglichen werden müssen.
• Konformitätsnachweis: dokumentierte Bewertung, warum ein konkreter Stand die anwendbaren Anforderungen erfüllt und wie erkannte Risiken behandelt werden.

Wo entstehen Sichtbarkeitslücken unterhalb der SPS?

Eine SPS ist keine rechtlich definierte Sichtbarkeitsgrenze. Technisch können klassische IT-Scans aber an Routing-Grenzen, industriellen Gateways, segmentierten Zellen oder nicht IP-basierten Feldverbindungen enden. Dann sieht ein übergeordnetes System nur importierte Datensätze oder die direkt erreichbaren Netzteilnehmer, nicht zwangsläufig alle Komponenten der Maschine.

CISA empfiehlt deshalb, physische Inspektion und logische Bestandsaufnahme mit detaillierten digitalen und netzwerkbasierten Informationen zu kombinieren und auch dokumentierte Assets sowie Infrastrukturabhängigkeiten einzubeziehen. Kein einzelner Erfassungsweg liefert in jeder Maschinenarchitektur automatisch ein vollständiges Bild.

• Passive Netzsicht erkennt nur Geräte und Beziehungen, die im beobachteten Segment tatsächlich kommunizieren.
• Aktive Abfragen erreichen nur freigegebene Ziele und liefern nur die Merkmale, die Gerät und Protokoll lesend bereitstellen.
• Nicht IP-basierte oder hinter Gateways gekapselte Komponenten brauchen zusätzliche Engineering-, Gateway- oder Herstellerdaten.
• Firmwarestand, Hardware-Revision und Seriennummer sind deshalb Attribute mit belegter Quelle und Erfassungszeitpunkt, keine pauschal garantierten Scan-Ergebnisse.

Wie unterstützt secnostic sensor die Nachweisführung?

secnostic sensor liefert kontrollierte Beobachtungen aus Endpunkten und Netzwerken und gleicht den dokumentierten Bestand mit der technischen Realität ab. Er ist damit eine Datenquelle für Risiko-, Änderungs- und Schwachstellenprozesse, kein Werkzeug, das allein CRA-Konformität oder eine CE-Kennzeichnung erzeugt.

1. Maschinensegment passiv beobachten

   Gespiegelter Netzwerkverkehr macht aktive Geräte, Dienste und Kommunikationsbeziehungen sichtbar, ohne selbst Pakete an die Geräte zu senden. Neue oder bislang unbekannte Netzteilnehmer werden zu prüfbaren Änderungen.

2. Freigegebene OT-Fakten lesend erfassen

   Für ausdrücklich erlaubte Ziele können kontrollierte, nur lesende Protokollabfragen, beispielsweise über OPC UA oder Siemens S7, Identitäts- und Versionshinweise ergänzen. Erfasst wird nur, was das jeweilige Gerät und Protokoll tatsächlich bereitstellen.

3. Belege mit Herkunft zusammenführen

   Jeder Fund behält Quelle und Konfidenz. Passive Beobachtung, freigegebene Abfrage, Engineering-Unterlagen und bestehende Inventardaten lassen sich dadurch unterscheiden und gezielt validieren.

4. Soll und Ist abgleichen

   Produktstruktur, freigegebene Komponenten, SBOM und dokumentierte Firmwarestände werden mit dem beobachteten Maschinenbestand verglichen. Abweichungen fließen als konkrete Prüf- oder Änderungsaufgabe in den verantwortlichen Prozess.

Womit sollten Maschinenbauer jetzt beginnen?

Der sinnvolle Startpunkt ist nicht ein flächendeckender Scan, sondern ein abgegrenztes Produkt und eine klare Nachweiskette. So wird Asset Discovery Teil des Entwicklungs- und Änderungsprozesses statt einer isolierten Inventarliste.

1. Produkte und Rollen abgrenzen

   Pro Produktfamilie festhalten, welche digitalen Elemente, Netzverbindungen, Remote-Dienste und Drittkomponenten dazugehören und wer Herstellerpflichten trägt.

2. CRA und Maschinenverordnung getrennt zuordnen

   Anwendbare Anforderungen, Risikobewertungen, Prüfungen und Nachweise in einer gemeinsamen CE-Akte verknüpfen, ohne die beiden Regelwerke gleichzusetzen.

3. SBOM pro Softwarestand erzeugen

   Software-Abhängigkeiten aus dem Build-Prozess maschinenlesbar erfassen und mit Produktversion, Release und Schwachstellenprozess verbinden.

4. OT-Inventar pro Referenzarchitektur aufbauen

   Hersteller, Modell, Rolle, Schnittstellen, Protokolle, Firmware- oder Softwarestand, Seriennummer und Quelle als Zielattribute definieren und die Erfassbarkeit je Gerätetyp prüfen.

5. Änderungen nachweisbar machen

   Neue Geräte, abweichende Versionen und neue Kommunikationswege gegen freigegebene Baselines prüfen und mit Entscheidung, Verantwortlichem und Zeitpunkt dokumentieren.

6. Nachweise an einem Maschinentyp testen

   Mit einer repräsentativen Maschine beginnen und prüfen, ob Produktakte, SBOM, beobachteter Bestand, Schwachstellenbewertung und Änderungsverlauf eine widerspruchsfreie Evidenzkette bilden.