802.1X und Zero Trust im Netzwerk – Identität statt Portnummer

Warum VLANs heute nicht mehr reichen

Über viele Jahre waren VLANs das Mittel der Wahl, um Netzwerke logisch zu segmentieren. Administrator:innen teilten das Unternehmensnetzwerk in Abteilungen auf – Vertrieb, Verwaltung, Produktion – und vergaben Ports am Switch entsprechend. Der Switch wies dem Gerät am Port das passende VLAN zu und machte es damit zum Teil eines abgeschlossenen Segments.

Lange setzten Unternehmen auf dieses Modell, um Netzwerke strukturiert aufzubauen. Mit zunehmender Komplexität und neuen Anforderungen stößt die reine VLAN-Logik jedoch an ihre Grenzen.

Analysten wie Palo Alto Networks sehen für 2025 den Trend hin zu Identity-first Security und Zero Trust als zentrale Leitlinie moderner Netzwerksicherheit. Klassische VLAN-Modelle geraten dadurch zunehmend ins Hintertreffen, da sie keine kontextabhängige Kontrolle erlauben und Angriffe im East-West-Traffic nicht verhindern können. Auch McKinsey betont, dass Netzwerke künftig adaptiver und resilienter werden müssen, statische Segmentierung reicht dafür nicht mehr aus.

Neue Herausforderungen in modernen Netzwerken

Die Anforderungen an Unternehmensnetze haben sich verändert. Endgeräte sind mobiler, die Zahl unterschiedlicher Gerätetypen steigt, und Angriffe sind raffinierter geworden. Einige Beispiele verdeutlichen das Problem:

• Bring Your Own Device (BYOD): Private Smartphones und Tablets benötigen häufig einen sicheren Zugang zu Unternehmensressourcen. Administrator:innen können diese Geräte nicht mehr vorab einem VLAN-Port zuordnen.
• IoT- und OT-Geräte: Von der IP-Kamera über die Zutrittskontrolle bis hin zu Fertigungssensoren – immer mehr Geräte möchten ins Netz. Viele davon bringen keine klassische Benutzer:innen-Identität mit.
• Mobilität der Endgeräte: Notebooks wandern von Büro zu Büro, Mitarbeitende wechseln zwischen Homeoffice, Meetingräumen und Hot-Desks. Ein statischer Port zeigt heute nicht mehr, welches Gerät angeschlossen ist.
• Neue Bedrohungslage: VLANs allein bieten keine granulare Zugriffskontrolle. Dringt ein Angreifer in ein Segment ein, bewegt er sich dort relativ frei – das ist der sogenannte East-West-Traffic. Dieses Konzept und die Risiken dahinter habe ich im Beitrag Von VLAN zu VXLAN – Segmentierung im Cisco-Netzwerk im Wandel der Zeit ausführlicher beschrieben.

VLAN-Sprawl und Managementprobleme

Ein weiteres Problem ist das Phänomen des VLAN-Sprawl. Jedes neue Projekt, jede Abteilung oder jede Sicherheitsanforderung bringt in klassischen Netzen oft ein zusätzliches VLAN mit sich. Mit der Zeit entstehen Hunderte VLANs, die Administrator:innen auf allen Switches konfigurieren und pflegen müssen. Das erhöht die Komplexität, erschwert Fehlersuche und belastet Change-Prozesse. Studien und Best-Practice-Guides weisen darauf hin, dass gerade in Campus-Netzen der Verwaltungsaufwand für VLANs schnell den eigentlichen Sicherheitsnutzen übersteigt.

Vom Port zur Identität mit 802.1x

Die Folge: VLANs reichen als alleinige Sicherheitsmaßnahme nicht mehr aus. Unternehmen müssen Segmentierung dynamisch und identitätsbasiert umsetzen. Heute zählt nicht mehr, an welchem Port sich ein Gerät verbindet, sondern wer oder was die Verbindung aufbaut.

Moderne Campus-Designs stellen daher zunehmend die Identität ins Zentrum und gestalten Netzwerke so, dass sie Richtlinien nicht mehr an Ports oder VLAN-IDs knüpfen, sondern an Benutzer:innen, Geräteprofile und Kontextinformationen.

Genau an diesem Punkt setzt 802.1X an, als Kontrollmechanismus, der Sicherheit direkt am Zugangspunkt beginnt und klassische Netzwerke um eine entscheidende Dimension erweitert.

802.1X: Kontrolle am Einstiegspunkt

Wenn VLANs allein nicht mehr ausreichen, stellt sich die Frage: Wie können wir sicherstellen, dass nur berechtigte Geräte und Personen ins Netzwerk gelangen? Ein Großteil dieser Antwort findet sich in Technologien rund um IEEE 802.1X. Der Standard 802.1X definiert einen Mechanismus zur Port-basierten Zugangskontrolle. Vereinfacht gesagt: Bevor ein Endgerät (Supplicant) Daten über einen Switchport oder einen WLAN-Access Point senden darf, muss es sich gegenüber dem Netzwerk authentifizieren. Erst nach einer erfolgreichen Authentifizierung gibt der Switch den Port frei – oder der Switch leitet das Gerät kontrolliert in ein Gäste- oder Quarantäne-VLAN weiter.

