Sichere HMI-Panels im OEM-Design: Was Hardware leisten kann – und was nicht

Bei kundenspezifischen HMI-Baugruppen betrifft diese Entscheidung Display, Touchsensor, Overlay, Leiterplatte, Lichtleiter, Steckverbinder und den Übergang zum Gehäuse. Die Baugruppe ist eine Schutzschicht. Sie ist nicht das vollständige Security-System.

Sichere HMI-Panels auf einen Blick: Welche Hardwareentscheidung wirkt wo?

Die stärkste Hardwaremaßnahme ist meist nicht ein komplexeres Schloss, sondern das Weglassen eines unnötigen Zugangs. Wo Servicezugänge erforderlich bleiben, müssen Lage, Werkzeugbedarf, elektrische Freigabe und Verantwortlichkeit zusammenpassen.

Die Sicherheitsgrenze verläuft zwischen physischem Zugang und Systemvertrauen

HMI-Hardware kontrolliert vor allem Erreichbarkeit, Sichtbarkeit und mechanische Zugangswege. Systemvertrauen entsteht dagegen durch Identitäten, Schlüssel, Bootkette, Firmware, Kommunikationsprotokolle, Netzwerkzonen, Protokollierung und Betreiberprozesse. Wer diese Ebenen in einer Beschaffungsanforderung vermischt, erhält entweder unnötig teure Mechanik oder eine scheinbar robuste Front mit offenem Systempfad.

Ein HMI-Panel ist die physische und elektrische Benutzerschnittstelle einer Maschine. Der grundlegende Hardwareaufbau eines HMI-Panels kann aus Frontscheibe oder Folienoverlay, Touchsensor, Display, Tasten- oder Anzeigeschaltung, Träger, Dichtung und Verbindung zur Recheneinheit bestehen. Ein Panel-PC ergänzt Prozessor, Speicher, Boot-Firmware und Betriebssystem. Diese Unterscheidung verschiebt die Security-Verantwortung erheblich.

„Safety HMI“ und „Cybersecurity“ sind ebenfalls nicht synonym. Ein Not-Halt, Zustimmtaster oder eine SIL-/PL-bezogene Anzeige gehört zur funktionalen Sicherheit und braucht die dafür festgelegte Architektur und Bewertung. Eine robuste oder funktional sichere Taste sagt allein nichts über Debugzugang, Updateauthentizität oder Netzwerksegmentierung aus.

Physische Ports: Weglassen ist stärker als Abdecken

Ein nicht vorhandener Port kann weder versehentlich noch absichtlich benutzt werden. Für nicht benötigte USB-, Ethernet-, serielle oder Speicherschnittstellen ist das Weglassen deshalb die bevorzugte Hardwareentscheidung. NIST SP 800-53 Rev. 5, Control SC-41 nennt physisches oder logisches Deaktivieren beziehungsweise Entfernen von Ports und I/O-Geräten und bewertet die physische Maßnahme als stärker.

Das bedeutet nicht, dass jeder Serviceanschluss entfallen muss. Entwicklung, End-of-Line-Prüfung, Felddiagnose und Wiederherstellung können einen Zugang erfordern. Dann braucht die Zeichnung eine definierte Zugriffsklasse:

Eine Gummi- oder Kunststoffkappe schützt primär vor Umgebungseinfluss und versehentlichem Kontakt. Sie ist kein Berechtigungsmechanismus. Auch ein versenkter Port verhindert nicht, dass ein passender Adapter angeschlossen wird. Der RFQ-Nachweis muss deshalb aus einer Zeichnung mit Portlage, Abdeckungsart, Werkzeug, Montagefolge und elektrischem Status bestehen – nicht aus dem Satz „USB geschützt“.

Debugzugänge müssen zum Produktlebenszyklus passen

JTAG, SWD, UART-Bootloader und proprietäre Testpads sind keine gewöhnlichen Bedienerschnittstellen. Sie dienen Bring-up, Programmierung, Endprüfung, Fehleranalyse und gegebenenfalls Depot-Reparatur. Genau deshalb reicht es nicht, den Standardstecker nach der Entwicklung zu entfernen: Offene Pads, Bootstraps oder ein intern zugänglicher Connector können weiterhin einen Debug- oder Programmierpfad bilden.

