Ist UART eine Netzwerkschnittstelle?

September 4, 2026 · Reading Time: 16-20 minutes

Auf nahezu jeder Leiterplatte sitzt ein serieller Zugang: ein bestückter Pfostenstecker, vier unbestückte Testpunkte oder ein Pad-Feld neben dem Prozessor. Im Entwicklungsalltag ist das der Weg zur Bootmeldung, zur Servicekonsole und zur Fehlersuche im Feld. In der Nachweisführung nach DIN EN 18031 wird derselbe Zugang zur Streitfrage, denn von seiner Einordnung hängt ab, welche Mechanismen der Norm überhaupt greifen. Dieser Artikel beantwortet, wann ein UART als Netzwerkschnittstelle zu behandeln ist, wann eine andere Einordnung trägt und welche Anforderungen in jedem Fall gelten.

Kurz gesagt

In den meisten Fällen nein. Ein UART ist für sich genommen keine Netzwerkschnittstelle. Maßgeblich ist nicht der Bustyp, sondern die Funktion des Zugangs im konkreten Gerät:

• Punkt-zu-Punkt-Verbindung zu einem angeschlossenen Bauteil, Modul oder Gerät: Maschinenschnittstelle.
  Keine Netzwerkschnittstelle, weil kein Zugang zu einem Netz entsteht.
• Servicekonsole, die ein Mensch über ein Terminal bedient: auf Anwendungsebene Benutzerschnittstelle, auf physischer Ebene Maschinenschnittstelle.
  Relevant wird damit [AUM-1-2] und nicht [AUM-1-1].
• Serieller Zugang, über den das Gerät Zugang zu einem Netz erhält oder bereitstellt: Netzwerkschnittstelle.
  Typisch bei PPP über Modem, AT-Kommandos zu einem Mobilfunkmodul oder einem Mehrteilnehmerbus wie RS-485.

Entscheidend ist der zweite Teil der Antwort: Ein UART, der von außerhalb des Geräts erreichbar ist, bleibt in jedem dieser Fälle eine externe Schnittstelle. Damit greifen [GEC-5] und [GEC-6] unabhängig davon, wie die Einordnung ausfällt, Zugriffe über den Zugang unterliegen der Betrachtung nach [ACM-1].

„UART“ ist in DIN EN 18031-1 kein eigener Begriff

DIN EN 18031-1 nennt keine Bustechnologien als Anforderungsmerkmal. Weder UART noch SPI, I²C, JTAG oder SWD tauchen als eigene Begriffe auf. Schnittstellentypen sind stattdessen über ihre Funktion definiert. Genau daran ist die Einordnung auszurichten.

Die Netzwerkschnittstelle ist definiert als externe Schnittstelle, die es dem Gerät ermöglicht, Zugang zu einem Netz zu haben oder Zugang zu einem Netz bereitzustellen. Als Beispiele nennt die Definition einen kabelgebundenen LAN-Port sowie drahtlose Schnittstellen für WLAN oder Nahbereichsfunk. Die Maschinenschnittstelle ist demgegenüber die externe Schnittstelle zwischen dem Gerät und einem Dienst oder einem Gerät, die Benutzerschnittstelle die externe Schnittstelle zwischen dem Gerät und einem Nutzer. Alle drei sind spezifische Ausprägungen der externen Schnittstelle, also einer Schnittstelle des Geräts, die von außerhalb des Geräts erreichbar ist. Diese Systematik haben wir im Artikel zu den Netzwerkschnittstellen in DIN EN 18031 ausführlich beschrieben.

Wichtig ist eine Feinheit der Definitionen: Als Gerät im Sinne der Norm gilt ein Produkt, das außerhalb des betrachteten Geräts liegt. Eine serielle Verbindung zwischen zwei Bausteinen innerhalb desselben Produkts ist deshalb zunächst keine externe Schnittstelle und damit auch keine Maschinenschnittstelle. Sie wird erst dann zum Prüfgegenstand, wenn sie von außerhalb erreichbar ist, etwa über einen zugänglichen Pfostenstecker oder über Testpunkte.

Zwei Prüffragen entscheiden über die Einordnung

Die Einordnung eines seriellen Zugangs lässt sich auf zwei aufeinander aufbauende Prüfungen zurückführen:

