Unterschied Safety und Security – Definitionen, Konflikte und warum beides zusammengehört

Zwei englische Begriffe, ein deutsches Wort, ein handfestes Problem: „Safety“ und „Security“ werden im Deutschen beide mit „Sicherheit“ übersetzt, dabei meinen sie grundlegend verschiedene Dinge. In der IT, im Maschinenbau und in der industriellen Produktion führt diese Verwechslung täglich zu Fehlannahmen, schlechten Entscheidungen und Systemen, die auf dem Papier sicher klingen, es aber nicht sind.
Dieser Artikel liefert klare Definitionen, zeigt anhand konkreter Szenarien, wo Safety und Security in Konflikt geraten und erklärt, wie beide Konzepte strategisch zusammengedacht werden müssen.

Was bedeutet Safety?

Schutz vor unbeabsichtigten Gefahren
Safety bezeichnet die Betriebssicherheit – also den Schutz von Menschen, Umwelt und Sachgütern vor Gefahren, die aus einem System selbst entstehen. Nicht durch Angriffe, nicht durch Böswilligkeit, sondern durch Fehlfunktionen, Fehlanwendungen, technische Defekte oder einfach durch menschliches Versagen.
Die Schutzrichtung ist klar definiert: Das System soll den Menschen nicht gefährden. Deswegen lautet die prägnante Formel:

„Safety schützt den Menschen vor der Maschine.“

In der Praxis bedeutet Safety: Not-Aus-Schalter, die jederzeit erreichbar sein müssen. Schutzgitter, die Maschinenteile von Personen trennen. Redundante Steuerungen, die bei einem Fehler in einen sicheren Zustand fallen. Brandschutzmaßnahmen. Druckventile, die bei Überlastung automatisch öffnen. All das sind typische Safety-Maßnahmen – ausgelegt auf Szenarien, die niemand absichtlich herbeiführt.

Ein zentrales Merkmal von Safety-Maßnahmen: Sie sind langfristig stabiler als Security-Maßnahmen. Eine mechanische Schutzvorrichtung oder ein Not-Aus-System bleibt einmal korrekt konstruiert über Jahre oder Jahrzehnte wirksam, solange sich die Betriebsbedingungen nicht wesentlich ändern. Für softwarebasierte Sicherheitsfunktionen (etwa SIL-zertifizierte Steuerungen) gilt: Auch dort ist ein Lifecycle-Management nötig, und Änderungen lösen Revalidierungspflichten aus – aber der Grundcharakter ist reaktiv-stabil, nicht kontinuierlich-dynamisch wie bei Security. Das macht Safety zu einer ingenieurwissenschaftlichen Disziplin mit klar definierten Normen – unter anderem IEC 61508 (funktionale Sicherheit), ISO 13849 (Sicherheit von Steuerungen) und EN ISO 12100 (Risikobeurteilung für Maschinen).

Safety ist außerdem gesetzlich verankert: Die Maschinenrichtlinie (und ihre Nachfolgerin, die Maschinenverordnung) macht Safety zu einer zwingenden Anforderung für jeden Hersteller, der Maschinen und Anlagen in der EU in den Verkehr bringt. Risikobeurteilung nach EN ISO 12100 ist Pflicht.

Safety vs. Security: Was ist der Unterschied?

Die folgende Tabelle fasst die wesentlichen Unterschiede kompakt zusammen:

Warum das Deutsche hier ein Problem ist: Im Englischen erzwingt die Sprache bereits eine Differenzierung. Im Deutschen reden Safety-Ingenieur und IT-Security-Spezialist buchstäblich aneinander vorbei – beide sprechen von „Sicherheit“, meinen aber völlig verschiedene Gefährdungen, Schadensarten und Gegenmaßnahmen. Diese Fehlannahme ist im industriellen Umfeld nicht nur lästig, sondern potenziell gefährlich.

Was ist eigentlich Privacy? Das dritte Konzept im Bunde