Die Hardwarezeichnung muss vier Zustände unterscheiden: Entwicklungsmuster, Produktionsprogrammierung, Serienauslieferung und autorisierte Rückläuferanalyse. Für jeden Zustand werden erreichbare Signale, Adapter, Gehäusezugang, elektrische Freigabe und Eigentümer der Credentials festgelegt. Das vermeidet zwei gegensätzliche Fehler. Ein dauerhaft offener Debugzugang schwächt das Seriengerät. Ein irreversibel geschlossener Zugang kann dagegen Diagnose, Recovery oder Fehleranalyse verhindern.

Moderne Controller können differenziertere Zustände anbieten. Die NXP Application Note AN13037 für LPC55Sxx dokumentiert beispielsweise fest aktivierten, fest deaktivierten oder authentifizierten Debugzugang. Der Debugger erhält bei der Authentifizierungsvariante nur mit passenden Credentials Zugriff; die Dokumentation warnt zugleich vor nicht rückgängig zu machender Fehlkonfiguration. Das ist ein konkretes Bauteilbeispiel, keine universelle MCU-Eigenschaft.

Für die HMI-Baugruppe folgen daraus klare Fertigungsfragen:

• Bleiben Debugpads nach der Montage erreichbar, ohne eine sicherheitsrelevante Versiegelung zu brechen?
• Sind Testpunkte beschriftet, in der Serienvariante unbestückt oder unter einem Shield beziehungsweise Vergussbereich angeordnet?
• Trennt der Produktionsadapter Debug, Stromversorgung und Recovery so, dass keine unbeabsichtigten Bootzustände entstehen?
• Wird der Auslieferungszustand durch einen auslesbaren Konfigurationsnachweis geprüft, nicht nur durch Sichtkontrolle?
• Ist die Rückläuferstrategie vor einer irreversiblen Sperre freigegeben?

Die Fertigung kann Pads positionieren, Stecker bestücken oder weglassen und programmierte Zustände nach einer freigegebenen Prüfanweisung verifizieren. Schlüsselgenerierung, Credential-Verwahrung, Debug-Autorisierung und MCU-Security-Policy bleiben beim Produktverantwortlichen.

Wechselmedien bleiben ein Prozessrisiko – auch hinter einer Abdeckung

Ein SD-Kartenschacht oder USB-Port ist nur die physische Hälfte des Medienpfads. Die andere Hälfte umfasst Herkunft des Mediums, Dateiformat, Signatur- und Versionsprüfung, Schreibrechte, Protokollierung, Malware-Prüfung, Transport, Lagerung und Entsorgung. Eine verriegelte Klappe reduziert spontane Nutzung, ersetzt diese Regeln aber nicht.

NIST SP 800-82 Rev. 3 zählt SD-Karten und USB-Speicher ausdrücklich zu den Wechselmedien in OT-Umgebungen und fordert geregelte Nutzung sowie Schutz bei Handhabung, Lagerung, Transport und Bereinigung. Für ein OEM-Design sind daher drei Fragen getrennt zu beantworten:

1. Muss das Seriengerät überhaupt Medien lesen oder schreiben? Wenn nein, entfallen Slot und Hostfunktion.
2. Wer darf das Medium physisch einführen? Das bestimmt Portlage, Abdeckung und Zugangsprozess.
3. Was akzeptiert das Gerät logisch? Dateityp, Signatur, Version, Rollback-Regel und Fehlerreaktion liegen in Firmware und Systemtest.

Ein nur lesbarer mechanischer Adapter ist nicht automatisch ein kryptografisch vertrauenswürdiger Updatepfad. Umgekehrt kann ein signiertes Update über einen offen sichtbaren Port zwar authentisch geprüft werden, doch der Port bleibt für Fehlbedienung, mechanische Belastung oder unerwünschte Geräte relevant. Beide Ebenen müssen zusammen validiert werden.