1. Erreichbarkeit von außerhalb des Geräts. Ist der Zugang von außen zugänglich, handelt es sich um eine externe Schnittstelle. Erst damit ist er überhaupt Gegenstand der Schnittstellenbetrachtung.
2. Zugang zu einem Netz. Verschafft der Zugang dem Gerät Zugang zu einem Netz oder stellt er einen solchen bereit, liegt eine Netzwerkschnittstelle vor. Andernfalls handelt es sich um eine Maschinen- oder Benutzerschnittstelle, je nachdem, ob am anderen Ende ein Dienst beziehungsweise Gerät oder ein Mensch steht.

Bei der ersten Frage wird häufig zu großzügig argumentiert. Ein Gehäuse, das sich mit handelsüblichem Werkzeug öffnen lässt, macht einen Debug-Header nicht unerreichbar. Die Guidance zu [GEC-5] stellt die Nichtexposition auf drei Konstellationen ab: Die Schnittstelle ist durch die vorgesehene Einsatzumgebung physisch geschützt, sie ist deaktiviert oder sie ist blockiert. Der Verschluss des Produktgehäuses gehört nicht dazu. Ausdrücklich einbezogen sind auch solche physischen externen Schnittstellen, die eigentlich für die geräteinterne Kommunikation vorgesehen sind.

Bei der zweiten Frage entscheidet, ob am seriellen Zugang ein Netz hängt oder ein einzelner Kommunikationspartner. Eine feste Verbindung zu genau einem Sensor ist kein Netz. Ein Bus mit adressierten Teilnehmern, ein Mobilfunkmodul, das über AT-Kommandos eine Datenverbindung aufbaut, oder eine serielle Strecke, über die ein IP-Stack läuft, sind es sehr wohl.

Vier typische Konstellationen und ihre Einordnung

Die folgenden Fälle decken den überwiegenden Teil der Praxis ab:

• Debug-UART mit Bootlog und Servicekonsole. Am anderen Ende sitzt ein Mensch mit einem Terminalprogramm. Auf physischer Ebene liegt eine Maschinenschnittstelle zum angeschlossenen Rechner vor, auf Anwendungsebene eine Benutzerschnittstelle. Das entspricht der Systematik, die DIN EN 18031-1 am Beispiel der über USB angeschlossenen Tastatur beschreibt.
• UART zu einem Sensor oder Aktor. Eine feste Punkt-zu-Punkt-Verbindung zu einem externen Bauteil ist eine Maschinenschnittstelle. Ein Netz entsteht dabei nicht.
• UART zu einem Mobilfunk-, WLAN- oder Bluetooth-Modul. Hier verschafft der serielle Zugang dem Gerät Zugang zu einem Netz. Die Einordnung als Netzwerkschnittstelle liegt nahe, und zwar unabhängig davon, dass die eigentliche Funkstrecke im Modul endet.
• Serieller Feldbus mit mehreren Teilnehmern. RS-485-Strecken mit Modbus RTU oder vergleichbaren Protokollen adressieren mehrere Teilnehmer und bilden damit ein Netz. Die Einordnung als Netzwerkschnittstelle ist der Regelfall.

Die vierte Konstellation wird am häufigsten falsch geführt, weil der elektrische Aufbau nach „nur seriell“ aussieht. Maßgeblich ist jedoch die Funktion. Wer eine Modbus-Strecke als Maschinenschnittstelle dokumentiert, verliert damit sämtliche Betrachtungen, die an Netzwerkschnittstellen hängen.

Die Einordnung entscheidet darüber, welche Mechanismen greifen

Der praktische Wert der Frage liegt in ihren Folgen. Mehrere Anforderungen der DIN EN 18031-1 knüpfen ausdrücklich am Schnittstellentyp an:

