Mythos oder Fakt: „Jede Netzwerkschnittstelle braucht eine Authentifizierung“

28. August 2026 · Lesedauer: 15-19 Minuten

„Alles, was über das Netz erreichbar ist, muss hinter eine Anmeldung.“ Diese Regel klingt nach solider Sicherheitsarbeit und führt in DIN-EN-18031-Projekten trotzdem regelmäßig zu falschen Ergebnissen. Sie erzeugt Aufwand an Stellen, an denen die Norm nichts verlangt, und sie lenkt von den Stellen ab, an denen sie sehr wohl etwas verlangt. Vor allem aber verschiebt sie den Bezugspunkt: Maßgeblich ist nicht, ob eine Schnittstelle existiert, sondern welcher Zugriff über sie läuft und ob dieser Zugriff überhaupt einem Zugriffskontrollmechanismus unterliegt. Dieser Artikel ordnet ein, wo die Grenze verläuft.

Kurz gesagt: Mythos

Nein, DIN EN 18031-1 verlangt keine Authentifizierung für jede Netzwerkschnittstelle. Die Anforderung [AUM-1-1] setzt an drei Bedingungen an, die alle erfüllt sein müssen:

• Es besteht ein Zugriffskontrollmechanismus nach [ACM-1].
  Fällt ein Asset schon aus [ACM-1] heraus, stellt sich die Authentifizierungsfrage nicht.
• Der Zugriff läuft über eine Netzwerkschnittstelle und hat eine der drei relevanten Wirkungen. Lesen vertraulicher Netzwerkfunktionskonfiguration oder vertraulicher Sicherheitsparameter, Verändern sensibler Netzwerkfunktionskonfiguration oder sensibler Sicherheitsparameter, oder das Nutzen von Netzwerk- und Sicherheitsfunktionen.
  Zugriffe ohne eine dieser Wirkungen sind von [AUM-1-1] nicht erfasst.
• Keine der beiden Ausnahmen greift. Der Anforderungstext benennt sie selbst.
  Die Ausnahme ist allerdings keine Freistellung, sondern eine Begründungspflicht.

Der wahre Kern des Mythos: Wo diese Bedingungen zusammentreffen, ist die Authentifizierung tatsächlich verpflichtend, und zwar unabhängig davon, für wie unkritisch der Hersteller den Zugriff hält.

Der Ursprung des Mythos

Die Faustregel stammt aus der allgemeinen Sicherheitspraxis, wo sie ihre Berechtigung hat. Wer ein Produkt härtet, fährt gut damit, jeden erreichbaren Dienst zunächst als schutzbedürftig zu behandeln. In der Nachweisführung nach DIN EN 18031 ist diese Denkweise jedoch das falsche Werkzeug, weil nicht das gewünschte Sicherheitsniveau maßgeblich ist, sondern eine nachvollziehbare Entscheidung je Element.

Hinzu kommt eine begriffliche Verwechslung. Zugriffskontrolle und Authentifizierung werden im Alltag oft synonym verwendet, in der Norm sind es zwei getrennte Mechanismenfamilien mit einer klaren Reihenfolge. [ACM-1] entscheidet, ob der Zugriff auf ein Security- oder Netzwerk-Asset überhaupt verwaltet werden muss. Erst wenn das bejaht ist, fragt [AUM-1-1], ob dieser verwaltete Zugriff eine Authentifizierung braucht. Die Anforderung beschreibt also die Eigenschaft eines Zugriffskontrollmechanismus und nicht die Eigenschaft eines Steckers oder einer Antenne.

Beide Fehlschlüsse sind in der Praxis etwa gleich häufig. Der eine Hersteller authentifiziert pauschal alles und kann die Entscheidung anschließend nicht sauber dokumentieren, weil er nie geprüft hat, welche Zugriffe eigentlich betroffen sind. Der andere beruft sich auf eine Ausnahme, ohne die dafür verlangte Beschreibung liefern zu können.

Die Anforderung setzt am Zugriff an, nicht an der Schnittstelle

Der Bezugspunkt von [AUM-1-1] ist der einzelne verwaltete Zugriff. Praktisch heißt das: Ein und dieselbe Netzwerkschnittstelle kann mehrere Zugriffe tragen, die unterschiedlich zu bewerten sind.

Ein Beispiel aus einem typischen Gerät mit Ethernet-Port und WLAN:

• Konfigurationsoberfläche über HTTPS: Verändert sensible Netzwerkfunktionskonfiguration, unterliegt einem Zugriffskontrollmechanismus, Authentifizierung erforderlich.
• Firmware-Update über das Netz: Nutzt eine Sicherheitsfunktion, Authentifizierung erforderlich.
• Abfrage der öffentlichen IP-Konfiguration: Nach der Guidance der Norm ein Beispiel für einen Zugriff, bei dem eine Authentifizierung nicht zwingend ist.
• Adressbezug über DHCP: Laut Guidance ein Beispiel für ein Protokoll, das Zugang zu Security- oder Netzwerk-Assets geben kann, aber ohne Authentifizierung zugänglich sein soll.