Manipulationsschutz braucht drei getrennte Begriffe

Mechanische Barriere, Manipulationsnachweis und Manipulationserkennung lösen verschiedene Aufgaben. Eine Sicherheitsschraube erschwert das Öffnen. Ein Siegel kann eine Öffnung später sichtbar machen. Ein Gehäusekontakt kann ein Ereignis melden. Keine dieser Maßnahmen beweist für sich, dass Firmware, Schlüssel oder angezeigte Prozessdaten unverändert sind.

NIST SP 800-53 Rev. 5, PE-3 trennt abschließbare Gehäuse von Manipulationsschutz und nennt bei Letzterem sowohl Erkennen als auch Verhindern sowie Siegel und Beschichtungen als mögliche Technologien. Für ein HMI-Design ist diese Trennung unmittelbar zeichnungsrelevant:

IP- und IK-Angaben dürfen hier nicht als Cybersecurity-Kürzel missbraucht werden. IEC 60529 klassifiziert den Gehäuseschutz mit dem IP-Code; IEC 62262 behandelt äußere mechanische Einwirkungen mit dem IK-Code. Beide Nachweise können für ein robustes Panel wichtig sein. Sie bestätigen aber weder Zugriffskontrolle noch Authentizität, Updateintegrität oder Manipulationserkennung.

Vertrauenswürdige Anzeigen brauchen einen geschützten Signalweg

Eine Statusanzeige ist nur so vertrauenswürdig wie die Kette von der Zustandsquelle bis zum sichtbaren Signal. Wird ein grünes Symbol vom gleichen Betriebssystem, Grafikstack und Displaycontroller erzeugt wie jede andere Bildschirmgrafik, kann die Frontscheibe allein nicht belegen, dass das Symbol einen unverfälschten Sicherheitszustand zeigt.

NIST beschreibt in SP 800-53 Rev. 5, SC-11 einen Trusted Path als physisch oder logisch isolierten Kommunikationspfad zwischen Nutzer und vertrauenswürdiger Systemkomponente. Ein solcher Pfad soll von nicht vertrauenswürdiger Software nicht imitierbar sein. Daraus folgt als Engineering-Inferenz für HMI-Hardware: Eine dedizierte LED oder ein separates Anzeigefeld kann einen besser unterscheidbaren Pfad schaffen, wenn es direkt von einer vertrauenswürdigen Quelle angesteuert wird und der gemeinsame Fehleranteil beherrscht ist. Die LED allein erfüllt das Prinzip nicht.

Ein brauchbares Anforderungsblatt benennt deshalb:

• die vertrauenswürdige Zustandsquelle, etwa einen getrennten Controllerausgang;
• Leitung, Treiber, Versorgung und Default-Zustand bei Unterbrechung;
• optische Trennung vom Hauptdisplay durch Position, Farbe, Beschriftung oder Lichtleiter;
• Fehlerreaktion bei Kurzschluss, Leitungsbruch, Spannungsverlust und Kommunikationsausfall;
• Testmethode, mit der eine manipulierte Hauptanzeige den separaten Indikator nicht imitieren kann.

Architektur-Stack und Handoff

BEDIENER / SERVICEPERSONAL
        │ sieht, berührt, öffnet
        ▼
┌─────────────────────────────────────────────┐
│ Frontfläche: Overlay, Glas, Touch, Tasten, │  ← HMI-Fertigung
│ Lichtleiter, Portabdeckung, Siegelzone      │
├──────────── physische Vertrauensgrenze ─────┤
│ Interne Baugruppe: PCB, Stecker, Kabel,     │  ← HMI- und Elektronikdesign
│ Testpads, Gehäusekontakt, separate LED      │
├──────────── elektrische Übergabe ───────────┤
│ Trusted Component / MCU / Boot-Firmware     │  ← Firmware-/Product Security
│ Debugstatus, Schlüssel, Secure Boot, Update │
├──────────── Systemgrenze ───────────────────┤
│ PLC/SCADA, Netzwerkzonen, Identitäten, Logs │  ← Systemintegrator / Betreiber
└─────────────────────────────────────────────┘

