Schutz gegen Korrumpierung nach Maschinenverordnung: Anhang III Nr. 1.1.9 in der Risikobeurteilung
Anhang III Teil B Nr. 1.1.9 der Maschinenverordnung (EU) 2023/1230 verlangt ab dem 20.01.2027, dass angeschlossene Einrichtungen und Fernzugriffe zu keiner gefährlichen Situation führen, dass sicherheitsrelevante Hardware, Software und Daten gegen unbeabsichtigte und vorsätzliche Korrumpierung geschützt sind und dass die Maschine ihre sicherheitsrelevante Software identifiziert und Nachweise über Eingriffe sammelt. Nr. 1.2.1 ergänzt, dass Steuerungen, soweit angemessen, vernünftigerweise vorhersehbaren böswilligen Versuchen Dritter standhalten und Eingriffe sowie hochgeladene Sicherheitssoftware bis zu fünf Jahre rückverfolgbar bleiben; beides bewerten Sie in der Risikobeurteilung. CE-Copilot bildet den Schutz gegen Korrumpierung als Teil der Risikobeurteilung ab: Schnittstellen-Inventar, 15 Bedrohungsszenarien als Gefährdungen mit Maßnahmen in drei Stufen, angelehnt an den Normentwurf prEN 50742, und eine Nachweis-Checkliste, im Starter-Tarif ab 119 € pro Monat (Lizenz für jeweils drei Monate, Endpreis; Checkliste im Prüfprotokoll ab Professional).
Was Nr. 1.1.9 verlangt
Nr. 1.1.9 „Schutz gegen Korrumpierung“ ist neu im Maschinenrecht. Die Anforderung hat fünf Unterabsätze, hier sinngemäß nach der konsolidierten Fassung (der deutsche Wortlaut wurde am 01.04.2025 berichtigt; ältere Zitate weichen ab):
Angeschlossene Einrichtungen und Fernzugriff
Nr. 1.1.9 UAbs. 1
Der Anschluss einer anderen Einrichtung darf weder über eine Funktion dieser Einrichtung noch über eine entfernte Fernzugriffseinrichtung, die mit der Maschine kommuniziert, zu einer gefährlichen Situation führen.
Sicherheitsrelevante Hardware
Nr. 1.1.9 UAbs. 2
Hardware-Bauteile, die Signale oder Daten für den Zugriff auf konformitätsrelevante Software übertragen, sind angemessen gegen unbeabsichtigte oder vorsätzliche Korrumpierung zu schützen. Die Maschine sammelt Nachweise über rechtmäßige und unrechtmäßige Eingriffe in diese Bauteile.
Software und Daten
Nr. 1.1.9 UAbs. 3
Software und Daten, die für die Konformität mit den grundlegenden Anforderungen entscheidend sind, sind als solche kenntlich zu machen und angemessen gegen unbeabsichtigte oder vorsätzliche Korrumpierung zu schützen.
Identifikation der installierten Software
Nr. 1.1.9 UAbs. 4
Die Maschine identifiziert die installierte Software, die für den sicheren Betrieb erforderlich ist, und stellt diese Information jederzeit in leicht zugänglicher Form bereit.
Nachweise über Eingriffe in Software und Konfiguration
Nr. 1.1.9 UAbs. 5
Die Maschine sammelt Nachweise über rechtmäßige und unrechtmäßige Eingriffe in die Software und über Veränderungen der installierten Software oder ihrer Konfiguration.
Verknüpfung mit Nr. 1.2.1 „Sicherheit und Zuverlässigkeit von Steuerungen“
Nr. 1.2.1 überträgt den Gedanken auf die Steuerung. Steuerungen müssen, wenn den Umständen und Risiken angemessen, Fremdeinflüssen standhalten, ausdrücklich auch vernünftigerweise vorhersehbaren böswilligen Versuchen Dritter, die zu einer Gefährdungssituation führen (lit. a). Ein Defekt der Hard- oder Software darf nicht zu Gefährdungssituationen führen (lit. b). Die Grenzen der Sicherheitsfunktionen legt die Risikobeurteilung fest, und gefährliche Änderungen von Einstellungen oder Regeln sind ausgeschlossen, auch in einer Lernphase (lit. d). Neu ist lit. f: Das Rückverfolgungsprotokoll der Daten zu einem Eingreifen und der Versionen der Sicherheitssoftware, die nach dem Inverkehrbringen hochgeladen wurden, muss bis zu fünf Jahre nach dem Hochladen auf begründete Anforderung einer Behörde zugänglich sein.
Dazu kommen zwei Punkte, die jede vernetzte Maschine betreffen: Bei kabelloser Steuerung darf ein Ausfall oder eine fehlerhafte Verbindung nicht zu einer Gefährdungssituation führen (Nr. 1.2.1, letzter Unterabsatz), und Ausfall, Wiederherstellung oder Änderung der Kommunikationsnetzverbindung dürfen nicht zu gefährlichen Situationen führen (Nr. 1.2.6). Das Schutzziel aller dieser Anforderungen ist die Sicherheit von Personen, nicht der Schutz von Daten oder Know-how.
Was der Hersteller nachweisen muss
Die Maschinenverordnung schreibt keine bestimmte Technik vor, verlangt aber, dass jede Anforderung nachvollziehbar erfüllt ist. In der Praxis entstehen diese Nachweise:
| Anforderung | Fundstelle | Typischer Nachweis |
|---|---|---|
| Schnittstellen führen zu keiner gefährlichen Situation | Nr. 1.1.9 UAbs. 1 | Schnittstellen-Inventar, Bedrohungsszenarien mit Maßnahmen je Schnittstelle in der Risikobeurteilung, Schnittstellenbeschreibung für Integratoren |
| Sicherheitsrelevante Hardware geschützt, Eingriffe nachweisbar | Nr. 1.1.9 UAbs. 2 | Liste der geschützten Baugruppen, Plomben, gesperrte Ports, Ereignisliste der Steuerung mit Beispielprotokoll |
| Software und Daten benannt und geschützt | Nr. 1.1.9 UAbs. 3 | Verzeichnis der sicherheitsrelevanten Software und Daten mit Versionen und Prüfsummen, Beschreibung von Integritätsprüfung und Zugriffsschutz |
| Installierte Software jederzeit identifizierbar | Nr. 1.1.9 UAbs. 4 | Bildschirmfoto der Versionsanzeige, Abgleich mit dem Abnahmeprotokoll |
| Eingriffe in Software und Konfiguration protokolliert | Nr. 1.1.9 UAbs. 5 | Änderungs- und Ereignisprotokoll mit Benutzer, Zeit, Inhalt und Version, Exportweg |
| Steuerung hält vorhersehbaren böswilligen Versuchen Dritter stand | Nr. 1.2.1 lit. a | Security-Konzept mit Zonen, Rollen und Passwortregeln, Härtungsnachweis, Testprotokoll |
| Keine gefährlichen Änderungen von Einstellungen oder Regeln | Nr. 1.2.1 lit. d | Grenzen der Sicherheitsfunktionen aus der Risikobeurteilung, Schreibschutz sicherheitsrelevanter Parameter |
| Rückverfolgungsprotokoll bis fünf Jahre nach dem Hochladen | Nr. 1.2.1 lit. f | Speicher- und Aufbewahrungskonzept für Eingriffsdaten und Versionen der Sicherheitssoftware, Exportverfahren für Behördenanfragen |
| Ausfall des Kommunikationsnetzes oder der Funkverbindung ist ungefährlich | Nr. 1.2.6, Nr. 1.2.1 letzter UAbs. | Testprotokoll Kommunikationsausfall und Wiederanlauf in allen Betriebsarten, Stoppzeit bei Verbindungsabbruch |
In die technischen Unterlagen gehören die Risikobeurteilung mit der Liste der anwendbaren Anforderungen und den Schutzmaßnahmen (Anhang IV Teil A lit. b) und die Prüfberichte (lit. g). Neu ist lit. m: Quellcode oder Programmierlogik der sicherheitsrelevanten Software stellen Sie auf begründeten Antrag einer zuständigen Behörde zur Verfügung, wenn sie für die Prüfung der grundlegenden Anforderungen nötig sind (ebenso Art. 10 Abs. 3).
prEN 50742, IEC 62443 und die Vermutungswirkung
prEN 50742 „Sicherheit von Maschinen, Schutz gegen Korrumpierung“ ist der Normentwurf zu Nr. 1.1.9, erarbeitet bei CENELEC. In Deutschland ist er als Entwurf DIN EN 50742 (VDE 0113-742):2026-03 erschienen. Nach einem Fachbeitrag der IBF Solutions GmbH (zuletzt aktualisiert am 05.10.2026) befindet sich das Projekt in der Annahmephase („Approval Stage“); wann die EN erscheint, steht nicht fest. Eine Fundstelle im Amtsblatt unter der Maschinenverordnung hat der Entwurf nicht. Eine Konformitätsvermutung nach Art. 20 Abs. 1 entsteht erst mit einer solchen Fundstelle.
Der Entwurf beschreibt nach diesem Fachbeitrag zwei Wege. Weg A baut auf einer herstellerspezifischen Bedrohungsanalyse nach EN ISO 12100 auf, also in der gewohnten Risikobeurteilung. Weg B nutzt die Normenreihe IEC 62443 mit dem sicheren Entwicklungsprozess (IEC 62443-4-1), den Systemanforderungen (-3-3) und den Komponentenanforderungen (-4-2).
IEC 62443 ist die etablierte Normenreihe für die IT-Sicherheit industrieller Automatisierungssysteme und eine gute Orientierung für Security-Maßnahmen. Unter der Maschinenverordnung ist sie keine harmonisierte Norm und begründet keine Vermutungswirkung. Wer sie anwendet, beschreibt sie in den technischen Unterlagen als angewandte technische Spezifikation (Anhang IV Teil A lit. f) und zeigt in der Risikobeurteilung, wie die Maßnahmen die Gefährdungen von Personen mindern.
Einen weiteren Weg zur Vermutung sieht Art. 20 Abs. 9 vor: Maschinen, die nach einem Schema für die Cybersicherheitszertifizierung gemäß Verordnung (EU) 2019/881 mit Fundstelle im Amtsblatt zertifiziert sind oder für die eine Konformitätserklärung nach einem solchen Schema vorliegt, gelten für Nr. 1.1.9 und 1.2.1 als konform, soweit Zertifikat oder Erklärung die Anforderungen abdecken. Prüfen Sie, ob für Ihr Produkt ein solches Schema überhaupt in Frage kommt.
Verhältnis zum Cyber Resilience Act und zur Funkanlagenrichtlinie
- Cyberresilienz-Verordnung (EU) 2024/2847. Gilt für Produkte mit digitalen Elementen, also auch für vernetzte Maschinen, und schützt die Cybersicherheit des Produkts über seine Nutzungsdauer. Die Meldepflichten nach Art. 14 gelten seit dem 11.09.2026, auch für bereits ausgelieferte Produkte; die übrigen Pflichten gelten für Produkte, die ab dem 11.12.2027 in Verkehr gebracht werden. Nach Erwägungsgrund 53 kann die Erfüllung der CRA-Anforderungen den Nachweis für Nr. 1.1.9 und 1.2.1 erleichtern; die Synergie weist der Hersteller nach, und er befolgt die Konformitätsbewertung nach beiden Verordnungen. Eine Vermutung für Nr. 1.1.9 folgt aus der CRA-Konformität nicht. Einzelheiten im Ratgeber Cyber Resilience Act für Maschinen.
- Funkanlagenrichtlinie 2014/53/EU. Für Funkanlagen, die vom 01.08.2025 bis 10.12.2027 in Verkehr gebracht werden, gelten die Cyber-Anforderungen nach Art. 3 Abs. 3 lit. d, e und f über die Delegierte Verordnung (EU) 2022/30, mit der Normenreihe EN 18031. Die Delegierte Verordnung (EU) 2026/339 hebt sie mit Wirkung vom 11.12.2027 auf; danach übernimmt der CRA. Ob eine Maschine mit fest eingebautem Funkmodul insgesamt als Funkanlage gilt, ist nicht abschließend geklärt.
Dieselbe Schnittstelle kann also in bis zu drei Bewertungen auftauchen, mit unterschiedlichen Schutzzielen: Personen (Maschinenverordnung), Netz und Daten (Funkanlagenrichtlinie) und das Produkt über seine Nutzungsdauer (CRA). Zeitstrahl und Methoden im Ratgeber Cybersicherheit von Maschinen.
Vorgehen in sieben Schritten
1. Schnittstellen und schützenswerte Werte erfassen
Alle Wege, über die Daten oder Befehle in die Maschine gelangen: Netzwerk und Feldbus, Fernwartung, Cloud-Anbindung, Funk, USB und Speicherkarten, Bedienpanel mit Parameterverwaltung, Programmierzugang der Steuerung, Update-Pfad, zugängliche Sicherheitshardware im Schaltschrank und angeschlossene Fremdgeräte. Dazu die Software und Daten, die für die Sicherheit entscheidend sind, etwa Sicherheitsprogramm, Grenzwerte und Muting-Parameter.
2. Bedrohungen als Gefährdungen ermitteln
Je Schnittstelle fragen: Kann eine unbeabsichtigte oder vorsätzliche Korrumpierung eine gefährliche Situation auslösen? Typische Szenarien sind geänderte Sicherheitsparameter über das Netz, ein Fernzugriff während jemand im Gefahrenbereich arbeitet, eine nicht freigegebene Software-Version nach einem Update, gebrückte Sicherheitskontakte oder ein Kommunikationsausfall mit unerwartetem Wiederanlauf.
3. Risiko einschätzen und bewerten
Wie jede andere Gefährdung: Schwere des möglichen Schadens und Wahrscheinlichkeit. Für die Wahrscheinlichkeit zählen bei Security-Szenarien vor allem die Erreichbarkeit der Schnittstelle (Internet, lokales Netz, nur vor Ort), der nötige Aufwand und ob ein Eingriff erkannt wird.
4. Maßnahmen in der Rangfolge festlegen
Nach Nr. 1.1.2 lit. b zuerst konstruktiv, etwa sicherheitsrelevante Parameter nur in der Sicherheitssteuerung und über das Prozessnetz nicht beschreibbar; dann technische Schutzmaßnahmen wie Authentifizierung, signierte Updates, Segmentierung und Protokollierung; zuletzt Benutzerinformation.
5. Restrisiko bewerten und Wirksamkeit prüfen
Restrisiko je Szenario neu bewerten und die Maßnahmen prüfen: Versionsanzeige, Protokolleinträge nach einem Update, Verhalten bei Kommunikationsausfall, Freigabe des Fernzugriffs vor Ort. Die Prüfergebnisse gehören zu den Berichten nach Anhang IV Teil A lit. g.
6. Nachweis in den technischen Unterlagen
Die Risikobeurteilung mit der Liste der anwendbaren Anforderungen einschließlich Nr. 1.1.9 und den Schutzmaßnahmen (Anhang IV Teil A lit. b), die angewandten Spezifikationen bei Normentwürfen oder IEC 62443 (lit. f) und die Prüfberichte (lit. g). Quellcode oder Programmierlogik der sicherheitsrelevanten Software stellen Sie auf begründeten Antrag einer Behörde bereit (lit. m, Art. 10 Abs. 3).
7. Angaben in der Betriebsanleitung
Einen eigenen Security-Punkt hat Nr. 1.7.4.2 nicht. Die Angaben gehören zu Inbetriebnahme und Betrieb (lit. k), zu den Restrisiken (lit. l) und zu den Schutzmaßnahmen des Nutzers (lit. m): wo die Software-Version angezeigt wird, Update-Verfahren mit anschließender Funktionsprüfung der Sicherheitsfunktionen (Nr. 1.1.2 lit. e), Anforderungen an das Netz des Betreibers, Freigabe von Fernzugriffen und Aufbewahrung der Protokolle.
Beispiele: Schnittstelle, Bedrohung, Maßnahmen
| Schnittstelle | Bedrohung | Typische Maßnahmen |
|---|---|---|
| Netzwerk, OPC UA, MES | Unautorisierter Schreibzugriff ändert Muting-Zeiten oder Geschwindigkeitsgrenzen | Sicherheitsparameter nur in der Sicherheitssteuerung, über das Prozessnetz nicht beschreibbar; Authentifizierung, Prüfsumme der Sicherheitskonfiguration, Protokoll jeder Änderung |
| Fernwartung, VPN | Programmänderung oder Quittieren aus der Ferne, während Personen im Gefahrenbereich sind | Fernzugriff ohne Pfad zur Sicherheitssteuerung, Freigabe nur vor Ort und zeitlich begrenzt, Anzeige „Fernzugriff aktiv“, Sitzungsprotokoll |
| Software-Update | Manipulierte oder nicht freigegebene Version der Sicherheitssoftware wird eingespielt | Signierte Firmware mit Prüfung vor Aktivierung, Prüfsumme am Bedienpanel, Versionseintrag mit Aufbewahrung bis fünf Jahre, Funktionsprüfung nach jedem Update |
| Schaltschrank | Sicherheitskontakte gebrückt oder DIP-Schalter der Sicherheitsbaugruppe umgestellt | Verschlossener Schaltschrank, Plomben, codierte Steckverbinder, Erfassung des Öffnens mit Zeitstempel |
| Feldbus, Funk | Kommunikationsausfall, danach unerwarteter Anlauf mit veralteten Sollwerten | Zeitüberwachung der sicheren Telegramme, Übergang in den sicheren Zustand, Wiederanlauf nur nach Quittierung |
So bildet CE-Copilot den Schutz gegen Korrumpierung ab
CE-Copilot folgt dem Ansatz von Weg A des Entwurfs prEN 50742: Die Bedrohungsanalyse ist Teil der Risikobeurteilung nach EN ISO 12100, bewertet mit derselben Risikozahl aus Schwere und Wahrscheinlichkeit wie alle anderen Gefährdungen.
Modul „Schutz gegen Korrumpierung“ in der Risikobeurteilung
Erscheint im Editor der Risikobeurteilung, sobald die Maschinenbeschreibung digitale Schnittstellen nennt, etwa Netzwerk, Fernwartung, USB, Funk oder ein Bedienpanel mit Parameterverwaltung; sonst blenden Sie es über „Bewertungen nach weiteren Rechtsakten“ ein. Das Schnittstellen-Inventar kennt zehn Schnittstellenarten und wird aus der Beschreibung vorbelegt; ausdrücklich verneinte Nennungen wie „kein WLAN“ werden nicht übernommen. Sie bestätigen oder korrigieren die Auswahl, gespeichert wird sie im Maschinenprofil des Projekts.
ab Starter
15 Bedrohungsszenarien als Gefährdungen
Zu den gewählten Schnittstellen schlägt das Modul passende Szenarien vor, von der Parametermanipulation über das Netz bis zur fehlenden Protokollierung. Sie übernehmen nur, was Sie im Auswahldialog abhaken: als Gefährdung der Art „Korrumpierung/Security“ mit Szenario, Lebensphasen, Fundstelle, vorbelegter Schwere und Wahrscheinlichkeit und Maßnahmen in drei Stufen. Die Fundstelle richtet sich nach dem Regelwerk des Projekts: im MVO-Projekt Anhang III Nr. 1.1.9, 1.2.1 und 1.2.6, im Projekt nach Maschinenrichtlinie Anhang I Nr. 1.2.1 und 1.2.6 als Stand der Technik mit Hinweis auf Nr. 1.1.9 ab dem 20.01.2027. Je Szenario stehen die passenden Systemanforderungen der IEC 62443-3-3 als Referenz.
ab Starter
KI-Gefährdungssuche mit Blick auf die Schnittstellen
Enthält das Inventar Schnittstellen, fragt die KI-Gefährdungssuche zusätzlich gezielt nach maschinenspezifischen Szenarien, in denen eine Korrumpierung an genau diesen Schnittstellen eine gefährliche Situation auslösen kann, bewertet wie die übrigen Gefährdungen. Die Vorschläge sind Entwürfe, die Sie fachlich prüfen.
ab Starter, im KI-Kontingent des Tarifs
Nachweis im Export
Der PDF- und Word-Export der Risikobeurteilung und das Gesamtdossier enthalten einen Kasten „Schutz gegen Korrumpierung“ mit der Zahl der bewerteten Szenarien, dem Schnittstellen-Inventar und der Rechtsgrundlage, mit dem ausdrücklichen Hinweis, dass ohne Fundstelle im Amtsblatt keine Konformitätsvermutung besteht.
ab Starter
Prüfprotokoll-Sektion mit zwölf Anforderungen
Die Anforderungen A1 bis A12 beziehen sich auf Nr. 1.1.9, 1.2.1 und 1.2.6, dazu auf Betriebsanleitung und Update-Prozess, je mit Fundstelle, verlangtem Nachweis und Referenz auf IEC 62443. Im MVO-Projekt sind alle zwölf Pflicht, im Projekt nach Maschinenrichtlinie stehen die reinen MVO-Punkte als Empfehlung für das Inverkehrbringen ab dem 20.01.2027.
ab Professional
Kapitel Cybersicherheit in der Betriebsanleitung
Geprüfte Schnittstellen erscheinen mit Bezeichnung, Protokoll, Anbindung und Aktualisierungsweg in der Anleitung. Angaben zum Zugangsschutz stehen bewusst nicht im Dokument, damit die Anleitung keine Schwachstellenbeschreibung wird.
Modul Betriebsanleitung ab Professional, Einmalkauf je Projekt
Ein Inventar für Maschinenverordnung, Funkanlagen und CRA
Details je Schnittstelle und die schützenswerten Werte pflegen Sie einmal; das Funkanlagen-Modul und die Seite „Cybersicherheit (CRA)“ nutzen dasselbe Inventar. Das Modul weist außerdem darauf hin, dass die Cyber-Risikobewertung nach CRA eine eigene Bewertung neben Nr. 1.1.9 ist.
Inventar ab Starter, Seite Cybersicherheit (CRA) ab Professional
Was CE-Copilot nicht leistet: keine Zertifizierung, kein Penetrationstest, keine Prüfung Ihrer Steuerungssoftware und keine Einstufung in Security Level nach IEC 62443 oder nach dem Normentwurf (Weg B wird je Szenario als Referenz genannt, nicht durchgeführt). Den Normtext der prEN 50742 enthält die App nicht. Tarife und Preise auf der Preisseite.
Schutz gegen Korrumpierung im eigenen Projekt bewerten
Das Modul testen Sie 14 Tage kostenlos in der Risikobeurteilung. Wo Ihre Maschine sonst noch vor dem 20.01.2027 nachgezogen werden muss, zeigt der kostenlose MVO-Readiness-Check.
FAQ
Häufige Fragen zum Schutz gegen Korrumpierung
Gilt Nr. 1.1.9 für jede Maschine?
Ab wann muss ich den Schutz gegen Korrumpierung nachweisen?
Ist prEN 50742 eine harmonisierte Norm?
Reicht es, IEC 62443 anzuwenden?
Was hat der Schutz gegen Korrumpierung mit dem Cyber Resilience Act zu tun?
Muss der Schutz gegen Korrumpierung in die Risikobeurteilung?
Was gehört zum Schutz gegen Korrumpierung in die Betriebsanleitung?
Gibt es eine Software, die den Schutz gegen Korrumpierung in die Risikobeurteilung integriert?
Quellen
Fachinformation mit Stand 3. November 2026, keine Rechtsberatung. Rechtliche Aussagen geprüft gegen die Amtsblatt-Texte mit Stand 3. November 2026; Angaben zum Normentwurf prEN 50742 nach DIN Media und einem Fachbeitrag vom 05.10.2026. KI-Vorschläge in CE-Copilot sind Entwürfe; die Verantwortung für die Konformität bleibt beim Hersteller.