• [AUM-1-1] verlangt Authentifizierung für Zugriffskontrollmechanismen, die Zugriffe über Netzwerkschnittstellen verwalten. Für Benutzerschnittstellen regelt [AUM-1-2] dieselbe Frage mit einer eigenen Ausnahmesystematik. Eine Anforderung, die an Maschinenschnittstellen ansetzt, kennt die AUM-Familie nicht.
• [SCM-1] verlangt sichere Kommunikationsmechanismen für Security- und Netzwerk-Assets, die über Netzwerkschnittstellen mit anderen Entitäten kommuniziert werden.
• [GEC-2] bis [GEC-4] betreffen die im Auslieferungszustand exponierten Netzwerkschnittstellen und die darüber exponierten Dienste, also Begrenzung, Abschaltbarkeit und Dokumentation.
• [GEC-5] und [GEC-6] setzen dagegen an der externen Schnittstelle an und damit an jedem seriellen Zugang, unabhängig von seiner weiteren Einordnung.

Daraus folgt ein Ergebnis, das viele Hersteller überrascht: Ein UART, der sauber als Maschinenschnittstelle geführt wird, löst keine Authentifizierungspflicht nach [AUM-1] aus. Das bedeutet aber nicht, dass er unbewertet bleibt. [ACM-1] fragt nach Zugriffskontrolle für Security- und Netzwerk-Assets, die für Entitäten zugänglich sind. Entitäten sind nach der Definition der Norm Nutzer, Geräte, Anlagen oder Dienste. Der Anforderungstext führt die externe Schnittstelle, über die ein Zugriff erfolgt, sogar ausdrücklich als eine der Eigenschaften auf, an die sich Zugriffsrechte knüpfen lassen. Ein serieller Zugang, über den sich Konfiguration lesen oder verändern lässt, ist damit ein Fall für [ACM-1], auch wenn [AUM-1] nicht greift.

Umgekehrt gilt: Sobald die Servicekonsole von einem Menschen bedient wird, ist auf Anwendungsebene [AUM-1-2] einschlägig. Dessen Ausnahmen sind eng, sie stellen auf physische oder logische Maßnahmen der vorgesehenen Einsatzumgebung sowie auf rein lesende Zugriffe ab. Warum eine Ausnahme nie eine Freistellung, sondern immer eine Begründungspflicht ist, haben wir im vorherigen Artikel dieser Reihe ausgeführt.

GEC-5 und GEC-6 greifen unabhängig von der Einordnung

Zwei Anforderungen lassen sich über die Einordnungsfrage nicht umgehen.

[GEC-5] verlangt, dass ein Gerät nur solche physischen externen Schnittstellen exponiert, die für die vorgesehene Funktionalität notwendig sind. Zu dokumentieren ist je Schnittstelle der Zweck und die Art der Schnittstelle, dazu die Beschreibung der vorgesehenen Gerätefunktionalität sowie der gewählte Pfad durch den Entscheidungsbaum samt Begründung. Die vorgesehene Funktionalität darf dabei mehrere Anwendungsfälle umfassen, eine exponierte Schnittstelle muss in mindestens einem davon einem Zweck dienen. Für einen Debug-Header heißt das: Entweder er dient einem dokumentierten Zweck im Feld, etwa der Wartung durch autorisiertes Personal, oder er ist im Serienstand deaktiviert oder blockiert.

Besonders unangenehm wird die zugehörige funktionale Vollständigkeitsprüfung. Dabei wird aktiv versucht, exponierte physische Schnittstellen aufzudecken, und zwar ausdrücklich auch solche, deren Funktion weder aktiviert noch dokumentiert ist. Geprüft werden dazu die Dokumentation und das Gerät selbst. Wird eine physische externe Schnittstelle gefunden, die nicht dokumentiert ist, lautet das Ergebnis FAIL. Ein nicht dokumentierter Pfostenstecker führt also nicht zu einer Rückfrage, sondern zu einem Befund.

[GEC-6] verlangt die Validierung von Eingaben, die über externe Schnittstellen empfangen werden, sofern sie Security- oder Netzwerk-Assets beeinflussen können. Zu dokumentieren sind je externer Schnittstelle die genutzten APIs, Protokolle, Eingabedatentypen und Dateiformate sowie die Art der syntaktischen und semantischen Prüfung. Für eine serielle Konsole bedeutet das eine belastbare Aussage über den Parser: Wie werden Länge, Struktur und Wertebereiche der empfangenen Daten geprüft, bevor sie verarbeitet werden? Genau diese Betrachtung fehlt in der Praxis häufig, weil serielle Eingaben implizit als vertrauenswürdig gelten.