Dies funktioniert dabei sowohl im kabelgebundenen LAN als auch im WLAN. Im LAN wird EAP über EAPoL (EAP over LAN) zwischen Endgerät und Switch transportiert. Im WLAN dagegen ist 802.1X Teil von WPA2-Enterprise und WPA3-Enterprise: Hier läuft die Authentifizierung zwischen Client und Access Point ab, bevor der Datenverkehr ins Funknetz gelangt. Das Prinzip ist identisch – der Zugang bleibt solange gesperrt, bis der Authenticator den Authentifizierungsprozess erfolgreich abgeschlossen hat.

Eine eingängige Analogie beschreibt 802.1X als eine Art Türsteher im Club:

• Der Supplicant ist der Gast, der hinein möchte
• Der Authenticator ist der Türsteher, der den Ausweis kontrolliert
• Der Authentication Server ist die zentrale Instanz im Hintergrund, die prüft, ob der Ausweis gültig ist und welche Zugangsrechte bestehen

Nur wer sich eindeutig ausweisen kann, darf hinein – und das auch nur in den Bereich, der seiner Rolle entspricht.

Rollen im 802.1X-Modell

Damit 802.1X in der Praxis funktioniert, übernehmen verschiedene Komponenten klar definierte Rollen. Am Anfang steht der Supplicant, also das Endgerät, das sich anmelden möchte. In der täglichen Arbeit kann das ein Windows-Notebook sein, das sich beim Start automatisch am Netzwerk anmeldet, ein Smartphone, das sich mit dem Firmen-WLAN verbindet, oder ein IoT-Gerät wie eine Kamera oder Zutrittskontrolle.

Dem gegenüber steht der Authenticator, typischerweise ein Switch oder ein Access Point. Er kontrolliert den Zugang, indem er zunächst alle Datenpakete blockiert und nur Authentifizierungsinformationen zum Server weiterleitet. Erst nach einer erfolgreichen Prüfung gibt er den Port frei oder ordnet das Gerät einer bestimmten Richtlinie zu.

Die endgültige Entscheidung liegt beim Authentication Server. In Unternehmensnetzen übernimmt diese Funktion meist ein RADIUS-Server, häufig Cisco ISE oder Microsoft NPS. Er prüft Anmeldedaten, Zertifikate oder Geräteattribute und sendet dem Authenticator die entsprechenden Anweisungen zurück, beispielsweise in Form von VLAN-Zuweisungen oder dynamischen Access Control Lists.

In modernen Betriebssystemen wie Windows, macOS oder Linux ist der Supplicant bereits integriert. Administrator:innen können über Gruppenrichtlinien oder Intune festlegen, welche EAP-Methode, etwa PEAP oder EAP-TLS, das Gerät verwendet. In BYOD-Szenarien oder bei älteren Geräten kann es jedoch zu Einschränkungen kommen. Intel dokumentiert beispielsweise, dass manche Legacy-WLAN-Adapter lediglich einfache Methoden wie PEAP oder EAP-MD5 unterstützen, aber EAP-TLS nicht ausführen können. Für Unternehmen bedeutet das: entweder Workarounds wie MAB einsetzen oder alte Hardware konsequent ablösen.

Historische Einordnung und Standardisierung

Die IEEE standardisierte 802.1X erstmals im Jahr 2001, aktualisierte diesen in den Jahren 2004 und 2010 durch weitere Revisionen, die u.a. Verbesserungen bei EAP, Key Management und die Unterstützung für MACsec einführten. Heute gilt 802.1X als Grundlage für jede moderne Implementierung von Network Access Control.

Die Weiterentwicklung des Standards erfolgt kontinuierlich in der IEEE 802.1 Security Task Group, die auch angrenzende Themen wie MACsec (802.1AE) und Secure Device Identity (802.1AR) verantwortet.

Von der Portnummer zur Identität

Der entscheidende Unterschied zu klassischen VLAN-Konzepten liegt darin, dass nicht mehr der physische Anschluss über die Zugehörigkeit entscheidet, sondern die Identität. Diese Identität kann ein Benutzerkonto, ein Zertifikat oder ein Geräteattribut sein.

Ein Vergleich verdeutlicht den Paradigmenwechsel:

• Früher galt: „Wer an Port 5 hängt, gehört automatisch zum VLAN Vertrieb.“
• Heute lautet das Prinzip: „Nur wer sich mit gültigen Anmeldedaten oder Zertifikaten authentifiziert, erhält Zugriff – und zwar dynamisch je nach Rolle oder Gerätetyp.“

Auf diese Weise wird 802.1X zur Grundlage moderner Netzwerksicherheit. Ohne erfolgreiche Authentifizierung bleibt der Port gesperrt und Administrator:innen können den Zugriff auf sensible Ressourcen granular steuern.

Wer tiefer in die Kommunikation auf Layer 2 eintauchen möchte, findet dazu Grundlagen in meinem Beitrag Warum jedes Bit seinen Weg braucht – Der Weg zur intelligenten Kommunikation. Dort erkläre ich, wie Switches Datenpakete behandeln und warum die Steuerung des Ports durch 802.1X so wirksam ist.

Cisco ISE als Policy-Engine

Die reine Authentifizierung ist nur der erste Schritt. Auch das BSI weist im IT-Grundschutz-Baustein NET.3.4 Network Access Control darauf hin, dass eine Network Access Control (NAC) Architektur nicht nur aus Technik besteht, sondern auch dokumentierte Prozesse für Betrieb, Notfall und Monitoring erfordert.