Wer Safety und Security klar unterscheiden kann, hat schon viel gewonnen. Vollständig ist das Bild aber erst mit einem dritten Begriff: Privacy.
Privacy bezeichnet den Schutz personenbezogener Daten und der Privatsphäre natürlicher Personen. Während Security ein System vor unbefugtem Zugriff absichert, schützt Privacy die Daten, die das System über Menschen verarbeitet. Beide Konzepte überschneiden sich, sind aber nicht identisch: Ein System kann technisch sicher sein (Security) und trotzdem datenschutzwidrig arbeiten. Zum Beispiel, wenn Kamerasysteme oder biometrische Zugangslösungen Daten erheben, die nicht hätten erhoben werden dürfen.

In der Praxis relevant wird Privacy überall, wo personenbezogene Daten im Spiel sind: Mitarbeiterdaten in Produktionssystemen, Patientendaten in medizintechnischen Geräten, Standortdaten von Fahrzeugen, biometrische Daten an Zugangskontrollen. Die rechtliche Grundlage ist die DSGVO und wer beim Entwurf eines Systems nur Safety und Security einplant, Privacy aber ignoriert, baut sich spätestens beim Rollout ein regulatorisches Problem ein.

Wo begegnen uns Safety und Security in der Praxis?

Der Unterschied zwischen Safety und Security ist kein akademisches Problem. Er tritt in konkreten Branchen täglich auf – mit sehr unterschiedlichen Gewichtungen:

• Industrie und OT (Operational Technology): In Produktionsumgebungen mit speicherprogrammierbaren Steuerungen (SPS), SCADA-Systemen und vernetzten Maschinen war Safety das dominante Thema, lange bevor IT-Security überhaupt eine Rolle spielte. Mit Industrie 4.0 ändert sich das: Maschinen und Anlagen werden vernetzt, kommunizieren mit übergeordneten IT-Systemen und werden damit erstmals auch zum Angriffsziel für Cyberangriffe.
• Medizintechnik: Hier gilt Safety als absolutes Muss. Ein Herzschrittmacher oder eine Infusionspumpe darf schlicht nicht versagen. Gleichzeitig wächst die Bedeutung von Security, seit medizinische Geräte zunehmend vernetzt sind und Patientendaten übertragen. Die Norm IEC 62304 adressiert die funktionale Sicherheit von Medizinsoftware; Security und Privacy kommen durch die EU-Medizinprodukteverordnung (MDR) und die DSGVO dazu.
• Automotive: Die ISO 26262 definiert die funktionale Sicherheit für Straßenfahrzeuge – Safety pur. Seit Fahrzeuge über Mobilfunk, WLAN und Bluetooth erreichbar sind, ist Security hinzugekommen: Die UNECE-Verordnung WP.29 und ISO/SAE 21434 machen Cybersecurity zur Pflicht für neue Fahrzeugtypen. Beides muss heute gemeinsam entwickelt werden.
• KRITIS – Kritische Infrastrukturen: In der Wasser-, Energie- und Gesundheitsversorgung ist die Verschmelzung von Safety und Security am deutlichsten spürbar. Ein Angriff auf eine Steuerungsanlage ist nicht nur ein IT-Incident; er kann physischen Schaden anrichten, Menschenleben gefährden und die Grundversorgung ganzer Bevölkerungsgruppen treffen.

Wo geraten Safety und Security in Konflikt?

Hier wird es praktisch und für viele Organisationen überraschend: Safety- und Security-Maßnahmen können sich aktiv widersprechen. Wer das nicht einplant, löst das Problem nicht ab, sondern verlangsamt es nur.

1. Notfallzugang vs. Zutrittskontrolle
   Der Brandschutz (Safety) fordert, dass Fluchtwege und Notausgänge jederzeit und ohne Hilfsmittel passierbar sind. Security will kontrollierte, protokollierte Zugänge und am besten ein Zutrittskontrollsystem, das unbefugte Personen draußen hält. Der Notausgang ist aus Safety-Sicht unverzichtbar – aus Security-Sicht eine potenzielle Schwachstelle.