Gern prüfen wir Ihre Schnittstellendokumentation gegen diese beiden Anforderungen und gleichen sie mit dem tatsächlichen Verhalten des Geräts ab.

Typische Befunde an seriellen Zugängen

Dieselben Muster fallen in Projekten immer wieder auf:

• Bootloader-Prompt aktiv. Die Konsole erlaubt den Abbruch des Startvorgangs und das Setzen von Startparametern. Damit sind sensible Konfiguration und Sicherheitsfunktionen erreichbar.
• Root-Shell ohne Anmeldung. Der serielle Zugang führt direkt in eine Systemkonsole mit vollen Rechten, ohne dass ein Zugriffskontroll- oder Authentifizierungsmechanismus dokumentiert wäre.
• Unbestückte Testpunkte als nicht vorhanden geführt. Pads und Vias ohne Stecker sind für ein Prüfteam mit Lötkolben oder Federkontakt erreichbar und deshalb zu dokumentieren.
• Serienstand und Entwicklungsstand vermischt. Dokumentiert wird ein Gerät mit deaktiviertem UART, ausgeliefert wird die Firmware mit aktiver Konsole.
• Feldbus als Maschinenschnittstelle deklariert. Eine RS-485-Strecke mit mehreren adressierten Teilnehmern wird als einfache Sensorverbindung geführt, wodurch die SCM-Betrachtung entfällt.
• Schnittstelle zum Funkmodul übersehen. Der serielle Kanal zum Mobilfunk- oder WLAN-Modul taucht in der Schnittstellenliste nicht auf, obwohl über ihn der gesamte Netzzugang läuft.
• Vom Referenzdesign geerbte Konsole. Der Debug-Ausgang des Evaluierungsboards bleibt im Serienprodukt aktiv, weil ihn niemand bewusst übernommen hat.

Auffällig ist die Verteilung: Die meisten Befunde entstehen nicht durch eine falsche Einordnung, sondern dadurch, dass der serielle Zugang in der Dokumentation gar nicht erst auftaucht.

Vier Schritte zur belastbaren Einordnung

1. Alle seriellen Zugänge erfassen, einschließlich unbestückter Header, Testpunkte und Pads, sowie der internen Verbindungen zu Modulen, die von außen erreichbar sind.
2. Erreichbarkeit bestimmen: Ist der Zugang von außerhalb des Geräts zugänglich, und wenn nein, beruht das auf einer physisch schützenden Einsatzumgebung, auf Deaktivierung oder auf Blockierung?
3. Funktion bestimmen: Verschafft der Zugang Zugang zu einem Netz oder stellt er einen bereit? Steht am anderen Ende ein Mensch, ein Dienst oder ein Gerät?
4. Ergebnis mit Begründung festhalten: Schnittstellentyp, Zweck, Auslieferungszustand, betroffene Assets und die daraus folgenden anwendbaren Mechanismen.

Unsere Schnittstellen-Checkliste führt durch die Angaben, die DIN EN 18031 je Schnittstelle verlangt, und eignet sich als Raster für genau diese Aufnahme.

Häufige Fragen

Ist UART nach DIN EN 18031 eine Netzwerkschnittstelle? In der Regel nicht. Eine Netzwerkschnittstelle ist eine externe Schnittstelle, die dem Gerät Zugang zu einem Netz verschafft oder einen solchen bereitstellt. Ein serieller Punkt-zu-Punkt-Zugang erfüllt das nicht. Läuft über den UART jedoch ein Netzzugang, etwa zu einem Mobilfunkmodul oder über einen Mehrteilnehmerbus, ist die Einordnung als Netzwerkschnittstelle sachgerecht.

Muss ein Debug-UART überhaupt dokumentiert werden? Ja, sofern er von außerhalb des Geräts erreichbar ist. [GEC-5] verlangt für jede physische externe Schnittstelle eine Beschreibung mit Zweck und Schnittstellenart. In der funktionalen Vollständigkeitsprüfung wird das Gerät aktiv auf nicht dokumentierte Schnittstellen untersucht.