Damit Cisco ISE aus einem erfolgreichen Login eine nachvollziehbare und sichere Zugangsentscheidung ableiten kann, braucht es eine Instanz, die Richtlinien definiert und umsetzt. Genau hier kommt Cisco Identity Services Engine (ISE) ins Spiel. Cisco ISE übernimmt die Rolle des zentralen Policy Decision Point (PDP) in einer 802.1X-Umgebung. Es prüft die Anmeldedaten, bewertet Gerätemerkmale und weist dem Endgerät anschließend die passende Netzwerkrolle zu. Dabei geht es längst nicht mehr nur um „Zugang erlaubt oder verboten“, sondern um differenzierte Steuerung von Berechtigungen.

Funktionen und Möglichkeiten

Die Stärke von Cisco ISE liegt in seiner Flexibilität. Richtlinien können nicht nur auf Basis von Benutzer:innen-Konten erstellt werden, sondern auch abhängig von Gerätetyp, Standort oder Sicherheitsstatus. Typische Einsatzszenarien sind:

• Dynamische VLAN-Zuweisung: weist einem Switchport  je nach authentifiziertem Gerät unterschiedlichen VLANs zu
• Feingranulare Access Control Lists (ACLs): Bestimmte Geräte wie Drucker oder IoT-Sensoren dürfen zwar ins Netz, werden aber auf das Minimum an Kommunikationswegen beschränkt
• Quarantäne- und Remediation-VLANs: Geräte, die nicht den Sicherheitsrichtlinien entsprechen, werden isoliert und erhalten nur Zugriff auf Update- oder Remediation-Server
• Rollenbasierte Zugriffssteuerung: Mitarbeitende erhalten Zugriff auf interne Ressourcen, Gäste dagegen nur auf das Internet

Durch diese Mechanismen wird aus dem einfachen Authentifizierungsserver eine Policy-Engine, die das gesamte Netzwerk identitätsbasiert steuert. Best-Practice-Designs für Campus-Netze empfehlen, ISE immer redundant und skalierbar zu betreiben. Dazu gehören mehrere RADIUS-Server im Cluster, geografische Redundanz bei verteilten Standorten sowie die lückenlose Protokollierung über Syslog oder NetFlow.

Beispiel aus der Praxis

Ein konkretes Szenario verdeutlicht die Funktionsweise:

• Eine Mitarbeiterin meldet sich mit ihrem Domänen-Notebook am Switchport an. Cisco ISE erkennt anhand der Zertifikate und AD-Gruppenzugehörigkeit, dass es sich um ein firmeneigenes Gerät handelt, und weist es dem VLAN Mitarbeitende mit vollem Ressourcenzugriff zu.
• Ein Gast verbindet sein Notebook über denselben Port. Da er sich nur über ein Captive Portal mit Gast-Account authentifiziert, erhält er ausschließlich Internetzugang.
• Ein IoT-Sensor meldet sich per MAC-Authentifizierung. Cisco ISE weist ihn einem restriktiven VLAN zu, in dem nur die Kommunikation mit dem zentralen Monitoring erlaubt ist.

So wird aus einer einfachen Zugangskontrolle ein dynamisches, identitätsbasiertes Sicherheitsmodell, genau das, was moderne Netzwerke im Sinne von Zero Trust benötigen. In Verbindung mit Cisco DNA Center können KI-gestützte Funktionen wie Endpoint Analytics helfen, unbekannte Geräte automatisch zu klassifizieren. Damit wird die Policy-Engine noch präziser: Ein Drucker oder Sensor wird sofort erkannt und der passenden Richtlinie, ohne manuelle Eingriffe, zugeordnet.

Mehr als nur Zugang: Dynamische Zuweisung

802.1X in Kombination mit Cisco ISE bringt einen entscheidenden Vorteil: Der Switchport ist nicht länger starr an ein VLAN gebunden, sondern wird dynamisch je nach Identität und Gerätemerkmal konfiguriert. Damit können Administrator:innen die Sicherheitsarchitektur wesentlich feiner steuern und auf unterschiedliche Szenarien reagieren. Moderne Campus-Designs denken Identität von Beginn an mit – anstelle statischer Portkonfigurationen stehen heute automatisierte, identitätsbasierte Mechanismen im Vordergrund, die Richtlinien unabhängig vom Standort durchsetzen.

VLANs als flexible Ressourcenzuweisung

Ein klassisches Beispiel ist die VLAN-Zuweisung. Statt einem Port dauerhaft ein bestimmtes VLAN zuzuordnen, entscheidet Cisco ISE anhand der Authentifizierung, welches VLAN zugewiesen wird.

• Mitarbeitende landen in einem produktiven VLAN mit Zugriff auf interne Systeme
• Gäste werden automatisch in ein separates VLAN mit Internet-only-Zugang verschoben
• IoT-Geräte wie Kameras oder Zutrittskontrollen erhalten ein dediziertes VLAN, das sie von sensiblen Bereichen abschottet

So können Netzwerksegmente auf einer höheren Ebene nach Rollen und Risiken strukturiert werden, ohne dass physische Portkonfigurationen angepasst werden müssen. Das BSI empfiehlt in Umgebungen mit erhöhtem Schutzbedarf, VLANs nicht nur zur Segmentierung zu nutzen, sondern ergänzend auf Mikrosegmentierung und identitätsbasierte Regeln zu setzen. Nur so lässt sich eine feinere Trennung nach Rollen und Sicherheitsanforderungen erreichen.