2. Verfügbarkeit vs. Patch-Management
   Security erfordert regelmäßige Updates und Patches, um bekannte Schwachstellen zu schließen. Safety-kritische Systeme in der Produktionsumgebung dürfen jedoch oft nicht einfach neugestartet werden, ungeplante Ausfälle sind nicht tolerierbar, und jede Änderung an einem zertifizierten System kann eine erneute Validierung notwendig machen. Das Ergebnis: OT-Systeme laufen jahrelang mit ungepatchter Software, weil das Safety-Argument gegen Updates sticht.
3. Fernwartung vs. Netzwerktrennung
   Safety-Teams wollen bei Störungen schnellen Fernzugriff auf Anlagen – jede Minute Ausfallzeit kostet. Security-Teams wollen Netzwerke segmentieren und externe Verbindungen kontrollieren oder ganz verbieten. Beide Anforderungen sind legitim; ohne Koordination beißen sie sich.
4. Fail-Safe vs. Fail-Secure
   Das ist der tiefste konzeptuelle Konflikt: Safety-Systeme sind auf Fail-Safe ausgelegt. Im Fehlerfall öffnen Türen, schalten Maschinen ab, geben Wege frei. Security-Systeme sind auf Fail-Secure ausgelegt. Im Fehlerfall sperren Türen, isolieren Netzwerke, blockieren Zugriffe. Ein und dasselbe Ereignis, etwa ein Stromausfall oder ein Systemabsturz, führt in beiden Logiken zu entgegengesetzten Reaktionen.
   Diese Konflikte entstehen nicht aus Böswilligkeit, sondern weil Safety und Security historisch von verschiedenen Disziplinen entwickelt wurden: Safety von Maschinenbauern und Elektrotechnikern, Security von IT-Spezialisten. Beide haben ihre eigene Fachsprache, ihre eigenen Normen und ihre eigenen Fehlannahmen über die jeweils andere Seite.

Wann gefährdet Security die Safety – und umgekehrt?

Dass beide Konzepte sich beeinflussen, ist keine Theorie. Es gibt konkrete Szenarien, in denen das Fehlen des einen das andere direkt gefährdet.

Security-Angriff → Safety-Ausfall: Manipuliert ein Angreifer die Steuerungssoftware einer Produktionsmaschine, kann er Qualitätsmängel provozieren, die Safety-relevante Auswirkungen haben. Ein bekanntes Labordemonstrationsszenario aus der Automobilindustrie: Ein Schweißroboter wird so manipuliert, dass er minimale, aber sicherheitskritische Fehler in Karosserieverbindungen produziert und gleichzeitig werden die Qualitätssicherungssysteme (Safety) so beeinflusst, dass diese Schwachstellen nicht erkannt werden. Das Resultat wären strukturell fehlerhafte Fahrzeuge, die trotzdem die Produktion verlassen. Der Angriff war nur durch das Zusammenspiel aus IT-Security-Wissen und tiefem Produktionswissen möglich.

Das bekannteste reale Beispiel ist Stuxnet: Schadsoftware, die über einen Security-Angriff auf Siemens-SPS-Steuerungen die Drehgeschwindigkeit iranischer Uranzentrifugen manipulierte und dabei gleichzeitig gefälschte Sensordaten sendete, damit die Überwachungssysteme keine Anomalien anzeigten. Das Safety-System zur automatischen Notabschaltung wurde so effektiv außer Kraft gesetzt. Ergebnis: rund 1.000 zerstörte Zentrifugen, monatelang unbemerkt. Ein Security-Angriff mit direkter Safety-Wirkung.

Safety-Lücke → Security-Schwachstelle: Die Kehrseite: OT-Systeme, die aus Safety-Gründen nicht aktualisiert werden dürfen, häufen im Laufe der Zeit bekannte Sicherheitslücken an. Wer sich in ein Industrienetz einloggen möchte, sucht genau diese Stellen – Steuerungssysteme, die seit Jahren nicht gepatcht wurden und bekannte Schwachstellen aufweisen. Das Safety-Argument „Wir können nicht einfach Neustart drücken“ wird zum Security-Einfallstor.