Der Stack verhindert Verantwortungsnebel. Eine Öffnungsschleife ist erst dann Security-relevant, wenn eine vertrauenswürdige Komponente ihren Zustand auswertet, protokolliert und eine definierte Reaktion auslöst. Ebenso bleibt eine separate LED nur ein optisches Bauteil, solange Quelle, Treiber und Fehlerverhalten nicht spezifiziert sind.

IEC 62443 und CRA bewerten mehr als die Frontpanel-Baugruppe

IEC 62443 ist für industrielle Automatisierungs- und Steuerungssysteme relevant, aber eine Frontpanel-Zeichnung erhält dadurch nicht automatisch ein Security Level. IEC 62443-4-2:2019 beschreibt technische Anforderungen für IACS-Komponenten entlang von sieben grundlegenden Bereichen: Identifikation und Authentisierung, Nutzungskontrolle, Systemintegrität, Datenvertraulichkeit, eingeschränkter Datenfluss, rechtzeitige Reaktion auf Ereignisse und Ressourcenverfügbarkeit. Viele davon benötigen Firmware und Systemkontext.

IEC 62443-4-1:2018 adressiert den sicheren Produktentwicklungslebenszyklus einschließlich Anforderungsdefinition, sicherem Design, Implementierung, Verifikation, Fehler- und Patchmanagement sowie Produktlebensende. Das betrifft Hardware, Software und Firmware. Ein Lieferant einer mechanisch-elektrischen Baugruppe kann definierte Designmerkmale und Prüfungen beitragen, aber nicht ohne Auftrag und Nachweis die gesamte Produktentwicklung oder Systemintegration vertreten. Die Rollen und ergänzenden Nachweise gehören in eine projektspezifische Betrachtung der industriellen HMI-Normen und Hardware-Konformität.

Auch der Cyber Resilience Act ist breiter als die Frontblende. Die Verordnung (EU) 2024/2847 erfasst grundsätzlich Produkte mit digitalen Elementen, deren vorgesehene oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung einschließt. Sie verbindet Produktanforderungen mit Design, Entwicklung, Produktion und Schwachstellenbehandlung. Die konkrete Einordnung, Ausnahmen und Konformität verantwortet der Inverkehrbringer mit der vollständigen Produktarchitektur; diese Seite ersetzt keine Rechts- oder Konformitätsbewertung.

Eine Validierungsmatrix macht Sicherheitsannahmen prüfbar

„Port geschützt“ oder „tamper-proof“ sind keine Akzeptanzkriterien. Eine belastbare Freigabe benennt Testobjekt, Ausgangszustand, Werkzeug, elektrische Bedingung, erwartetes Ergebnis und zuständige Stelle. Die Prüf- und Validierungsplanung sollte Sicherheitsmerkmale gemeinsam mit Umwelt-, Montage- und Funktionsanforderungen erfassen, ohne die Nachweisarten zu vermischen.

Frühe Muster sollten nicht nur die Optik zeigen. Im Prototyping und bei der Musterfreigabe müssen Serviceadapter, Portabdeckungen, Siegelzonen, Lichtleiter, Kontaktwege und Montagefolge in der vorgesehenen Gehäusesituation geprüft werden. Eine HMI-Panel-Konstruktionscheckliste mit Freigabekriterien hilft, Security-Merkmale zusammen mit Toleranzen, Dichtung, Bedienbarkeit und Reparaturstrategie einzufrieren.

Hardwarezentrierte Maßnahmen reichen nicht in jedem Einsatzfall

Ein Frontpanel-Konzept ist ungeeignet als alleinige Security-Maßnahme, wenn das Gerät öffentlich oder unbeaufsichtigt zugänglich ist, Schlüssel oder vertrauliche Daten im Panel-PC verarbeitet, Fernadministration zulässt, Updates über Wechselmedien annimmt oder sicherheitskritische Zustände ausschließlich auf dem Hauptdisplay zeigt. In diesen Fällen braucht das Projekt zusätzlich eine systemische Bedrohungsanalyse, abgesicherte Boot- und Updatekette, Identitäts- und Rechtekonzept, Netzwerkarchitektur, Ereignisprotokollierung und Reaktionsplan.