Access Control Lists für feingranulare Steuerung

Neben VLANs spielen auch Access Control Lists (ACLs) eine zentrale Rolle. Sie ermöglichen es, den Datenverkehr noch genauer zu regulieren:

• Ein Drucker darf beispielsweise nur mit dem Printserver kommunizieren, nicht aber mit beliebigen Endgeräten im gleichen VLAN
• Ein IoT-Sensor erhält Zugriff ausschließlich auf den Monitoring-Server, während alle anderen Verbindungen blockiert werden
• Externe Geräte können streng auf definierte Services wie HTTP oder HTTPS limitiert werden

Diese Kombination aus VLANs und ACLs schafft ein mehrschichtiges Sicherheitsmodell, das nicht mehr am Port endet, sondern bis auf die Ebene der einzelnen Anwendung greift. Cisco erweitert diesen Ansatz durch KI-gestützte Funktionen wie Endpoint Analytics in DNA Center. Unbekannte oder neue Geräte werden automatisch erkannt, klassifiziert und der passenden Richtlinie zugeordnet. Damit wird die Zuweisung noch dynamischer und reduziert den manuellen Aufwand für Administrator:innen erheblich.

Rollenbasierte Richtlinien als Brücke zu Zero Trust

Die dynamische Zuweisung nach Identität und Rolle ist ein entscheidender Schritt in Richtung Zero Trust. Statt nur auf Netzwerksegmentierung zu setzen, geht es darum, jeder Verbindung genau die Berechtigungen zu geben, die notwendig sind, nicht mehr und nicht weniger.

Somit ist 802.1X mehr als ein Türsteher am Switchport. In Kombination mit Policy-Engines wie Cisco ISE verwandelt es das Netzwerk in eine flexible, identitätsbasierte Sicherheitsplattform, die sich an die Realität moderner IT-Landschaften anpasst. Zunehmend setzen Unternehmen dabei auf KI-gestützte Netzwerküberwachung, die Anomalien erkennt und automatisch reagieren kann. Studien zeigen, dass sich damit sowohl Zero-Day-Angriffe schneller identifizieren als auch Zugriffsrichtlinien adaptiv anpassen lassen, ein Schritt hin zu autonomen Sicherheitsarchitekturen.

Keine Angst vor Zertifikaten

Wer 802.1X mit EAP-TLS einsetzt, kommt an Zertifikaten nicht vorbei. Sie sind der Schlüssel für eine starke, kennwortlose Authentifizierung und verknüpfen Benutzer:innen und Geräte eindeutig mit der Infrastruktur. Während Kennwörter abhörbar oder wiederverwendbar sind, lassen sich Zertifikate kryptografisch absichern und zentral verwalten. Deshalb gilt EAP-TLS mit Zertifikaten als Goldstandard für sichere Unternehmensnetze.

Aufbau einer Zertifizierungsinfrastruktur (PKI)

Zertifizierungsstellen lassen sich in verschiedenen Betriebsmodellen umsetzen. In Microsoft-zentrierten Umgebungen spielt die Unterscheidung zwischen Stand-Alone-CA und Enterprise-CA eine wichtige Rolle.

Eine Stand-Alone-CA, oder eigenständige Zertifizierungsstelle, ist losgelöst von Active Directory und eignet sich deshalb für Szenarien, in denen keine Windows-Domäne vorhanden ist. Auch hier sind Automatisierungsmechanismen verfügbar, zum Beispiel über Skripte, Konfigurationsmanagement-Tools oder ACME-Protokolle. Stand-Alone bedeutet also nicht zwangsläufig manuell, sondern vielmehr unabhängig von Active Directory.

Die Microsoft Enterprise-CA, auch Unternehmens-Zertifizierungsstelle, integriert sich dagegen direkt in Active Directory. Sie ermöglicht die automatische Zertifikatsverteilung an Domänen-Clients über Gruppenrichtlinien oder Intune und ist deshalb für große Windows-Umgebungen die bevorzugte Wahl.

Auch außerhalb der Windows-Welt sind Zertifikate fester Bestandteil sicherer Infrastrukturen. In Linux- und Open-Source-Umgebungen werden prinzipbedingt meist Stand-Alone-CAs eingesetzt, die unabhängig von Active Directory arbeiten. Die Automatisierung erfolgt hier auf andere Weise, nicht über Gruppenrichtlinien, sondern über flexible Tools und Standards.

Typische Beispiele sind:

• ACME-Protokoll (z.B. mit Let’s Encrypt): Ermöglicht die automatische Ausstellung und Verlängerung von Zertifikaten für Server und Dienste
• cert-manager für Kubernetes: Automatisiert die Bereitstellung und Erneuerung von TLS-Zertifikaten in Cloud-nativen Umgebungen
• HashiCorp Vault: Eine Plattform, die Zertifikate dynamisch ausstellen und mit definierten Laufzeiten automatisch erneuern kann
• Konfigurationsmanagement-Tools wie Ansible oder Puppet: Sie binden PKI-Workflows in bestehende Automatisierungsprozesse ein und verteilen Zertifikate an Server und Clients