Die Konsequenz ist eindeutig: Safety und Security bedingen einander. Wer Safety ohne Security plant, riskiert, dass ein Cyberangriff die sorgfältig konstruierten Schutzmaßnahmen aushebelt. Wer Security ohne Safety-Verständnis betreibt, riskiert, durch Sicherheitsmaßnahmen neue Gefährdungen zu schaffen.

Wie lassen sich Safety und Security gemeinsam denken?

Die Integration von Safety und Security ist keine optionale Verbesserung, sondern die Voraussetzung für jedes ernsthaft sichere System in vernetzten Umgebungen. Folgende Ansätze haben sich dabei als tragfähig erwiesen:
Gemeinsame Sprache als Fundament. Bevor Maßnahmen diskutiert werden können, muss das Vokabular geklärt sein.

Betriebssicherheit = Safety.
Informationssicherheit = Security.

Das klingt trivial, ist in der Praxis aber der häufigste Stolperstein. Abteilungen, die aneinander vorbeireden, können keine gemeinsamen Risikobeurteilungen erstellen.
Safety-Security-Co-Engineering. Fraunhofer IESE hat dieses Konzept formalisiert: Safety- und Security-Anforderungen werden nicht nacheinander, sondern von Anfang an gemeinsam erhoben und bewertet. Wechselwirkungen, etwa der Fail-Safe/Fail-Secure-Konflikt, lassen sich so bereits in der Entwicklungsphase erkennen und auflösen, statt im Betrieb zu eskalieren.

Gemeinsame Risikoanalyse. Safety nutzt FMEA (Failure Mode and Effects Analysis), Security nutzt TARA (Threat Analysis and Risk Assessment) – im industriellen OT-Kontext nach IEC 62443-3-2, im Automotive-Kontext verpflichtend nach ISO/SAE 21434. Eine integrierte Analyse, die beide Methoden kombiniert, liefert ein vollständigeres Bild aller relevanten Gefährdungen – zufällige wie absichtliche.

Normative Brücke IEC 62443. Diese Normenreihe für Industrial Security adressiert explizit das Zusammenspiel von Safety und Security in industriellen Automatisierungssystemen. Sie bietet einen strukturierten Rahmen, um beide Anforderungen in einem Managementsystem zu verankern.

Organisatorisch: „Zweisprachige“ Sicherheitsverantwortliche. Mittel- bis langfristig brauchen Organisationen Experten, die beide Welten kennen, die sowohl mit IEC 61508 als auch mit IEC 62443 vertraut sind, die sowohl mit dem Safety-Ingenieur als auch mit dem IT-Security-Analysten sprechen können. Diese „zweisprachigen“ Profile sind selten und entsprechend gefragt, aber die Herausbildung entsprechender Rollen ist eine der wichtigsten organisatorischen Aufgaben für Unternehmen, die Industrie 4.0 ernsthaft betreiben wollen.

Fazit: Unterschied Safety und Security – und warum die Trennung ein Auslaufmodell ist

Safety und Security sind weder Synonyme, noch sind es unabhängige Disziplinen. Safety schützt den Menschen vor unbeabsichtigten Gefahren aus Maschinen und Anlagen. Security schützt Systeme und Infrastrukturen vor absichtlichen Angriffen. Beide arbeiten mit unterschiedlichen Bedrohungsmodellen, unterschiedlichen Normen und unterschiedlichen Reaktionslogiken.

Wer beides verwechselt, trifft schlechte Entscheidungen. Wer beides isoliert betrachtet, baut Sicherheitskonzepte mit blinden Flecken. Wer beides gemeinsam denkt, koordiniert, mit klarer Sprache und integrierter Risikobeurteilung und schafft damit die einzige belastbare Grundlage für sichere, vernetzte Systeme.

Die Frage ist heute nicht mehr „Safety oder Security?“, sondern: „Wie weit ist unsere Organisation damit, beides zu integrieren?“