Alle vier laufen über dieselbe physische Schnittstelle. Wer die Bewertung auf Schnittstellenebene führt, kann dieses Ergebnis gar nicht abbilden.

Deshalb hängt die Qualität der AUM-Bewertung unmittelbar an zwei Vorarbeiten: an der vollständigen Asset-Liste, die wir im Artikel zur systematischen Asset-Identifikation beschrieben haben, und an der sauberen Schnittstellenaufnahme aus dem vorherigen Artikel dieser Reihe. Fehlt eines von beiden, bleibt die Zuordnung Zugriff zu Schnittstelle zu Asset lückenhaft, und die Entscheidungsbäume laufen ins Leere.

Der Anforderungstext kennt zwei Ausnahmen für Netzwerkschnittstellen

Der Anforderungstext von [AUM-1-1] nimmt zwei Konstellationen aus:

Erstens Zugriffe auf Netzwerkfunktionen oder deren Konfiguration, bei denen die vorgesehene Gerätefunktionalität das Fehlen der Authentifizierung erfordert. Gemeint sind Fälle, in denen eine Anmeldung die Funktion selbst unmöglich machen würde. Die Guidance nennt hier Protokolle wie DHCP und ICMP sowie als weitere Beispiele das Lesen der öffentlichen IP-Konfiguration, das Lesen eines öffentlichen Schlüssels und das Auslesen des öffentlichen Netzwerkzustands des Geräts. Der Prüfmaßstab ist eng: Nicht der Komfort entscheidet, sondern die Frage, ob die vorgesehene Funktionalität ohne den unauthentifizierten Zugriff überhaupt erbracht werden kann.

Zweitens Zugriffe über Netze, in denen physische oder logische Maßnahmen der vorgesehenen Einsatzumgebung die Erreichbarkeit auf autorisierte Entitäten begrenzen. Als Beispiele führt der Anforderungstext eine physische Zugangskontrolle an, die nur autorisierten Zugang zum Innenraum eines Straßen- oder Wasserfahrzeugs zulässt, sowie den Fall, dass nur autorisierte Personen an die WPS-Taste eines Heim-Gateways innerhalb eines Privathauses gelangen. Wichtig ist der Zusatz bei den Zugriffskontrollmechanismen: Funkschnittstellen können auch dann erreichbar sein, wenn das Gerät in einer Umgebung steht, die physische Manipulation verhindert. Ein WLAN reicht regelmäßig über die Wohnungsgrenze hinaus. Wer sich auf die Einsatzumgebung beruft, muss also die konkret wirksame Begrenzung benennen und nicht nur die Aufstellungssituation beschreiben.

Beide Ausnahmen beziehen sich auf den Zugriff, nicht auf das Gerät. Sie lassen sich deshalb nicht pauschal für ein Produkt in Anspruch nehmen.

Benutzerschnittstellen folgen einer eigenen Ausnahmesystematik

Parallel zu [AUM-1-1] regelt [AUM-1-2] dieselbe Frage für Benutzerschnittstellen, allerdings mit anderen Ausnahmen. Ausgenommen sind dort Zugriffe, bei denen physische oder logische Maßnahmen der vorgesehenen Einsatzumgebung die Erreichbarkeit auf autorisierte Entitäten begrenzen, und zusätzlich rein lesende Zugriffe auf Netzwerkfunktionen oder deren Konfiguration, wenn der Zugriff ohne Authentifizierung nötig ist, um die vorgesehene Gerätefunktionalität zu ermöglichen oder weil rechtliche Vorgaben eine Authentifizierung nicht zulassen.

Diese Unterscheidung ist der Grund, warum die im vorherigen Artikel beschriebene Mehrfachzuordnung von Schnittstellen über Kommunikationsschichten hinweg praktisch relevant wird. Ein Webinterface ist auf Anwendungsebene eine Benutzerschnittstelle und auf Netzwerkebene eine Netzwerkschnittstelle. Wer es ausschließlich als Benutzerschnittstelle führt, argumentiert mit der Ausnahmesystematik von [AUM-1-2] an einer Stelle, an der [AUM-1-1] einschlägig ist. Diese Verwechslung gehört zu den Befunden, die in einer konzeptuellen Bewertung schnell auffallen, weil die beiden Ausnahmekataloge unterschiedliche Nachweise verlangen.

Die Ausnahme ist eine Begründungspflicht, keine Freistellung

Der teuerste Irrtum liegt nicht in der Frage, ob eine Ausnahme greift, sondern in der Annahme, eine Ausnahme müsse nicht belegt werden. DIN EN 18031-1 sieht für jeden Pfad durch den Entscheidungsbaum eine dokumentierte Begründung vor.