NIST SP 800-193 strukturiert Firmware-Resilienz über Schutz, Erkennung und Wiederherstellung. Eine Metallabdeckung kann keinen dieser drei Mechanismen allein implementieren. Sie kann lediglich den physischen Zugang zu der Plattform begrenzen, auf der sie umgesetzt werden.

Projekt- und RFQ-Checkliste für sichere HMI-Panels

Vor einer Designprüfung sollten folgende Eingaben vorliegen:

• Displaygröße, aktiver Sichtbereich, Touchtechnologie und Frontaufbau;
• Frontplatten- und Gehäusezeichnung einschließlich Ausschnitt, Befestigung und Dichtung;
• vollständiger Interface-Stack mit USB, Ethernet, seriellen Ports, SD, Debug und Testpunkten;
• Zugriffsklasse jedes Ports in Entwicklung, Produktion, Serie und Rückläuferanalyse;
• gewünschte Tamper-Funktion: erschweren, sichtbar machen, elektrisch erkennen oder kombinieren;
• Quelle, Treiber, Versorgung und Fehlerzustand jedes kritischen Indikators;
• Umgebung, Reinigungsmedien, Temperatur, Feuchte, Stoß-/Vibrations- und IP-/IK-Ziel, soweit anwendbar;
• Akzeptanzkriterien, Prüfmusterzahl und Eigentümer für Firmware-/Systemnachweise;
• erwartetes Jahresvolumen, Varianten, Servicekonzept und Ersatzteilstrategie.

OEM-Teams können ihre Zeichnungen zur technischen Prüfung senden, damit mechanischer Aufbau, Schnittstellenlage, Fertigbarkeit und Validierungsübergaben gemeinsam geprüft werden.

Häufige Fragen zu sicheren HMI-Panels

Kann die Frontpanel-Hardware ein HMI cybersecure machen?

Nein. Die Frontpanel-Hardware kann Ports entfernen oder verlagern, Gehäusezugang erschweren, Manipulationsspuren unterstützen und getrennte Anzeige- oder Sensorsignalwege bereitstellen. Authentisierung, Secure Boot, signierte Updates, Netzwerksegmentierung und Ereignisreaktion entstehen erst in Elektronik, Firmware, Systemintegration und Betrieb. Die Hardware ist eine Schicht des Sicherheitskonzepts, nicht dessen Abschluss.

Bedeutet IP65 oder IP67, dass ein HMI gegen Manipulation geschützt ist?

Nein. IP-Codes nach IEC 60529 beschreiben den Gehäuseschutz gegen Berührung, Fremdkörper und Wasser innerhalb des Norm-Scope. Sie bewerten keine Benutzerrechte, Firmware-Integrität, Portfreigabe oder Manipulationsspuren. Ein abgedichtetes Panel kann für seine Umgebung geeignet und zugleich über interne Service- oder Debugpfade angreifbar sein.

Soll ein USB-Port am Serien-HMI vollständig entfernt werden?

Wenn keine Bedien-, Service- oder Recovery-Funktion den Port benötigt, ist Entfernen die stärkste Hardwareoption. Bleibt USB erforderlich, sollten Lage, Abdeckung, Zugriffsklasse, elektrischer Zustand und zulässige Geräte dokumentiert werden. Die Firmware muss zusätzlich festlegen, welche Funktionen, Dateien oder Updates akzeptiert werden; eine Portkappe ersetzt diese Kontrolle nicht.

Reicht es, JTAG- oder SWD-Stecker in der Serie nicht zu bestücken?

Nein. Unbestückte Pads können nach dem Öffnen des Gehäuses weiterhin elektrisch erreichbar sein. Die Serienfreigabe muss sowohl Layout und Zugänglichkeit als auch den programmierten Debugzustand des konkreten Controllers prüfen. Falls authentifizierter Debugzugang vorgesehen ist, gehören Credential-Verwaltung, Rückläuferanalyse und Recovery in das Produktlebenszykluskonzept.

