Funktionale Sicherheit schützt Menschen und Umwelt vor einem fehlerhaften System, Cyber Security schützt das System vor einem Angreifer. Lange wurden beide Disziplinen getrennt entwickelt, geprüft und zertifiziert. In vernetzten, softwaregetriebenen Systemen funktioniert diese Trennung nicht mehr: Ein erfolgreicher Cyberangriff kann eine Sicherheitsfunktion aushebeln und damit direkt zum Safety-Vorfall werden. Normen wie IEC TR 63069 und TS 50701 bauen die Brücke zwischen IEC 61508 und IEC 62443, während NIS2, der Cyber Resilience Act und die neue Maschinenverordnung den regulatorischen Druck erhöhen. Wer beide Disziplinen erst am Ende eines Projekts zusammenführt, baut zweimal – wer sie von der Architekturphase an gemeinsam denkt, einmal richtig.
Fragen zu Software-Engineering von infoteam?
?
Ist ein System, das nach IEC 61508 zertifiziert ist, automatisch auch gegen Cyberangriffe geschützt?
Nein. IEC 61508 behandelt zufällige und systematische Fehler in der Technik selbst, nicht die gezielte Manipulation durch einen Angreifer. Ein SIL-3-zertifiziertes System kann trotzdem eine offene Angriffsfläche haben, wenn Cyber Security nicht separat adressiert wurde.
?
Reicht eine ISO-27001-Zertifizierung, um auch die Anforderungen von IEC 62443 zu erfüllen?
Nicht vollständig, aber sie ist eine gute Grundlage. ISO 27001 behandelt Informationssicherheit auf Organisationsebene, IEC 62443 adressiert zusätzlich produktspezifische, technische Anforderungen an industrielle Automatisierungssysteme. Wer ISO 27001 bereits erfüllt, hat für IEC 62443 einen deutlich geringeren Mehraufwand vor sich als bei einem Neustart.
?
Ab wann muss ich die Meldepflichten des Cyber Resilience Act erfüllen?
Seit dem 11. September 2026 müssen aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle gemeldet werden – gestaffelt als Frühwarnung binnen 24 Stunden, Vollmeldung binnen 72 Stunden und Abschlussbericht binnen 14 Tagen. Die vollständigen Produktanforderungen, inklusive Security by Design, gelten ab dem 11. Dezember 2027.
?
Betrifft das auch Bestandsanlagen, die schon seit Jahren im Feld sind?
Ja, bei der Meldepflicht des Cyber Resilience Act ausdrücklich. Sie gilt auch für Produkte, die vor Dezember 2027 in Verkehr gebracht wurden, und läuft weiter, selbst wenn der offizielle Support-Zeitraum des Produkts bereits beendet ist.
Zwei Disziplinen mit demselben Ziel, aber unterschiedlicher Blickrichtung
Funktionale Sicherheit und Cyber Security beantworten auf den ersten Blick eine ähnliche Frage – kann diesem System vertraut werden – aber aus entgegengesetzter Richtung. Safety fragt: Was passiert, wenn die Technik selbst versagt, durch einen zufälligen Bauteilfehler oder einen systematischen Entwicklungsfehler? Security fragt: Was passiert, wenn jemand von außen gezielt eingreift, um genau dieses Verhalten zu erzwingen? IEC 61508 wurde für die erste Frage entwickelt, IEC 62443 für die zweite. Beide Normenfamilien haben eigene Begriffswelten, eigene Risikobewertungsmethoden und eigene Zertifizierungswege – historisch entstanden, als vernetzte Steuerungen noch die Ausnahme waren.
Diese Trennung war so lange praktikabel, wie sicherheitskritische Systeme isoliert liefen. Sobald eine SPS Fernwartungszugänge bekommt, ein Leitsystem Daten in die Cloud spiegelt oder ein Medizingerät sich ins Krankenhausnetzwerk einbindet, verschiebt sich die Ausgangslage grundlegend: Ein Angreifer, der Zugriff auf die Steuerung erlangt, kann dieselben Zustände erzwingen, vor denen die funktionale Sicherheit eigentlich schützen soll. Die Frage ist dann nicht mehr, ob Safety oder Security wichtiger ist, sondern ob Security zur Vorbedingung für Safety geworden ist – denn ein manipuliertes System kann per Definition nicht mehr sicher im Sinne von IEC 61508 sein, unabhängig davon, wie sorgfältig die ursprüngliche SIL-Einstufung war.
Wie die Normenwelt die Lücke schließt
Die Normungsgremien haben auf diese Entwicklung reagiert, allerdings nicht mit einer vollständigen Verschmelzung, sondern mit Brückendokumenten. IEC TR 63069 erklärt, wie IEC 61508 und IEC 62443 gemeinsam angewendet werden können, und liefert ein Mapping zwischen den unterschiedlichen Begriffen, Konzepten und Bewertungsmethoden beider Normenfamilien. Für die Maschinensicherheit übernimmt IEC TR 63074 eine vergleichbare Rolle im Zusammenspiel mit ISO 13849. In der Bahntechnik verlangt TS 50701 explizit den Nachweis von Cyber Security für sicherheitsrelevante Leit- und Steuerungssysteme – parallel und im Zusammenspiel mit der funktionalen Sicherheit nach DIN DIN EN 50716. In der Medizintechnik übernimmt IEC 81001-5-1 eine ähnliche Funktion für vernetzte Software in Gesundheits-IT-Systemen.
Gemeinsam ist all diesen Dokumenten ein Grundprinzip: Sie ersetzen nicht die jeweils andere Disziplin, sondern verlangen, dass beide Risikoanalysen aufeinander Bezug nehmen. Eine Bedrohungsanalyse nach IEC 62443 muss die Frage beantworten, ob eine erfolgreiche Manipulation eine als sicher eingestufte Funktion kompromittieren kann. Umgekehrt muss eine Safety-Risikoanalyse berücksichtigen, dass ein Angreifer gezielt genau die Bedingungen herstellen kann, die eine zufällige Fehlerannahme eigentlich als unwahrscheinlich einstuft. Wer beide Analysen getrennt und nacheinander durchführt, übersieht typischerweise genau diese Wechselwirkung.
Der regulatorische Druck kommt von mehreren Seiten gleichzeitig
Was bisher vor allem gute Ingenieurspraxis war, wird zunehmend zur gesetzlichen Pflicht. Der Cyber Resilience Act verlangt seit dem 11. September 2026 die Meldung aktiv ausgenutzter Schwachstellen und schwerer Sicherheitsvorfälle – gestaffelt in eine Frühwarnung binnen 24 Stunden, eine Vollmeldung binnen 72 Stunden und einen Abschlussbericht binnen 14 Tagen. Die vollständigen Produktanforderungen inklusive Security by Design und Secure by Default gelten ab dem 11. Dezember 2027, für Produkte, die schon vorher in Verkehr gebracht wurden, allerdings nur bei einer wesentlichen Änderung. Die Meldepflichten dagegen gelten ausdrücklich auch für Bestandsprodukte, die schon länger im Feld sind. Parallel dazu wird Cyber Security ab Januar 2027 über die neue Maschinenverordnung fester Bestandteil der CE-Kennzeichnung für Industrieanlagen. NIS2 verpflichtet Betreiber kritischer Infrastruktur zusätzlich zu Risikomanagement, Meldepflichten und einer persönlichen Haftung der Geschäftsleitung bei Vernachlässigung.
Für Entwicklungsteams heißt das: Die Frage ist nicht mehr, ob Cyber Security parallel zur funktionalen Sicherheit dokumentiert werden muss, sondern nur noch, wie früh im Entwicklungsprozess diese Dokumentation ansetzt. Ein nachträglich aufgesetztes Security-Konzept lässt sich zwar noch für eine Meldepflicht nutzen, erfüllt aber kaum die Anforderung an Security by Design, die Architekturentscheidungen von Anfang an einschließt.
Was das für die tägliche Entwicklungsarbeit bedeutet
In der Praxis zeigt sich die Konvergenz beider Disziplinen an drei Stellen im Entwicklungsprozess. Erstens beim Threat Modeling: Eine Bedrohungsanalyse, die parallel zur Gefährdungsanalyse nach IEC 61508 entsteht, kann direkt prüfen, welche identifizierten Cyberbedrohungen eine bestehende Sicherheitsfunktion betreffen – statt zwei getrennte Dokumente nachträglich abzugleichen. Zweitens bei der Architektur: Netzwerksegmentierung, die eine sicherheitsrelevante Steuerung von der IT-Ebene trennt, ist gleichzeitig eine Security-Maßnahme nach IEC 62443 und eine Voraussetzung dafür, dass die Safety-Risikoanalyse ihre Grundannahmen zur Angriffswahrscheinlichkeit überhaupt aufrechterhalten kann. Drittens beim Lieferkettenmanagement: Eine Software Bill of Materials, die ohnehin für die CRA-Meldepflichten benötigt wird, liefert gleichzeitig die Grundlage, um im Fall einer neu entdeckten Schwachstelle in einer Drittkomponente schnell zu bewerten, ob eine sicherheitsrelevante Funktion betroffen ist.
Die sechs wichtigsten Punkte auf einen Blick
Unterschiedliche Blickrichtung
Safety schützt vor zufälligem Systemversagen, Security vor gezielter Manipulation – beide Disziplinen bleiben inhaltlich eigenständig.
IEC TR 63069 als Brücke
Liefert das Mapping zwischen IEC 61508 und IEC 62443, inklusive gemeinsamer Begriffswelt.
Gemeinsames Threat Modeling
Bedrohungs- und Gefährdungsanalyse gehören in denselben Prozess, nicht in zwei getrennte Dokumente.
CRA-Meldepflicht seit September 2026
Aktiv ausgenutzte Schwachstellen müssen binnen 24 Stunden erstgemeldet werden – auch bei Bestandsprodukten.
Volle CRA-Pflichten ab Dezember 2027
Security by Design wird verbindlich, nicht mehr optional dokumentiert.
Branchenspezifische Ergänzungen
TS 50701 für Bahntechnik, IEC TR 63074 für Maschinensicherheit, IEC 81001-5-1 für vernetzte Medizin-IT.
Praxisbeispiel: Fernwartung an einer sicherheitsrelevanten Anlagensteuerung
Ein Maschinenbauer rüstet eine bestehende Anlage mit einem Fernwartungszugang nach, damit Servicetechniker Störungen ohne Vor-Ort-Termin diagnostizieren können. Die Anlage verfügt über eine SIL-2-eingestufte Not-Halt-Funktion, entwickelt und zertifiziert nach IEC 61508 – zu einem Zeitpunkt, als das Steuerungsnetzwerk noch vollständig isoliert war.
Wird der Fernwartungszugang isoliert als IT-Projekt betrachtet, entsteht eine gefährliche Lücke: Die ursprüngliche Risikoanalyse ging von einem physisch abgeschotteten System aus und bewertete die Wahrscheinlichkeit einer gezielten Manipulation der Not-Halt-Logik entsprechend niedrig. Mit dem neuen Zugang ändert sich diese Grundannahme fundamental, ohne dass die Safety-Akte automatisch aktualisiert wird.
Der belastbarere Weg beginnt mit einer gemeinsamen Betrachtung: Eine Bedrohungsanalyse nach IEC 62443 identifiziert den Fernwartungszugang als neuen Angriffsvektor und bewertet, ob ein kompromittiertes Wartungskonto Zugriff auf die sicherheitsrelevante Logik erlangen könnte. Parallel dazu wird die bestehende SIL-2-Risikoanalyse um genau diese neue Bedrohung ergänzt, nicht als separates Dokument, sondern als aktualisierter Abschnitt der bestehenden Safety-Akte. Die Netzwerkarchitektur wird so segmentiert, dass der Fernwartungszugang ausschließlich auf die Diagnoseebene zugreifen kann, physisch getrennt von der sicherheitsrelevanten Steuerungslogik. Am Ende steht eine Anlage, die sowohl ihre ursprüngliche SIL-2-Einstufung als auch die neuen CRA-Meldepflichten erfüllt – weil beide Betrachtungen von Anfang an denselben Sachverhalt aus zwei Blickwinkeln beleuchtet haben, statt ihn zweimal getrennt zu bewerten.
Fazit – Funktionale Sicherheit und Cyber Security
Funktionale Sicherheit und Cyber Security lassen sich normativ nicht zu einer Disziplin verschmelzen – dafür sind ihre Grundfragen zu unterschiedlich. Aber sie lassen sich auch nicht mehr unabhängig voneinander entwickeln, sobald ein System vernetzt ist. IEC TR 63069 und vergleichbare Brückendokumente zeigen, wie beide Risikoanalysen aufeinander Bezug nehmen müssen, und der Cyber Resilience Act macht aus dieser guten Praxis seit September 2026 schrittweise eine gesetzliche Pflicht. Wer Threat Modeling und Gefährdungsanalyse von der Architekturphase an gemeinsam denkt, vermeidet nicht nur doppelte Dokumentation, sondern genau die Lücken, die entstehen, wenn eine ursprünglich isolierte Sicherheitsfunktion später vernetzt wird, ohne dass ihre Risikobewertung mitwächst.
Wie infoteam unterstützt
Wir entwickeln seit 1983 funktional sichere Software nach IEC 61508 und DIN EN 50716 und bringen Cyber-Security-Anforderungen nach IEC 62443, NIS2 und dem Cyber Resilience Act von der Architekturphase an in denselben Entwicklungsprozess ein – mit unserem TÜV iFSM-Prozess als gemeinsamem Rahmen. Wenn Sie prüfen möchten, wie sich Ihre bestehende Safety-Dokumentation auf die neuen CRA-Fristen vorbereiten lässt, sprechen Sie unverbindlich mit uns.
Hinweis: Die in diesem Artikel genannten Fristen des Cyber Resilience Act entsprechen dem Stand September 2026. Für eine rechtsverbindliche Einschätzung Ihres konkreten Produkts empfehlen wir die Abstimmung mit Ihrer Rechtsberatung und den zuständigen Konformitätsbewertungsstellen.