Braucht eine serielle Servicekonsole eine Authentifizierung? Bedient ein Mensch die Konsole, liegt auf Anwendungsebene eine Benutzerschnittstelle vor, für die [AUM-1-2] gilt. Verwaltet der Zugriff Security- oder Netzwerk-Assets im Sinne der Anforderung und greift keine der dort genannten Ausnahmen, ist eine Authentifizierung erforderlich. Die Inanspruchnahme einer Ausnahme setzt eine dokumentierte Begründung voraus.

Genügt es, den UART in der Serienfirmware zu deaktivieren? Deaktivierte oder blockierte Schnittstellen gelten nach der Guidance zu [GEC-5] als nicht exponiert. Zu beachten ist, dass die Abschnitte „Rationale“ und „Guidance“ der Norm unterstützenden Charakter haben und für sich genommen keine Konformitätsvermutung begründen. Die Deaktivierung ist deshalb zu beschreiben und muss dem tatsächlichen Auslieferungszustand entsprechen.

Ist ein UART innerhalb des Gehäuses eine externe Schnittstelle? Maßgeblich ist die Erreichbarkeit von außerhalb des Geräts, nicht die Sichtbarkeit im geschlossenen Zustand. Ausdrücklich einbezogen sind auch Schnittstellen, die für die geräteinterne Kommunikation vorgesehen sind. Ein verschraubtes Gehäuse allein trägt die Einstufung als nicht exponiert daher nicht.

Gilt für JTAG und SWD dasselbe? Die Einordnungslogik ist identisch. Debug- und Programmierschnittstellen sind praktisch nie Netzwerkschnittstellen, aber sie sind physische externe Schnittstellen und damit von [GEC-5] und, soweit Eingaben verarbeitet werden, von [GEC-6] erfasst.

Muss die Kommunikation über einen seriellen Bus verschlüsselt werden? [SCM-1] knüpft an Netzwerkschnittstellen an. Ist der serielle Bus als Netzwerkschnittstelle einzuordnen und werden darüber Security- oder Netzwerk-Assets übertragen, greift die Anforderung, soweit keine der beiden dort genannten Ausnahmen einschlägig ist.

Fazit

Die Frage nach dem UART ist in Wahrheit keine Frage nach einer Technologie, sondern nach einer Funktion. DIN EN 18031-1 ordnet Schnittstellen danach ein, wer oder was am anderen Ende steht und ob ein Netz im Spiel ist. Für die meisten seriellen Zugänge lautet das Ergebnis Maschinen- oder Benutzerschnittstelle, für serielle Feldbusse und Modulanbindungen dagegen häufig Netzwerkschnittstelle. Praktisch bedeutsamer als die Einordnung selbst ist jedoch, dass ein von außen erreichbarer serieller Zugang in jedem Fall eine externe Schnittstelle bleibt und damit [GEC-5], [GEC-6] sowie die Zugriffsbetrachtung nach [ACM-1] auslöst. Der teuerste Fehler ist deshalb nicht die falsche Kategorie, sondern die fehlende Zeile in der Schnittstellenliste. Wie diese Liste systematisch entsteht und warum sie neben der Asset-Identifikation die zweite tragende Säule der Nachweisführung ist, haben wir in den beiden vorangegangenen Artikeln beschrieben.

Im nächsten Artikel unserer RED-DA-Reihe wechseln wir die Perspektive vom einzelnen Bauteil zurück auf das Produkt: Wir führen den Weg von Artikel 3 Absatz 3 der Funkanlagenrichtlinie bis zum anwendbaren Normteil als durchgehenden Entscheidungsbaum zusammen, mit allen Verzweigungen, die dabei zu dokumentieren sind.

Wenn Sie die Einordnung Ihrer Schnittstellen lieber direkt mit uns durchgehen möchten: In einem kostenfreien Erstgespräch nehmen wir serielle Zugänge, Debug-Schnittstellen und den Auslieferungszustand Ihres Geräts auf und ordnen sie den Anforderungen der Norm zu. Mehr dazu auf unserer Seite zur RED-DA-Beratung.

---

Dieser Artikel gibt einen strukturierten Überblick und ersetzt keine Einzelfallbewertung. Maßgeblich sind der Wortlaut der Funkanlagenrichtlinie 2014/53/EU, der Delegierten Verordnung (EU) 2022/30 sowie des Normteils DIN EN 18031-1.