Damit wird deutlich: Auch in reinen Linux- oder Cloud-Umgebungen muss Zertifikatsmanagement nicht manuell ablaufen. Im Gegenteil – mit den richtigen Werkzeugen lassen sich Zertifikate dort oft sogar noch dynamischer und flexibler verwalten als in klassischen Windows-Domänen.

Hierarchische PKI-Strukturen

Als Best Practice für mittlere und große Unternehmen hat sich eine hierarchische Struktur bewährt. In diesem Modell dient eine Stamm- oder Root-CA als Vertrauensanker, die in der Regel offline betrieben wird. Eine oder mehrere untergeordnete Sub-CAs übernehmen die operative Ausstellung von Zertifikaten und sind für den Tagesbetrieb verantwortlich.

Diese Trennung erhöht die Sicherheit erheblich: Die Root-CA ist nicht exponiert und kann nur dann aktiviert werden, wenn neue Sub-CAs signiert oder Sperrlisten erstellt werden müssen. Dieses Konstrukt wird als Offline Root-CA bezeichnet. Sub-CAs dagegen arbeiten online, können redundant ausgelegt und bei Bedarf auch als virtuelle Maschinen betrieben werden. Damit lassen sich sowohl Sicherheit als auch Verfügbarkeit in Einklang bringen.

Interne vs. externe Zertifikate

Unternehmen müssen sich auch entscheiden, ob sie interne oder externe Zertifikate verwenden. Eine interne CA bietet volle Kontrolle, erlaubt Automatisierung und verursacht keine laufenden Lizenzkosten. Allerdings müssen Geräte außerhalb der Domäne das Root-Zertifikat manuell oder über ein MDM importieren, damit sie der internen PKI vertrauen.

Externe Zertifikate von öffentlichen Zertifizierungsstellen wie DigiCert oder Sectigo genießen dagegen auf nahezu allen Plattformen Vertrauen. Sie sind allerdings kostenpflichtig und erlauben keine automatisierte Verteilung an interne Geräte. In der Praxis nutzen viele Organisationen deshalb eine Kombination: interne Zertifikate für Benutzer:innen und Geräte, externe Zertifikate für öffentlich erreichbare Dienste wie VPN-Portale oder Webserver.

Betriebsformen: Offline-CA und virtuelle Umgebung

Ein besonders wichtiger Aspekt ist die Absicherung der Root-CA. Sie sollte grundsätzlich offline betrieben werden und nur dann gestartet werden, wenn Sub-CAs neue Zertifikate benötigen oder Sperrlisten aktualisiert werden müssen. Auf diese Weise wird das Risiko minimiert, dass eine Kompromittierung der Root-CA die gesamte PKI gefährdet.

Auch die Betriebsumgebung spielt eine Rolle. Heute laufen viele Sub-CAs in virtuellen Maschinen, was Flexibilität und Snapshot-Funktionalität bietet. Für Root-CAs bevorzugen Unternehmen häufig physische Hardware, um das höchste Sicherheitsniveau zu erreichen. Alternativ können Root- und Sub-CAs in separaten virtuellen Umgebungen betrieben werden, entscheidend ist in jedem Fall eine strikte Trennung und Absicherung.

Typische Stolperfallen

Häufige Fehler entstehen durch abgelaufene CA-Zertifikate, die im schlimmsten Fall ganze Unternehmensumgebungen lahmlegen. Ein weiteres Risiko sind nicht erreichbare Certificate Revocation Lists (CRLs) oder OCSP-Responder.

Eine CRL ist eine von der CA veröffentlichte Liste mit gesperrten Zertifikaten. Clients prüfen bei der Anmeldung, ob das präsentierte Zertifikat auf dieser Liste steht. Das Online Certificate Status Protocol (OCSP) verfolgt denselben Zweck, allerdings in Echtzeit: Statt eine komplette Liste herunterzuladen, fragt der Client gezielt beim OCSP-Server nach, ob ein bestimmtes Zertifikat noch gültig ist. Diese Informationen finden sich unveränderlich im ausgestellten Zertifikat und müssen mit den real erreichbaren Informationsquellen übereinstimmen. Dies muss insbesondere bei Konfigurationsänderungen der Zertifikatsinfrastruktur beachtet werden.

Sind CRL oder OCSP nicht erreichbar, können Endgeräte Zertifikate nicht validieren und die Authentifizierung schlägt fehl. Ebenso problematisch ist eine fehlende Automatisierung in der Verteilung, etwa bei BYOD-Geräten ohne MDM-Anbindung. Das erzeugt hohen Supportaufwand und öffnet Sicherheitslücken.

Praxisempfehlungen

Unternehmen sollten möglichst auf eine Enterprise CA mit Auto-Enrollment für Domänen-Clients setzen und BYOD-Geräte über ein MDM-System wie Intune automatisiert mit Zertifikaten ausstatten. Für öffentlich erreichbare Dienste ist ein Hybrid-Ansatz sinnvoll, bei dem externe Zertifikate genutzt werden, während Geräte- und Benutzerzertifikate intern ausgestellt werden. Die Root-CA sollte konsequent offline gehalten werden, während Sub-CAs den laufenden Betrieb übernehmen. Außerdem empfiehlt sich ein regelmäßiger CA-Health-Check: Zertifikatslaufzeiten müssen überwacht, CRL- und OCSP-Server geprüft und Prozesse für die Sperrung oder Erneuerung von Zertifikaten dokumentiert werden.