Wer sich auf die erste Ausnahme beruft, muss nach [E.Info.AUM-1-1.ACM.IntendedFunctionality] die ohne Authentifizierung zugänglichen Netzwerkfunktionen oder deren Konfiguration beschreiben, dazu die vorgesehene Gerätefunktionalität und diejenigen ihrer Eigenschaften, die das Fehlen der Authentifizierung erforderlich machen. Wer sich auf die zweite Ausnahme beruft, muss nach [E.Info.AUM-1-1.ACM.AuthorizedEntity] die betreffenden Netze und die physischen oder logischen Maßnahmen der vorgesehenen Einsatzumgebung beschreiben, die den Zugang auf autorisierte Entitäten begrenzen. Und wo Authentifizierung erforderlich ist, verlangt [E.Info.AUM-1-1.ACM.AuthenticationMechanism] eine Beschreibung der umgesetzten Mechanismen.

Die Begründungen sind dabei den einzelnen Entscheidungsknoten zugeordnet: Die Begründung für [DT.AUM-1-1.DN-1] stützt sich auf die Beschreibung der vorgesehenen Funktionalität, die für [DT.AUM-1-1.DN-2] auf die Beschreibung der autorisierten Entitäten und der begrenzenden Maßnahmen. Fehlt eine dieser Begründungen oder trägt sie nicht, wird der Pfad in der konzeptuellen Bewertung mit FAIL bewertet. Der Befund lautet dann nicht „Authentifizierung fehlt“, sondern „Begründung fehlt“, mit derselben Konsequenz für den Nachweis.

Wenn Sie unsicher sind, ob Ihre Ausnahmebegründungen in dieser Form tragen, gehen wir sie gemeinsam mit Ihnen durch und gleichen sie gegen die Informationsanforderungen der Norm ab.

Jeder Zugriff wird einzeln entschieden

DIN EN 18031 trifft die Anwendbarkeitsentscheidung nicht einmal für das Gerät, sondern für jedes betrachtete Element gesondert. Der informative Anhang der Norm formuliert das ausdrücklich: Wird die Anwendbarkeit einer Anforderung auf externe Schnittstellen geprüft, ist für jede externe Schnittstelle unabhängig zu entscheiden, ob die Anforderung und alle weiteren Anforderungen dieses Abschnitts zu erfüllen sind.

Daraus folgen zwei Konsequenzen, die im Projektalltag oft übersehen werden:

• Eine Sammelbegründung trägt nicht. Der Satz „Alle Schnittstellen sind authentifiziert“ ist ebenso wenig ein Nachweis wie „Alle Schnittstellen liegen in einer geschützten Umgebung“. DIN EN 18031-1 verlangt je Zugriffskontrollmechanismus einen Pfad und eine Begründung.
• Die Entscheidung wirkt nach unten weiter. Wird ein Mechanismus als nicht anwendbar eingestuft, entfallen auch die weiteren Anforderungen des betreffenden Abschnitts. Umgekehrt ziehen anwendbare Mechanismen die Folgeanforderungen mit sich: Ist eine Authentifizierung nach [AUM-1-1] erforderlich, verlangt [AUM-2] mindestens einen Faktor aus den Kategorien Wissen, Besitz oder Inhärenz, und die weiteren Anforderungen der AUM-Familie zu Validierung, Änderbarkeit, Passwortstärke und Brute-Force-Schutz werden relevant.

Gerade der zweite Punkt macht die vermeintlich sichere Variante „im Zweifel authentifizieren“ teuer. Wer eine Authentifizierung einführt, ohne sie zu benötigen, zieht die gesamte nachgelagerte Anforderungskette in seinen Nachweis.

Typische Befunde in beide Richtungen

In der Praxis fallen dieselben Muster immer wieder auf:

• Ausnahme ohne Beschreibung. Der Entscheidungsbaum endet bei NOT APPLICABLE, die zugehörige Beschreibung der vorgesehenen Funktionalität oder der begrenzenden Maßnahmen fehlt.
• Einsatzumgebung als Universalargument. Die Begrenzung auf autorisierte Entitäten wird behauptet, ohne die Funkreichweite über die Grundstücksgrenze hinaus zu betrachten.
• Zugriffe nicht getrennt betrachtet. Die Bewertung erfolgt je Schnittstelle statt je verwaltetem Zugriff, wodurch Lese- und Schreibzugriffe in derselben Zeile landen.
• Ebenen verwechselt. Ein netzseitig erreichbares Webinterface wird über die Ausnahmesystematik von [AUM-1-2] begründet.
• Interne Dienste vergessen. Debug- und Servicezugänge, Telemetrie-Endpunkte und Schnittstellen aus Referenzdesigns tauchen in der Zugriffsliste nicht auf, sind im Auslieferungszustand aber erreichbar.
• Pauschale Authentifizierung ohne Bewertung. Alles ist mit einem Passwort geschützt, die Anwendbarkeitsentscheidung nach [ACM-1] und [AUM-1-1] wurde nie dokumentiert, und die nachgelagerten AUM-Anforderungen sind entsprechend unbearbeitet.