Was ist der Unterschied zwischen Tamper Evidence und Tamper Prevention?

Tamper Prevention soll Manipulation verhindern oder erschweren, etwa durch Verriegelung oder geschützte Befestigung. Tamper Evidence soll eine erfolgte Öffnung erkennbar machen, etwa mit einem kontrollierten Siegel. Tamper Detection erzeugt ein elektrisches Ereignis. Alle drei brauchen eigene Akzeptanzkriterien; ein Siegel allein verhindert weder Zugriff noch Firmwareänderung.

Wann ist ein Statusindikator am HMI vertrauenswürdig?

Ein Statusindikator ist vertrauenswürdig, wenn sein kompletter Pfad von einer vertrauenswürdigen Zustandsquelle bis zur Anzeige definiert, gegen Imitation abgegrenzt und auf Fehler geprüft ist. Eine separate LED kann dabei helfen. Wird sie jedoch vom gleichen kompromittierbaren Grafik- oder Applikationspfad gesteuert, liefert ihre physische Trennung allein keinen Vertrauensnachweis.

Wo lassen sich sichere HMI-Panels online bestellen oder günstig beschaffen?

Sichere HMI-Panels sollten nicht allein nach Shoppreis oder einer pauschalen „secure“-Kennzeichnung bestellt werden. Für OEM-Projekte sind Zeichnung, Port- und Debugmatrix, Gehäusezugang, Indikatorpfad, Umgebungsbedingungen und Validierungsnachweise entscheidend. Ein günstiges Standardpanel kann passen, wenn diese Anforderungen erfüllt und die verbleibenden Systemkontrollen nachweislich umgesetzt werden.

Welche Prüfungen gehören in die Freigabe eines security-orientierten HMI-Designs?

Mindestens erforderlich sind Zeichnungs- und Stücklistenprüfung, Zugangsversuche an Ports und Abdeckungen, Verifikation des Serien-Debugzustands, Medien-Negativtests, Prüfung von Siegel oder Gehäusekontakt sowie Fehlerfälle des separaten Indikators. IP-/IK- und Umweltprüfungen bleiben separate Nachweise und dürfen nicht als Cybersecurity-Test umetikettiert werden.

Technische Übergabe

Für eine belastbare Prüfung werden Displaygröße, Frontplattenzeichnung, Interface-Stack, Einsatzumgebung und Jahresvolumen benötigt. Auf dieser Basis lassen sich Portlage, Abdeckung, Testpunkte, Tamper-Merkmale, Anzeigewege und Prüfgrenzen fertigungsgerecht abstimmen. Anschließend kann das OEM-Team ein technisches Angebot anfragen.

Quellen

1. International Electrotechnical Commission: IEC 62443-4-2:2019 — technische Security-Anforderungen für IACS-Komponenten, Ausgabe 1.0, 27. Februar 2019.
2. International Electrotechnical Commission: IEC 62443-4-1:2018 — Secure Product Development Lifecycle, Ausgabe 1.0, 15. Januar 2018.
3. National Institute of Standards and Technology: NIST SP 800-53 Rev. 5 — Security and Privacy Controls, Dezember 2020; insbesondere PE-3, SC-11 und SC-41.
4. National Institute of Standards and Technology: NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security, September 2023; insbesondere Abschnitt 6.2.7.
5. National Institute of Standards and Technology: NIST SP 800-193 — Platform Firmware Resiliency Guidelines, Mai 2018.
6. NXP Semiconductors: AN13037 Rev. 3 — LPC55Sxx Debug Authentication, 12. Dezember 2023.
7. International Electrotechnical Commission: IEC 60529 Ed. 2.2 — Degrees of protection provided by enclosures (IP Code), konsolidierte Ausgabe, 29. August 2013.
8. International Electrotechnical Commission: IEC 62262:2002/AMD1:2021 — Schutz gegen äußere mechanische Einwirkungen (IK-Code), Amendment vom 3. September 2021.
9. Europäische Union: Verordnung (EU) 2024/2847 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen, 23. Oktober 2024.