Ein Beispiel verdeutlicht den Praxisansatz: Ein Unternehmen betreibt eine Microsoft Enterprise Root-CA offline auf physischer Hardware. Zwei Sub-CAs laufen als virtuelle Maschinen an unterschiedlichen Standorten. Windows-Clients erhalten ihre Zertifikate automatisch per Gruppenrichtlinie, mobile Endgeräte über Intune. Für das externe VPN-Portal wird ein Zertifikat einer öffentlichen Zertifizierungsstelle genutzt.

Fazit

Eine Public Key Infrastructure ist kein Hexenwerk, doch sie verlangt eine saubere Planung, eine verlässliche Implementierung und kontinuierliche Überwachung. Wer Zertifikate strukturiert einführt, die Hierarchie sinnvoll aufbaut und Prozesse für Erneuerung und Sperrung etabliert, erhält eine stabile Grundlage für 802.1X und Zero Trust – und nimmt dem oft gefürchteten Thema PKI den Schrecken.

Herausforderungen in der Praxis

So überzeugend 802.1X und Zero Trust in der Theorie klingen, in realen Netzwerken gibt es zahlreiche Stolperfallen. Unterschiedliche Gerätetypen, organisatorische Rahmenbedingungen und technische Altlasten machen die Umsetzung oft komplexer, als es auf dem Papier aussieht. Das BSI weist darauf hin, dass eine unzureichende Planung oder fehlende Notfallstrategien zu gravierenden Problemen führen können, etwa wenn zentrale NAC-Komponenten ausfallen oder unsichere Protokolle zum Einsatz kommen. In diesem Abschnitt werfen wir einen Blick auf typische Herausforderungen, mit denen Administrator:innen bei der Einführung von 802.1X regelmäßig konfrontiert werden.

Umgang mit Legacy-Devices

Nicht jedes Gerät im Unternehmensnetzwerk spricht 802.1X. Alte Drucker, IoT-Sensoren oder industrielle Steuerungen verfügen oft über keinen Supplicant. In solchen Fällen greifen Administrator:innen meist auf MAC Authentication Bypass (MAB) zurück. Dabei wird die MAC-Adresse wie ein Kennwort verwendet. Das ist praktisch, aber unsicher, denn MAC-Adressen lassen sich leicht fälschen. Deshalb gilt: MAB nur als Übergangslösung nutzen und die Geräte so restriktiv wie möglich über dynamische ACLs absichern. Ein weiteres Problem: Auch viele ältere WLAN-Adapter beherrschen nur einfache oder unsichere EAP-Methoden. Intel dokumentiert beispielsweise, dass Legacy-Produkte häufig lediglich PEAP oder gar EAP-MD5 unterstützen. Für Unternehmen bedeutet das ein Sicherheitsrisiko, da Passwörter abgegriffen oder Angriffe per Replay durchgeführt werden können.

Praxisempfehlung: Wer solche Geräte noch einsetzen muss, sollte sie konsequent in abgeschottete VLANs oder SGT-Zonen verschieben, den Datenverkehr mit restriktiven dACLs begrenzen und mittelfristig einen Austausch der Hardware einplanen.

Beispiel: Ein älterer Netzwerkkopierer ohne 802.1X-Support erhält per MAB Zugriff, darf aber ausschließlich mit dem Druckserver kommunizieren. Ein Legacy-WLAN-Adapter, der nur PEAP unterstützt, wird isoliert in einem Gäste-VLAN betrieben, bis er ersetzt werden kann.

BYOD und private Endgeräte

Bring Your Own Device (BYOD) ist in vielen Unternehmen Realität. Mitarbeiter:innen möchten mit eigenen Smartphones oder Tablets ins Netz. Diese Geräte lassen sich jedoch nicht ohne Weiteres in eine bestehende PKI-Struktur integrieren. Häufig greifen Unternehmen daher auf Captive Portals mit Web-Authentifizierung zurück oder setzen Mobile-Device-Management-Lösungen (MDM) ein, die Compliance-Checks ermöglichen und Zertifikate ausrollen.

Ein typisches Stolperstein-Szenario ergibt sich bei Windows-Clients: Standardmäßig nutzen viele Systeme PEAP mit Benutzername und Passwort. Microsoft weist jedoch darauf hin, dass dies zwar einfach einzurichten, aber sicherheitstechnisch deutlich schwächer ist als EAP-TLS mit Zertifikaten. Ohne PKI entsteht so ein unnötiges Risiko durch mögliche Passwort-Angriffe.

Praxisempfehlung: Für BYOD sollten klare Richtlinien definiert werden. Private Geräte können Internetzugang über Captive Portals erhalten, während der Zugriff auf Unternehmensressourcen an Bedingungen wie eine MDM-Registrierung oder die Ausstellung eines Gerätezertifikats geknüpft wird.

Beispiel: Ein Mitarbeiter bringt sein eigenes Tablet mit. Über das Captive Portal erhält er Zugangsdaten, die ausschließlich Internetzugriff erlauben. Soll das Gerät auch auf Unternehmensdaten zugreifen, muss es zunächst im MDM registriert werden, das automatisch ein Zertifikat für EAP-TLS bereitstellt.

Zertifikatsverteilung und PKI

