{"id":12965,"date":"2026-03-02T14:26:48","date_gmt":"2026-03-02T13:26:48","guid":{"rendered":"https:\/\/limessecurity.ninja\/?p=12965"},"modified":"2026-03-03T12:50:28","modified_gmt":"2026-03-03T11:50:28","slug":"statische-passwoerter-hardcoded-keys-und-schwache-kryptografie-ein-hartnaeckiges-muster-bei-ot-produkten","status":"publish","type":"post","link":"https:\/\/limessecurity.com\/de\/statische-passwoerter-hardcoded-keys-und-schwache-kryptografie-ein-hartnaeckiges-muster-bei-ot-produkten\/","title":{"rendered":"Statische Passw\u00f6rter, Hardcoded Keys, und schwache Kryptografie: Ein hartn\u00e4ckiges Muster bei OT-Produkten"},"content":{"rendered":"[vc_row type=“in_container“ full_screen_row_position=“middle“ column_margin=“default“ column_direction=“default“ column_direction_tablet=“default“ column_direction_phone=“default“ scene_position=“center“ text_color=“dark“ text_align=“left“ row_border_radius=“none“ row_border_radius_applies=“bg“ overflow=“visible“ overlay_strength=“0.3″ gradient_direction=“left_to_right“ shape_divider_position=“bottom“ bg_image_animation=“none“][vc_column column_padding=“no-extra-padding“ column_padding_tablet=“inherit“ column_padding_phone=“inherit“ column_padding_position=“all“ column_element_direction_desktop=“default“ column_element_spacing=“default“ desktop_text_alignment=“default“ tablet_text_alignment=“default“ phone_text_alignment=“default“ background_color_opacity=“1″ background_hover_color_opacity=“1″ column_backdrop_filter=“none“ column_shadow=“none“ column_border_radius=“none“ column_link_target=“_self“ column_position=“default“ gradient_direction=“left_to_right“ overlay_strength=“0.3″ width=“1\/1″ tablet_width_inherit=“default“ animation_type=“default“ bg_image_animation=“none“ border_type=“simple“ column_border_width=“none“ column_border_style=“solid“][vc_column_text css=““ text_direction=“default“]In unserem letzten Blogpost haben wir \u00fcber die entdeckte Sicherheitsl\u00fccke in Siemens Healthineers syngo.plaza<\/a> berichtet. Gespeicherte Passw\u00f6rter wurden nicht ordnungsgem\u00e4\u00df verschl\u00fcsselt, sodass Angreifer mit Zugriff auf die entsprechenden Daten, Klartext-Anmeldedaten wiederherstellen konnten. Siemens Healthineers hat die Schwachstelle mittlerweile mit einem Hotfix behoben.<\/p>\n

Diese spezifische Schwachstelle klingt in diesem Fall zwar relativ simpel, sie ist allerdings Teil eines viel gr\u00f6\u00dferen und seit langem bestehenden Musters in der OT und bei eingebetteten Produkten. Gemeint ist die Verwendung statischer Passw\u00f6rter, fest codierter kryptografischer Schl\u00fcssel und schwacher oder fehlerhafter kryptografischer Implementierungen. Dieser Blogbeitrag nutzt unsere Erkenntnisse als Ausgangspunkt, um dieses Muster, die Gr\u00fcnde daf\u00fcr und die Frage zu untersuchen, warum die regulatorischen Rahmenbedingungen (insbesondere in Europa) diese Praktiken zu einem ernstzunehmenden Haftungsthema machen.[\/vc_column_text][\/vc_column][\/vc_row][vc_row type=“in_container“ full_screen_row_position=“middle“ column_margin=“default“ column_direction=“default“ column_direction_tablet=“default“ column_direction_phone=“default“ scene_position=“center“ text_color=“dark“ text_align=“left“ row_border_radius=“none“ row_border_radius_applies=“bg“ overflow=“visible“ overlay_strength=“0.3″ gradient_direction=“left_to_right“ shape_divider_position=“bottom“ bg_image_animation=“none“][vc_column column_padding=“no-extra-padding“ column_padding_tablet=“inherit“ column_padding_phone=“inherit“ column_padding_position=“all“ column_element_direction_desktop=“default“ column_element_spacing=“default“ desktop_text_alignment=“default“ tablet_text_alignment=“default“ phone_text_alignment=“default“ background_color_opacity=“1″ background_hover_color_opacity=“1″ column_backdrop_filter=“none“ column_shadow=“none“ column_border_radius=“none“ column_link_target=“_self“ column_position=“default“ gradient_direction=“left_to_right“ overlay_strength=“0.3″ width=“1\/1″ tablet_width_inherit=“default“ animation_type=“default“ bg_image_animation=“none“ border_type=“simple“ column_border_width=“none“ column_border_style=“solid“][divider line_type=“No Line“ custom_height=“40px“][vc_column_text css=““ text_direction=“default“]\n

Das wiederkehrende Muster<\/strong><\/h2>\n

Statische Passw\u00f6rter, hardcoded Keys und unzureichende kryptografische Schutzma\u00dfnahmen sind seit mehr als zwei Jahrzehnten ein Dauerproblem bei OT-Produkten. Das Problem beschr\u00e4nkt sich nicht auf einen einzelnen Anbieter oder Sektor, sondern ist ein branchenweites Muster, das in historischen Designentscheidungen und den besonderen Einschr\u00e4nkungen dieser Umgebungen begr\u00fcndet ist.<\/p>\n

Stuxnet und das hardcoded Passwort, das eine Diskussion ausl\u00f6ste<\/h3>\n

Das vielleicht bekannteste fr\u00fche Beispiel stammt aus dem Jahr 2010: Siemens SIMATIC WinCC und PCS 7 verwendeten ein hardcoded Datenbankpasswort (CVE-2010-2772<\/a>). Der Stuxnet-Wurm nutzte unter anderem diese Schwachstelle aus, um Systeme in der iranischen Nuklearinfrastruktur zu kompromittieren. W\u00e4hrend Stuxnet ein au\u00dfergew\u00f6hnlich ausgekl\u00fcgelter Angriff war, handelte es sich bei dem hardcoded Passwort um eine ganz gew\u00f6hnliche Design-Abk\u00fcrzung, die bereits seit Jahren offen in Siemens-Benutzerforen<\/a> diskutiert wurde, bevor sie durch die Stuxnet-Angriffskampagne weltweit bekannt wurde.<\/p>\n

S7CommPlus: Der lange Weg von hardcoded Schl\u00fcsseln zu TLS<\/h3>\n

Ein lehrreicheres Beispiel ist die Entwicklung der kryptografischen Schutzma\u00dfnahmen in der Siemens S7-1200\/1500-SPS-Produktreihe und ihrem S7CommPlus-Kommunikationsprotokoll. Diese Geschichte, die sich \u00fcber ein Jahrzehnt Forschung erstreckt, veranschaulicht sowohl, wie diese Praktiken entstehen, als auch, wie schwierig es ist, sie zu l\u00f6sen.<\/p>\n

Als Siemens vor etwa einem Jahrzehnt mit TIA Portal v12<\/a> asymmetrische Kryptografie zum Schutz der SPS-Kommunikation und -Konfiguration einf\u00fchrte, war die dynamische Schl\u00fcsselverwaltung und -verteilung f\u00fcr die meisten industriellen Steuerungssysteme keine praktikable Option. Der operative Aufwand f\u00fcr Integratoren und Anlagenbetreiber wurde als zu hoch angesehen. Siemens entschied sich stattdessen f\u00fcr feste, hardcoded, kryptografische Schl\u00fcssel, die in jedes Ger\u00e4t derselben Produktfamilie eingebettet waren.<\/p>\n

Diese Designentscheidung war im Kontext verst\u00e4ndlich: Sie priorisierte einfache Bedienbarkeit und Abw\u00e4rtskompatibilit\u00e4t und setzte gleichzeitig h\u00f6here Ma\u00dfst\u00e4be als das v\u00f6llig ungesch\u00fctzte traditionelle S7Comm-Protokoll, das ihr vorausging. Das bedeutete aber auch, dass alle SPS desselben Modells den gleichen, privaten Schl\u00fcssel teilten.<\/p>\n

Im Jahr 2019 demonstrierten Forscher des Technion (Israel Institute of Technology) auf der Black Hat USA<\/a>, dass der S7CommPlus-Handshake nur die Ger\u00e4tefamilie authentifizierte, nicht aber einzelne Ger\u00e4te. Sie bauten eine gef\u00e4lschte Engineering-Workstation, die sich als TIA-Portal ausgeben und Befehle an S7-1500-SPSen senden konnte, darunter auch das Herunterladen gef\u00e4lschter Logik. Der Forscher Avishai Wool formulierte es so: \u201eAlle SPSen des selben Modells haben den selben Schl\u00fcssel, was bedeutet, dass man, wenn man einen knackt, alle geknackt hat.\u201c<\/p>\n

Im Jahr 2022 ging Clarotys Team82<\/a> noch einen Schritt weiter (CVE-2022-38465<\/a>, CVSS 9.3). Durch Ausnutzen einer zuvor entdeckten Schwachstelle bei der Remote-Codeausf\u00fchrung (CVE-2020-15782<\/a>), um native Codeausf\u00fchrung auf S7-SPSen zu erreichen, extrahierten sie den globalen fest codierten privaten Schl\u00fcssel direkt aus dem SPS-Speicher. Mit diesem Schl\u00fcssel konnten sie die gesamte, gesch\u00fctzte Kommunikation zwischen SPSen und Engineering-Workstations entschl\u00fcsseln, konfigurierte Passwort-Hashes wiederherstellen, Man-in-the-Middle-Angriffe durchf\u00fchren und einen vollst\u00e4ndig unabh\u00e4ngigen S7-Client implementieren, ohne TIA Portal \u00fcberhaupt zu ben\u00f6tigen.<\/p>\n

Siemens reagierte mit einer \u00dcberarbeitung der kryptografischen Architektur. TIA Portal v17 und entsprechende Firmware-Updates f\u00fchrten in der Folge modernste TLS-basierte Kommunikation und individuelle Passw\u00f6rter pro Ger\u00e4t<\/a> zum Schutz der Konfiguration ein. Dies war eine bedeutende und lobenswerte technische Leistung, zeigt aber auch, wie umfangreich die erforderlichen Abhilfema\u00dfnahmen sind, wenn sich grundlegende kryptografische Annahmen als fehlerhaft erweisen. Betreiber weltweit m\u00fcssen sowohl die Firmware als auch die Engineering-Software aktualisieren, Ger\u00e4tepassw\u00f6rter neu konfigurieren und Projekte migrieren \u2013 in gro\u00dfen Anlagen ein mehrj\u00e4hriger Aufwand.[\/vc_column_text][vc_column_text css=““ text_direction=“default“]\n

Schneider Electric: hardcoded Salts und Plaintext-Protokolle<\/span><\/span><\/h3>\n

Dieses grundlegende Problem betrifft wahrscheinlich eine gro\u00dfe Anzahl traditioneller OT-Ger\u00e4tehersteller. Im Jahr 2020 fanden Forscher beispielsweise einen hardcoded\u00a0kryptografischen Salt<\/a> in Schneider Electrics EcoStruxure Machine Expert (CVE-2020-28214<\/a>). Da f\u00fcr jede Installation derselbe Salt verwendet wurde, konnte ein Angreifer die Passw\u00f6rter f\u00fcr den Anwendungsschutz offline mit Brute-Force-Angriffen knacken, sobald das Hash-Schema bekannt war. Der hardcoded Wert wurde durch einfaches Disassemblieren der .NET-Bin\u00e4rdatei mit einem Standard-Decompiler gefunden.<\/p>\n

Im Jahr 2022 gab Forescout CVE-2022-46680<\/a> bekannt, welches das UMAS-Protokoll von Schneider Electric betrifft, das von den SPSen Modicon M340 und M580 verwendet wird. Das Protokoll \u00fcbertrug Passw\u00f6rter im Klartext, eine Designentscheidung, die etwa 30 Jahre zur\u00fcckliegt. Schneider Electric arbeitete eng mit Forescout an einer L\u00f6sung, was angesichts des Alters des Protokolls eine bemerkenswerte Leistung ist. Das Beispiel unterstreicht jedoch, wie sich alte Designentscheidungen \u00fcber Jahrzehnte hinweg in Produktionsumgebungen halten.<\/p>\n

OT:ICEFALL<\/span>,\u00a0<\/span>die systemische Sichtweise<\/span><\/span><\/h3>\n

Ebenfalls im Jahr 2022 ver\u00f6ffentlichte Forescout’s Vedere Labs die Studie OT:ICEFALL<\/a>, die 56 Schwachstellen in Produkten von 10 gro\u00dfen OT-Anbietern, darunter Siemens, Honeywell, Emerson, Omron und Yokogawa, aufdeckte. Mehr als ein Drittel der gemeldeten Schwachstellen (38 %) betraf die Kompromittierung von Anmeldedaten durch Speicherung im Klartext, fest codierte Anmeldedaten oder fehlerhafte kryptografische Implementierungen.<\/p>\n

Die wichtigste Beobachtung der Forscher war bemerkenswert: es handelte sich nicht um obskure Fehler, sondern um grundlegende Probleme auf Design-Ebene. Hardcoded Passw\u00f6rter, fehlende Authentifizierung, clientseitige Authentifizierungspr\u00fcfungen und fehlerhafte Kryptografieschemata waren wiederkehrende Muster bei allen Anbietern und Produktlinien. Am auff\u00e4lligsten war, dass 74 % der betroffenen Produktfamilien \u00fcber eine Form der Sicherheitszertifizierung verf\u00fcgten, wie die CISA bei der Ver\u00f6ffentlichung entsprechender Hinweise feststellte. Die gefundenen Probleme h\u00e4tten bei professionellen Sicherheitsbewertungen, einschlie\u00dflich technischer \u00dcberpr\u00fcfungen, relativ schnell entdeckt werden m\u00fcssen.[\/vc_column_text][divider line_type=“No Line“ custom_height=“40px“][vc_column_text css=““ text_direction=“default“]\n

Warum es immer wieder passiert: Die Beweggr\u00fcnde verstehen<\/h2>\n

Es w\u00e4re einfach, die Schuld f\u00fcr mangelhafte Sicherheitspraktiken einfach den Anbietern zu geben. Die Realit\u00e4t ist jedoch differenzierter. In der Vergangenheit haben mehrere Faktoren diese Designentscheidungen in OT-Umgebungen beeinflusst.<\/p>\n

Einfache Bedienung hat Vorrang.<\/span><\/b> OT-Systeme werden \u00fcblicherweise von Ingenieuren und Technikern bedient, nicht von IT- (Sicherheits-)Spezialisten. Komplexe Schl\u00fcsselverwaltung, Zertifikatsinfrastruktur und Passwortrichtlinien f\u00fchren zu Reibungsverlusten im Betrieb, die sich direkt auf die Systemverf\u00fcgbarkeit auswirken k\u00f6nnen. Wenn eine SPS w\u00e4hrend eines ungeplanten Ausfalls ausgetauscht werden muss, ist ein gemeinsam genutzter Schl\u00fcssel, der sofort funktioniert, eindeutig attraktiv. Wenn ein Au\u00dfendiensttechniker f\u00fcr die Fehlerdiagnose Fernzugriff ben\u00f6tigt, ist ein fest codiertes Service-Passwort aus betrieblicher Sicht praktisch.<\/span>\u00a0<\/span><\/p>\n

Lange Produktlebenszyklen f\u00fchren zu Tr\u00e4gheit.<\/span><\/b> OT-Produkte sind auf eine Betriebsdauer von 15-25 Jahren ausgelegt. Kryptografische Best Practices, die zum Zeitpunkt der Entwicklung als akzeptabel galten, k\u00f6nnen zum Zeitpunkt der Bereitstellung bereits veraltet und ein Jahrzehnt sp\u00e4ter eindeutig unzureichend sein. Die Nachr\u00fcstung geeigneter Kryptografie in bereits eingesetzten Produkten, insbesondere in eingebetteten Systemen mit begrenzten Rechenressourcen, ist eine erhebliche technische Herausforderung.<\/span><\/p>\n

Abw\u00e4rtskompatibilit\u00e4t beschr\u00e4nkt Optimierungspotenziale<\/b>.<\/span><\/b> Viele Protokolle und Produkte m\u00fcssen die Interoperabilit\u00e4t mit \u00e4lteren Ger\u00e4ten aufrechterhalten. Die Einf\u00fchrung einer geeigneten Authentifizierung oder Verschl\u00fcsselung bedeutet oft, dass die Kompatibilit\u00e4t mit der bestehenden installierten Basis nicht mehr gegeben ist, was zu einer schwierigen \u00dcbergangsphase f\u00fchrt, in der Alt und Neu nebeneinander existieren m\u00fcssen. Die Protokollkorrektur von Schneider Electric UMAS zeigt, dass dies m\u00f6glich ist und wie lange es dauern kann.<\/span><\/p>\n

Security<\/span><\/b>\u00a0hatte in der Vergangenheit keine Priorit\u00e4t<\/b>.<\/span><\/b> In der Geschichte industrieller Steuerungssysteme ging man lange davon aus, dass diese Systeme physisch von nicht vertrauensw\u00fcrdigen Netzwerken getrennt sein w\u00fcrden. Unter dieser Annahme machte es wirtschaftlich wenig Sinn, stark in die Sicherheit auf Produktebene zu investieren. Die Konvergenz von IT- und OT-Netzwerken in den letzten zwei Jahrzehnten hat diese Annahme vollst\u00e4ndig widerlegt – die Produktentwicklungszyklen in der OT verlaufen allerdings langsam.<\/span><\/p>\n

Keiner dieser Faktoren rechtfertigt allerdings die fortgesetzte Auslieferung von Produkten mit fest programmierten Anmeldedaten oder schwacher Kryptografie im Jahr 2026. Aber ihr Verst\u00e4ndnis hilft zu erkl\u00e4ren, warum das Problem so tief verwurzelt ist und warum regulatorischer Druck zunehmend als notwendig angesehen wird, um Ver\u00e4nderungen voranzutreiben.<\/span>[\/vc_column_text][divider line_type=“No Line“ custom_height=“40px“][vc_column_text css=““ text_direction=“default“]\n

Die regulatorische Abrechnung<\/span><\/span><\/h2>\n

F\u00fcr europ\u00e4ische Betreiber und Hersteller wird ein regulatorischer Rahmen geschaffen, der die Bewertung und Ahndung dieser Praktiken grundlegend ver\u00e4ndern wird.<\/p>\n

EU Cyber Resilience Act (CRA)<\/h3>\n

Der Cyber Resilience Act<\/a> (Regulation (EU) 2024\/2847) trat im Dezember 2024 in Kraft, wobei die Meldepflichten ab September 2026 gelten und die vollst\u00e4ndige Einhaltung bis Dezember 2027 erforderlich ist. Der CRA f\u00fchrt verbindliche Cybersicherheitsanforderungen f\u00fcr alle \u201eProdukte mit digitalen Elementen\u201d ein, die auf dem EU-Markt in Verkehr gebracht werden. Der Anwendungsbereich ist breit gefasst und umfasst Komponenten industrieller Steuerungssysteme, IoT-Ger\u00e4te, Netzwerkausr\u00fcstung und die meisten kommerziellen Softwareprodukte.<\/p>\n

Hersteller m\u00fcssen sicherstellen, dass ihre Produkte so konzipiert, entwickelt und hergestellt werden, dass sie ein angemessenes Ma\u00df an Cybersicherheit auf der Grundlage der Risiken gew\u00e4hrleisten. Neben anderen Anforderungen muss ein Produkt nach einer Risikobewertung auf den Markt gebracht werden, ohne bekannte ausnutzbare Schwachstellen, in einer standardm\u00e4\u00dfig sicheren Konfiguration, mit einer minimierten Angriffsfl\u00e4che sowie einem angemessenen Schutz der Vertraulichkeit und Integrit\u00e4t von gespeicherten und \u00fcbertragenen Daten. Dar\u00fcber hinaus m\u00fcssen Sicherheitsupdates w\u00e4hrend der festgelegten Support-Dauer kostenlos zur Verf\u00fcgung gestellt werden, um sicherzustellen, dass sp\u00e4ter identifizierte ausnutzbare Schwachstellen im Produkt bei Bedarf gepatcht werden k\u00f6nnen.<\/p>\n

Zwar wird die Verwendung schwacher oder fest codierter Standardpassw\u00f6rter nicht ausdr\u00fccklich verboten, doch angesichts der oben genannten Anforderungen wird es schwieriger sein, solche Designentscheidungen zu verteidigen. Das Hardcoding oder Nichtdurchsetzen einer \u00c4nderung von Standardpassw\u00f6rtern steht im Widerspruch zu \u201eSecure by Default\u201c und ist eine bekannte ausnutzbare Schwachstelle.<\/p>\n

Die Nichteinhaltung der wesentlichen Cybersicherheitsanforderungen in Anhang I wird mit Strafen von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes<\/a> geahndet, je nachdem, welcher Betrag h\u00f6her ist. Produkte, die die Konformit\u00e4tsbewertung nicht bestehen, verlieren vollst\u00e4ndig den Zugang zum EU-Markt. IoT-Ger\u00e4te, die mit hardcoded oder nicht \u00e4nderbaren Standardpassw\u00f6rtern ausgeliefert werden, werden ausdr\u00fccklich als Beispiele genannt, die die h\u00f6chsten Strafen nach sich ziehen w\u00fcrden.<\/p>\n

F\u00fcr Hersteller von OT-Produkten sind die Auswirkungen erheblich. Produkte, die mit hardcoded Anmeldedaten, schwacher Passwortverschl\u00fcsselung oder gemeinsam genutzten kryptografischen Schl\u00fcsseln ausgeliefert werden, werden nicht nur von Security-Forschern, sondern auch von Markt\u00fcberwachungsbeh\u00f6rden mit Durchsetzungsbefugnissen genau unter die Lupe genommen. Die \u00c4ra, in der \u201einsecure by Design\u201c als akzeptabler Kompromiss galten, geht zumindest f\u00fcr den europ\u00e4ischen Markt zu Ende.<\/p>\n

IEC 62443<\/h3>\n

Die Normenreihe IEC 62443<\/a> ist seit Langem der Referenzrahmen f\u00fcr industrielle Cybersicherheit. Teil 4-1 definiert Anforderungen an einen sicheren Produktentwicklungslebenszyklus, und Teil 4-2 legt technische Sicherheitsanforderungen f\u00fcr einzelne Komponenten fest, darunter explizite Anforderungen in Bezug auf die Verwaltung von Anmeldedaten, die kryptografische Implementierung und Authentifizierungsmechanismen. Die IEC hat die IEC 62443 als \u201ehorizontale\u201d Normen<\/a> genehmigt, was bedeutet, dass sie als Grundlage f\u00fcr die Entwicklung sektorspezifischer OT-Sicherheitsnormen dienen.<\/p>\n

Obwohl die IEC 62443-Zertifizierung bereits seit Jahren verf\u00fcgbar ist, hat die OT:ICEFALL-Studie eine unangenehme Wahrheit ans Licht gebracht: 74 % der betroffenen Produktfamilien verf\u00fcgten \u00fcber eine Form der Sicherheitszertifizierung. Dies deutet darauf hin, dass sich die Zertifizierungsprozesse manchmal eher auf die Einhaltung von Verfahren und Funktionstests als auf strenge Sicherheitsbewertungen konzentriert haben.<\/p>\n

Standardisierungsgremien arbeiten derzeit an mehreren Normen, um Herstellern von Produkten mit digitalen Elementen klare Anforderungen f\u00fcr die Einhaltung des CRA an die Hand zu geben. In Normen des Typs B werden allgemeine Grunds\u00e4tze und Sicherheitsanforderungen f\u00fcr Produkte definiert. In speziellen Normen des Typs C werden vertikale Standards f\u00fcr bestimmte Produktgruppen definiert. Die meisten dieser Normen befinden sich jedoch noch in der Entwurfsphase, wobei die Ver\u00f6ffentlichungstermine auf das dritte Quartal 2026 sowie das vierte Quartal 2027 festgelegt sind. Das Warten auf diese Normen ist riskant, da sie sich noch \u00e4ndern k\u00f6nnen und am Ende m\u00f6glicherweise nicht als harmonisierte Norm deklariert werden.<\/p>\n

Eine bereits bestehende harmonisierte Normenreihe ist EN 18031-1\/2\/3 f\u00fcr die in der Funkanlagenrichtlinie festgelegten Sicherheitsanforderungen. In Bezug auf Geheimnisse und kryptografische Algorithmen legt sie fest, dass Algorithmen auf dem neuesten Stand der Technik verwendet werden m\u00fcssen und dass die werkseitigen Standardeinstellungen entweder f\u00fcr jedes Ger\u00e4t einzigartig sein m\u00fcssen oder bei der ersten Verwendung ge\u00e4ndert werden m\u00fcssen.<\/p>\n

Die IEC 62443-Reihe kann in ihrer derzeitigen Form zwar keine harmonisierte Norm werden, ist jedoch eine bestehende, vereinbarte Norm, die in der Branche h\u00e4ufig verwendet wird. Sie deckt einen Gro\u00dfteil der in der CRA festgelegten Anforderungen ab. Daher bereiten alle Bem\u00fchungen zur Einf\u00fchrung und Einhaltung der IEC 62443-4-1 f\u00fcr organisatorische Aspekte sowie der IEC 62443-4-2 f\u00fcr technische Anforderungen an Komponenten oder der IEC 62443-3-3 f\u00fcr technische Anforderungen an Systeme das Produkt optimal auf die Einhaltung der kommenden Vorschriften vor.[\/vc_column_text][divider line_type=“No Line“ custom_height=“40px“][vc_column_text css=““ text_direction=“default“]\n

Empfehlungen f\u00fcr Betreiber und Hersteller<\/h2>\n

F\u00fcr Betreiber betroffener Systeme<\/h3>\n