Häufige Fragen

Muss jede Netzwerkschnittstelle meines Geräts authentifiziert werden? Nein. [AUM-1-1] verlangt Authentifizierung für Zugriffskontrollmechanismen, die nach [ACM-1] erforderlich sind und über Netzwerkschnittstellen bestimmte Zugriffe auf Security- oder Netzwerk-Assets verwalten. Bezugspunkt ist der einzelne verwaltete Zugriff, nicht die Schnittstelle als solche.

Welche Zugriffe erfasst AUM-1-1? Zugriffe, die vertrauliche Netzwerkfunktionskonfiguration oder vertrauliche Sicherheitsparameter lesen, sensible Netzwerkfunktionskonfiguration oder sensible Sicherheitsparameter verändern oder Netzwerk- beziehungsweise Sicherheitsfunktionen nutzen.

Sind DHCP und ICMP von der Authentifizierung ausgenommen? Die Guidance nennt beide als Beispiele für Protokolle, die Zugang zu Security- oder Netzwerk-Assets geben können, aber ohne Authentifizierung zugänglich sein sollen. Die Einordnung bleibt eine Einzelfallentscheidung und ist im Entscheidungsbaum zu begründen. 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.

Reicht das WLAN-Passwort als Authentifizierung? Die Guidance hält fest, dass eine Vertrauensbeziehung zu einem Netz, etwa der Besitz eines geteilten Geheimnisses wie der WLAN-Zugangsdaten, zur Authentifizierung einer Entität herangezogen werden kann. Ob das im konkreten Fall trägt, hängt vom betrachteten Zugriff und den nachgelagerten AUM-Anforderungen ab und ist zu begründen.

Genügt eine Ein-Faktor-Authentifizierung? [AUM-2] verlangt für Authentifizierungsmechanismen, die nach [AUM-1-1] oder [AUM-1-2] erforderlich sind, die Prüfung der Behauptung einer Entität anhand von Nachweisen aus mindestens einem Element der Kategorien Wissen, Besitz und Inhärenz. Eine Mehr-Faktor-Authentifizierung ist damit nicht generell gefordert.

Was passiert, wenn eine Ausnahme nicht begründet ist? Die konzeptuelle Bewertung prüft neben dem gewählten Pfad durch den Entscheidungsbaum auch dessen Begründung. Ist die Begründung nicht korrekt oder fehlt sie, wird die Bewertung mit FAIL abgeschlossen, unabhängig davon, wie das Gerät technisch umgesetzt ist.

Fazit

„Jede Netzwerkschnittstelle braucht eine Authentifizierung“ ist ein Mythos, und zwar einer, der in beide Richtungen schadet. Er führt zu unnötigem Aufwand, wo die Norm nichts verlangt, und zu falscher Sicherheit, wo eine Ausnahme behauptet, aber nie begründet wurde. Maßgeblich ist eine Kette, die konsequent am einzelnen Element ansetzt: Asset, Zugriffskontrollmechanismus nach [ACM-1], verwalteter Zugriff über eine Netzwerkschnittstelle, Prüfung der beiden Ausnahmen, dokumentierte Begründung je Pfad. Wer diese Kette je Zugriff durchhält, hat den AUM-Teil seiner Nachweisführung im Griff. Wer sie durch eine pauschale Regel ersetzt, hat am Ende beides nicht: weder die Begründung noch die Ersparnis. Die Grundlagen dafür liegen in der Schnittstellenaufnahme, die wir im vorherigen Artikel beschrieben haben, und in der Abgrenzung des Netzwerk-Assets.

Im nächsten Artikel unserer RED-DA-Reihe greifen wir eine Schnittstelle heraus, deren Einordnung Hersteller besonders häufig beschäftigt: UART. Wir klären, unter welchen Bedingungen ein serieller Zugang als Netzwerkschnittstelle zu behandeln ist, wann eine andere Einordnung trägt und welche Anforderungen jeweils greifen.

Unsere Schnittstellen-Checkliste führt Sie strukturiert durch die Angaben, die DIN EN 18031 je Netzwerkschnittstelle verlangt, und schafft damit die Grundlage, um die Zugriffe je Schnittstelle sauber aufzulisten und zu bewerten.

Wenn Sie die AUM-Bewertung lieber direkt mit uns durchgehen möchten: In einem kostenfreien Erstgespräch nehmen wir Zugriffe, Schnittstellen und bestehende Ausnahmebegründungen 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.