Ein häufig unterschätzter Aspekt von 802.1X ist der Betrieb einer Public Key Infrastructure (PKI). Besonders beim Einsatz von EAP-TLS hängt die gesamte Authentifizierung davon ab, dass Zertifikate zuverlässig verteilt, erneuert und gesperrt werden können. Ohne ein sauberes Auto-Enrollment und ein funktionierendes Lifecycle-Management drohen Authentifizierungsfehler und hoher Supportaufwand.

Das BSI weist im IT-Grundschutz-Baustein NET.3.4 Network Access Control darauf hin, dass Fehler in der Zertifikatsverwaltung eine wesentliche Gefährdung darstellen. Typische Risiken sind:

• Abgelaufene Root- oder Intermediate-Zertifikate: Wenn eine Root-CA ihr Ablaufdatum erreicht, verlieren alle ausgestellten Zertifikate ihre Gültigkeit
• Fehlende Erreichbarkeit der Sperrlisten (CRL/OCSP): Können Clients die Gültigkeit eines Zertifikats nicht prüfen, schlagen Authentifizierungen fehl
• Fehler beim Auto-Enrollment: Werden Gruppenrichtlinien oder Intune-Profile nicht korrekt ausgerollt, erhalten Clients kein neues Zertifikat und verlieren beim Ablauf des alten den Zugang

Praxisempfehlung: Vor der Einführung von EAP-TLS sollte immer ein CA-Health-Check erfolgen. Dazu gehören die Dokumentation der Gültigkeitszeiträume, die Überwachung von CRL- und OCSP-Servern sowie definierte Prozesse für die Erneuerung und Sperrung von Zertifikaten.

Beispiel: Ein Notebook verliert den Zugriff aufs Netz, weil sein Zertifikat abgelaufen ist. Mit automatischer Erneuerung über Gruppenrichtlinien oder Intune wäre dieses Problem gar nicht entstanden.

MACsec und physische Sicherheit

Selbst wenn 802.1X die Authentifizierung am Port sicherstellt, bleibt der Datenverkehr auf Layer 2 anfällig für Angriffe wie Sniffing oder Manipulation. MACsec (Media Access Control Security) verschlüsselt Frames direkt auf der Verbindung zwischen Endgerät und Switch und schützt zusätzlich deren Integrität. Damit sind klassische Man-in-the-Middle-Angriffe auf Kabelverbindungen praktisch ausgeschlossen.

Das BSI empfiehlt den Einsatz von MACsec insbesondere in Umgebungen mit erhöhtem Schutzbedarf, etwa in Behörden, Forschungseinrichtungen oder kritischen Infrastrukturen. Voraussetzung ist, dass sowohl die Netzwerkkarte des Endgeräts als auch die Switch-Hardware MACsec unterstützen, was meist auf Enterprise-Switches wie den Cisco Catalyst 9000 Serien der Fall ist.

Praxisempfehlung: MACsec dort aktivieren, wo besonders vertrauliche Daten übertragen werden oder ein erhöhtes Risiko physischer Angriffe auf Netzwerkverbindungen besteht.

Beispiel: In einer Entwicklungsabteilung mit hochsensiblen Projektdaten setzt das Unternehmen MACsec zwischen allen Clients und Access Switches ein. Selbst wenn jemand unbemerkt einen Packet Sniffer anstöpselt, bleibt der Datenverkehr geschützt.

Rollout und Change Management

Die größte Hürde bei der Einführung von 802.1X ist oft nicht die Technik, sondern der Betrieb. Ein Big Bang Rollout führt schnell zu massiven Störungen, wenn nicht alle Endgeräte oder Richtlinien sauber vorbereitet sind. Cisco empfiehlt daher, Schritt für Schritt vorzugehen:

1. Monitor Mode: Zunächst wird 802.1X nur überwacht, nicht erzwungen. So lässt sich erfassen, welche Geräte sich erfolgreich authentifizieren und wo Probleme auftreten.
2. Low-Impact Mode: In der nächsten Phase dürfen Geräte zwar grundlegende Protokolle wie DHCP oder DNS nutzen, alle anderen Zugriffe sind jedoch blockiert, bis die Authentifizierung abgeschlossen ist. Das senkt das Risiko von Betriebsausfällen.
3. Enforcement Mode: Erst nach erfolgreicher Pilotierung in ausgewählten Abteilungen erfolgt die vollständige Erzwingung der Authentifizierung im gesamten Netzwerk.

Wichtig ist eine lückenlose Protokollierung und Auswertung. Syslog, RADIUS-Accounting und zentrale Dashboards wie in Cisco ISE oder DNA Center helfen, fehlerhafte Konfigurationen und nicht konforme Geräte frühzeitig zu erkennen.

Praxisempfehlung: Den Rollout mit einer gut vorbereiteten Pilotgruppe starten – häufig die IT-Abteilung selbst – und anschließend schrittweise auf weitere Bereiche ausweiten.

Beispiel: Ein Unternehmen beginnt mit 802.1X im Monitor Mode für die IT-Abteilung. Nach einer Testphase wird in Low-Impact Mode gewechselt, bevor die Erzwingung im Enforcement Mode für alle Abteilungen aktiviert wird.

Fazit: Sicherheit beginnt am Port – aber endet nicht dort

Nach den technischen Details und Praxisbeispielen lohnt sich der Blick auf das Gesamtbild. 802.1X ist ein starker Baustein, aber nicht die alleinige Antwort auf alle Sicherheitsfragen. Das Zusammenspiel aus Zugangskontrolle, Zero-Trust-Strategie, KI-gestützten Mechanismen und klaren organisatorischen Prozessen entscheidet darüber, ob ein Netzwerk tatsächlich resilient gegenüber modernen Bedrohungen ist.

802.1X als Fundament moderner Netzwerksicherheit

Mit 802.1X steht ein bewährter Standard zur Verfügung, der den Netzwerkzugang zuverlässig kontrolliert. In Kombination mit Cisco ISE lässt sich nicht nur steuern, wer ins Netzwerk darf, sondern auch mit welchen Rechten. Dynamische VLANs, dACLs und SGTs machen aus einer simplen Portfreigabe eine fein abgestufte, identitätsbasierte Steuerung.

Zero Trust als übergeordnete Strategie

Zero Trust bedeutet, jede Verbindung kontinuierlich zu prüfen, vom Port bis zur Applikation. Cisco beschreibt diesen Ansatz entlang der drei Säulen Identity, Access und Response. 802.1X bildet den Einstiegspunkt, ist aber nur ein Teil einer ganzheitlichen Sicherheitsarchitektur. Ergänzende Mechanismen wie Mikrosegmentierung, Posture-Checks und kontinuierliches Monitoring sind notwendig, um Angriffe nachhaltig zu erschweren.

Ein tieferer Einblick in Zero-Trust-Strategien auf Plattformebene findet sich im Beitrag Microsoft 365 Security und Compliance im Fokus.

Herausforderungen und Chancen

Die Einführung ist in der Praxis komplex: Legacy-Devices, BYOD, Zertifikatsverwaltung und Betriebsprozesse erfordern sorgfältige Planung. Das BSI empfiehlt daher, NAC-Konzepte nicht nur technisch, sondern auch organisatorisch sauber abzusichern – inklusive Notfallmaßnahmen, Monitoring und regelmäßiger Überprüfung. Gleichzeitig bieten die Technologien enorme Vorteile: höhere Transparenz, verbesserte Sicherheit und die Möglichkeit, Richtlinien zentral und konsistent umzusetzen.

Ausblick

Die Zukunft von NAC und Zero Trust wird stark von KI geprägt sein. Cisco DNA Center, Microsoft Sentinel oder Akamai-Lösungen zeigen bereits heute, wie KI Endgeräte klassifiziert, Anomalien erkennt und automatisiert reagiert. Palo Alto nennt für 2025 Identity-first Security und KI-getriebene Detection als zentrale Trends. McKinsey mahnt jedoch, dass KI-Systeme selbst abgesichert werden müssen, um Manipulationen oder Intransparenz zu vermeiden.

Fazit: Sicherheit beginnt am Port, aber endet nicht dort. 802.1X und NAC schaffen das Fundament, Zero Trust liefert den Rahmen, und KI wird in den kommenden Jahren zur treibenden Kraft. Entscheidend bleibt, Technik und Prozesse zusammenzudenken – nur dann wird das Netzwerk wirklich resilient.

Quellenangabe

(Abgerufen am 20.09.2025)

Standards und Grundlagen

• BSI: IT-Grundschutz-Kompendium – NET.3.4 Network Access Control (2023)
• IEEE 802.1 Security Task Group: Security
• IEEE: IEEE 802.1X Standard

Cisco (Technologie, Design und Zero Trust)

• Cisco DNA Center: Endpoint Analytics
• Cisco: 1X Deployment Guide – TrustSec
• Cisco: Cisco Campus 802.1X Design Guide (2014, PDF)
• Cisco: Cisco Zero Trust Solutions
• Cisco: Configure ACS for 802.1X
• Cisco: Configure Global 802.1X Properties on a Switch
• Cisco: Configuring MAC Authentication Bypass (MAB) in Cisco ISE

Microsoft (Supplicant, PKI, AI & Security)

• Microsoft Learn: Extensible Authentication Protocol (EAP) in Windows
• Microsoft Security: What is AI for Cybersecurity?

Weitere Fachquellen (EAP, NAC, Security Trends)

• AIMultiple: AI for Network Security – Use Cases
• Akamai: AI Flexes Network Security Muscles
• Bradford Networks: 802.1X and NAC – Best Practices for Effective Network Access Control (2013, PDF)
• Faddom: AI in Network Security – Use Cases, Challenges and Best Practices
• Intel: Intel Wireless Products – EAP Support Overview
• JumpCloud: EAP Types – Best Practices
• McKinsey: The cybersecurity provider’s next opportunity: making AI safer
• Medium: Modern Enterprise Campus Design
• Network Computing: Crash Course 802.1X – The Great Authenticator
• Palo Alto Networks: 8 Trends in Network Security 2025
• ResearchGate: The Role of Artificial Intelligence in Enhancing Network Security – Opportunities and Challenges (2023, PDF)

Weiterlesen hier im Blog

• Intelligente Agenten mit Copilot Studio – KI-gestützte Automatisierung im Microsoft-Ökosystem
• Ganzheitliche Sicherheit in Microsoft 365: Von Defender for Office 365 bis Purview
• Von VLAN zu VXLAN – Segmentierung im Cisco-Netzwerk im Wandel der Zeit
• Warum jedes Bit seinen Weg braucht – Der Weg zur intelligenten Kommunikation
• Wenn Netzwerke sich selbst heilen – Cisco AI Canvas und AgenticOps