Secure network: certificates, identity and PasspointAuthentication
Migration von Mitarbeiter-WiFi von einem gemeinsam genutzten Passwort zu 802.1X über mehrere Standorte hinweg
Sie können die Migration des Mitarbeiter-WiFi von einem gemeinsam genutzten Passwort zu IEEE 802.1X an jedem Standort planen und ausführen - ohne ein einziges Umstellungs-Wochenende. Sie können Geräte nach EAP-TLS, Captive Portal-Onboarding oder gerätespezifischen Schlüsseln sortieren und anschließend den gemeinsam...
15 min read

Betreiben Sie eine neue WPA-Enterprise SSID parallel zur SSID mit gemeinsam genutztem Passwort und migrieren Sie die Geräte schrittweise. Verwaltete Geräte erhalten EAP-TLS Zertifikate über Ihr MDM. Private Smartphones werden über ein Captive Portal registriert. Geräte, die kein Zertifikat speichern können, erhalten einen eigenen Schlüssel in einem xPSK Netzwerk. Schalten Sie das gemeinsam genutzte Passwort an jedem Standort ab, sobald das Authentifizierungsprotokoll keine Altgeräte mehr anzeigt.
Was ändert sich bei der Migration des Mitarbeiter WiFi von einem gemeinsam genutzten Passwort zu 802.1X?
Ein gemeinsam genutztes Mitarbeiterpasswort ist ein einziges Geheimnis, das jedem Kollegen, jedem Gerät und jedem ehemaligen Mitarbeiter bekannt ist. Wenn jemand das Unternehmen verlässt, behält er es. Eine Änderung bedeutet, den Schlüssel auf jeder Kasse, jedem Tablet und jedem Laptop an jedem Standort neu einzugeben.
PCI DSS v4.0.1 Anforderung 2.3.2 macht dies zur Pflicht. Sie gilt für drahtlose Umgebungen, die mit der Karteninhaber-Datenumgebung verbunden sind oder Kontodaten übertragen. Sie müssen drahtlose Verschlüsselungsschlüssel immer dann ändern, wenn jemand, der sie kennt, das Unternehmen oder die entsprechende Rolle verlässt. Sie müssen sie auch ändern, wenn der Verdacht besteht oder bekannt ist, dass ein Schlüssel kompromittiert wurde. In einem Unternehmen mit hoher Fluktuation bedeutet eine wörtliche Auslegung die Neukonfiguration in den meisten Wochen.
IEEE 802.1X eliminiert das gemeinsam genutzte Geheimnis. Es ist der Standard für portbasierte Netzwerkzugriffskontrolle. Ein Gerät muss seine Identität nachweisen, bevor der Access Point seinen Datenverkehr weiterleitet. Der Access Point fragt über RADIUS an - das Protokoll, das Netzwerkhardware zur Abfrage eines Authentifizierungsservers verwendet.
EAP-TLS (Extensible Authentication Protocol mit Transport Layer Security, RFC 5216) ist die sicherste Methode für die Antwort. Das Gerät und der Server weisen sich jeweils durch ein Zertifikat aus. Es gibt kein Passwort, das geteilt, gephisht oder an das Whiteboard im Büro geschrieben werden kann.
Die Identität bestimmt anschließend das VLAN (Virtual LAN, ein logisch getrenntes Netzwerksegment). RADIUS gibt unter Verwendung der in RFC 3580 definierten Tunnel-Attribute ein VLAN für jedes Gerät zurück. Ein Laptop aus der Finanzabteilung und ein Tablet aus der Küche können sich mit derselben SSID verbinden und in unterschiedlichen Segmenten landen.
Die Einordnung in Purple Access
Purple Access betreibt drei Netzwerke auf einer Plattform:
- Open: Ein Captive Portal, also die Webseite, die ein Gerät sieht, bevor es Netzwerkzugriff erhält. In dieser Migration dient es dem Onboarding privater Smartphones.
- Secure: EAP-TLS, Integration von Identitätsanbietern, Passpoint und Cloud-RADIUS. Laptops, Tablets und Smartphones der Mitarbeiter landen hier.
- xPSK: Ein einzelner Schlüssel für jedes Gerät, je nach Anbieter iPSK oder PPSK genannt. Jedes Gerät, das kein Zertifikat speichern kann, landet hier.
Gast-WiFi bleibt in einem eigenen Netzwerk und außerhalb dieses Projekts. Der Leitfaden Guest network security: A practical Guide for 2026 deckt diesen Bereich ab. DNS-Filtering in jedem dieser Netzwerke erfolgt über Shield. Für das Gesamtbild lesen Sie unseren Leitfaden zur WiFi security.
Anmeldedaten-Modelle im Vergleich
PEAP-MSCHAPv2 (Protected EAP mit einem Benutzernamen und Passwort) ist der übliche Kompromiss und gehört daher in den Vergleich.
| Anmeldedaten-Modell | Was jedes Gerät vorweist | Was ein ausscheidender Mitarbeiter mitnimmt | Widerruf einer einzelnen Person oder eines Geräts | Auswirkung auf PCI-DSS-2.3.2-Schlüsseländerungen | Geeignet für |
|---|---|---|---|---|---|
| Shared PSK | Ein Passwort für alle | Den Schlüssel für jeden Standort | Neukonfiguration des Schlüssels auf jedem Gerät der SSID | Der Schlüssel muss jedes Mal für alle geändert werden, wenn ein ausscheidender Mitarbeiter ihn kannte | Einen einzelnen kleinen Standort ohne Kartendaten über WiFi |
| PEAP-MSCHAPv2 | Persönlicher Benutzername und Passwort | Das eigene Passwort, bis das Konto deaktiviert wird | Deaktivieren des Kontos | Kein gemeinsamer Schlüssel, aber Passwörter können abgefangen werden, wenn Serverzertifikate nicht validiert werden | Umgebungen ohne bisherige Zertifikatsstelle |
| EAP-TLS | Ein Zertifikat pro Gerät oder Person | Nichts Verwendbares, sobald das Zertifikat widerrufen wurde | Widerruf des Zertifikats oder Deaktivierung der Identität | Kein gemeinsamer Schlüssel, der geändert werden müsste | Verwaltete Laptops, Tablets, Handhelds und eingebundene Smartphones |
| xPSK | Ein eindeutiger Schlüssel pro Gerät | Nur die Geräteschlüssel, die persönlich eingegeben wurden | Löschen des Schlüssels dieses Geräts | Ändern nur der Schlüssel, die der ausscheidende Mitarbeiter verwaltet hat | Kassen, Kartenterminals, Drucker, CCTV, digitale Beschilderung |
Was benötigen Sie, bevor Sie ein gemeinsames WiFi Passwort auf 802.1X migrieren?
Sie benötigen keine neuen Access Points. Purple Access ist hardwareunabhängig und läuft als Cloud Overlay auf Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks und Fortinet. Sie benötigen sechs Dinge vor dem Testbetrieb.
- Ein Geräteinventar pro Standort. Exportieren Sie die Client-Liste für die Mitarbeiter-SSID aus der Konsole jedes Standorts für mindestens 14 Tage. Sortieren Sie jedes Gerät in eine von drei Klassen. Verwaltete Geräte sind in Ihrer MDM (Mobile Device Management Plattform) registriert. Persönliche Geräte sind Smartphones im Besitz der Mitarbeiter. Headless-Geräte sind Kassen, Kartenterminals, Drucker, Kameras und alles andere ohne Zertifikatsspeicher.
- Ein Identitätsanbieter mit sauberen Gruppen. Verwenden Sie Microsoft Entra ID, Okta oder Google Workspace. Jede Gruppe, die ihr eigenes Segment benötigt, wird zu einer VLAN-Regel. Okta WiFi Authentication: Setup Steps, Options and Fixes führt Sie durch die Okta-Seite.
- Eine Zertifikatsstelle, bei der Ihr MDM anfragen kann. Microsoft Intune, Jamf Pro und die meisten anderen MDMs stellen Zertifikate über SCEP (Simple Certificate Enrollment Protocol) oder PKCS-Profile aus. Entscheiden Sie jetzt, ob ein Zertifikat das Gerät oder die Person identifiziert. Gemeinsam genutzte Tablets und Handhelds benötigen Gerätezertifikate.
- Ein VLAN-Plan für jeden Standort. Ein typischer Plan umfasst fünf Segmente: Mitarbeiter, verwaltete Unternehmensgeräte, Zahlungsgeräte, sonstige Headless-Geräte und ein eingeschränktes Altsystem-Segment. Bestätigen Sie, dass der Switch-Trunk zu jedem Access Point jedes VLAN überträgt.
- Purple Access als RADIUS-Server eingestellt für die sichere SSID. Wenn Ihr Anbieter RADIUS für schlüsselbasierte Gerätezugänge verwendet, weisen Sie das xPSK-Netzwerk ebenfalls darauf hin. Cloud-RADIUS bedeutet, dass an den Standorten nichts installiert, gepatcht oder geclustert werden muss.
- Ein benannter Verantwortlicher an jedem Standort. Sie benötigen jemanden, der unbekannte Geräte auf der Inventarliste identifizieren und die Abschaltung genehmigen kann.
Wie migrieren Sie Mitarbeiter WiFi zu 802.1X ohne ein Umstellungs-Wochenende?
Drei Prinzipien erübrigen das Umstellungs-Wochenende. Bauen Sie die neuen Netzwerke neben dem alten auf. Verschieben Sie Geräte nach Klasse, nicht nach Standort. Schalten Sie Standort für Standort ab, basierend auf den Daten des Authentifizierungsprotokolls.
Können Sie beide SSIDs während der Migration gleichzeitig betreiben?
Ja, und Sie sollten sie für das gesamte Projekt zusammen betreiben. Die eigentliche Frage betrifft die Sendezeit. Jede gesendete SSID fügt Beacon-Frames auf jedem Funkkanal hinzu, weshalb Design-Leitfäden der Hersteller - darunter auch die von Cisco Meraki - empfehlen, die Anzahl der SSIDs gering zu halten.
Die saubere Lösung besteht darin, die bestehende SSID in das xPSK-Netzwerk umzuwandeln. Behalten Sie den Namen und den Sicherheitsmodus bei. Fügt das alte gemeinsame Passwort als einen Schlüssel in die gerätespezifische Schlüsselliste ein, zugewiesen an das eingeschränkte bestehende VLAN. Geräte, die das alte Passwort kennen, verbinden sich wieder, ohne es zu merken. Jedes Gerät, das Sie verschieben, erhält seinen eigenen Schlüssel.
Wenn der bestehende Schlüssel an einem Standort für keine Geräte mehr verwendet wird, löschen Sie ihn. Das gemeinsame Passwort ist damit deaktiviert, und es ist nie eine neue SSID aufgetaucht. Ihr Endzustand sind drei SSIDs: Gäste, sichere Mitarbeiter und xPSK.
Testen Sie dies zuerst an einem Standort. Mehrere Hersteller führen gerätespezifische Schlüsselfunktionen auf WPA2-Personal statt auf WPA3-SAE aus, prüfen Sie daher die Dokumentation Ihres Herstellers. Wenn Ihre Plattform das alte Passwort nicht als einzelnen Schlüssel speichern kann, betreiben Sie während der Migration vier SSIDs und entfernen Sie die bestehende SSID bei der Abschaltung.
Phase 1: Einmal aufbauen, auf die gesamte Infrastruktur anwenden
Konfigurieren Sie die sichere SSID und das xPSK-Netzwerk einmal und wenden Sie diese dann über eine Vorlage auf jeden Standort an. Verwenden Sie WPA3-Enterprise, wo Ihre verwaltete Geräteflotte dies unterstützt, andernfalls einen WPA2/WPA3-Übergangsmodus.
| Hersteller | Konsole | Sichere SSID-Einstellung | Gerätespezifische Schlüsselfunktion | Standortübergreifend anwenden mit |
|---|---|---|---|---|
| Cisco Meraki | Meraki Dashboard | Enterprise mit meinem RADIUS-Server | Identity PSK (iPSK) | Konfigurationsvorlagen |
| HPE Aruba | Aruba Central | Enterprise-Sicherheitsstufe | MPSK | Gruppen |
| Ruckus | SmartZone oder RUCKUS One | 802.1X EAP-Authentifizierung | Dynamic PSK (DPSK) | Zonen oder Standorte |
| Juniper Mist | Mist-Portal | Enterprise (802.1X) WLAN-Sicherheit | Multi PSK | WLAN-Vorlagen |
| Ubiquiti UniFi | UniFi Network | WPA Enterprise mit einem RADIUS-Profil | Private Pre-Shared Keys | Standorteinstellungen pro Standort |
Bezeichnungen ändern sich zwischen Firmware-Versionen, folgen Sie daher der Dokumentation Ihres Herstellers für den aktuellen Pfad. Weitere Konfigurationsanleitungen finden Sie in unseren Access-Guides.
Phase 2: Pilotprojekt an zwei oder drei repräsentativen Standorten
Wählen Sie unterschiedliche Standorte: einen großen Standort, einen kleinen und einen mit einem ungewöhnlichen Switch-Modell. Führen Sie jede spätere Phase zuerst an diesen Standorten durchgehend aus. Das Pilotprojekt dient dazu, den Trunk zu finden, der kein VLAN überträgt, die Kasse, die nur WPA2 unterstützt, und das MDM-Profil, das in der falschen Reihenfolge installiert wird.
Phase 3: Zertifikate über das MDM auf verwaltete Geräte übertragen
Verwaltete Geräte lassen sich am schnellsten umstellen, da das MDM jeden Standort gleichzeitig erreicht. Bereitstellen von drei Profilen in dieser Reihenfolge: das vertrauenswürdige Stammzertifikat, das Gerätezertifikat und anschließend das WiFi-Profil. Die meisten MDMs schlagen beim WiFi-Profil fehl, wenn das darin referenzierte Zertifikat fehlt.
Das WiFi-Profil benennt die sichere SSID, legt EAP-TLS fest und verankert den Zertifikatsnamen sowie das Root des RADIUS-Servers. Sobald sich ein Gerät an der sicheren SSID authentifiziert hat, verteilen Sie ein Profil, das das Altsystem-Netzwerk entfernt. Andernfalls wechselt das Gerät möglicherweise wieder zur alten SSID zurück, der es bereits vertraut.
Phase 4: Personaleigene Smartphones auf dieselbe SSID umstellen
Mitarbeiter verbinden sich mit dem offenen Netzwerk, häufig durch Scannen eines QR-Codes im Backoffice. Sie melden sich im Captive Portal mit ihrer Arbeitsidentität an und erhalten das sichere Netzwerkprofil. Unser Leitfaden Captive Portals behandelt das Portal-Design.
Ein Passpoint (Hotspot 2.0)-Profil bringt einem mehrteiligen Standortnetzwerk den größten Nutzen. Passpoint ermöglicht es einem Smartphone, ein Netzwerk anhand seiner Anmeldedaten statt über den SSID-Namen zu finden und ihm beizutreten. Eine einmalige Onboarding-Prozedur funktioniert dann an jedem Standort. Weisen Sie persönliche Smartphones einem reinen Internet-Mitarbeiter-VLAN zu - getrennt von Zahlungs- und Backoffice-Segmenten. Führen Sie das Onboarding regionsweise durch, damit das Helpdesk ein gleichmäßiges Anfragenaufkommen verzeichnet und keine Auslastungsspitzen.
Phase 5: Jedes Gerät ohne Zertifikatsunterstützung auf einen eigenen Schlüssel umstellen
Weisen Sie jedem Headless-Gerät einen eindeutigen Schlüssel zu und ordnen Sie die Schlüssel nach Klasse den entsprechenden VLANs zu. Kartenterminals gehören in das Zahlungssegment und Kameras in das Kamera-Segment. Erfassen Sie das Gerät, die MAC-Adresse, den Standort, den Schlüssel und die Person, die die Eingabe vorgenommen hat.
Drucker und Kamera-Rekorder verfügen in der Regel über Web-Schnittstellen, die Sie aus der Ferne neu konfigurieren können. Kassen und Terminals erfordern möglicherweise die Verwaltungsplattform des Herstellers oder einen Einsatz vor Ort. PPSK for retail store devices: a deployment checklist for tills, scanners and CCTV on Cisco Meraki and Juniper Mist behandelt diese Phase im Detail.
Wie lange dauert eine standortübergreifende 802.1X-Einführung?
Betrachten Sie die folgenden Zeitangaben als Planungsannahmen für Ihren Pilotversuch, nicht als feste Maßstäbe. Headless-Geräte geben das Tempo vor, da sie die einzige Klasse sind, die möglicherweise Manpower vor Ort erfordert.
| Phase | Was passiert | Umfang | Geplante Dauer |
|---|---|---|---|
| 0. Vorbereitung | Inventar, Identitätsgruppen, VLAN-Plan, Zertifizierungsstelle | Gesamter Bestand, keine Geräteänderungen | 2-3 Wochen |
| 1. Aufbau | Sichere SSID und xPSK-Netzwerk in Vorlagen | Gesamter Bestand | 1 Woche |
| 2. Pilot | Jede Phase von Anfang bis Ende | 2-3 Standorte | 3-4 Wochen |
| 3. Verwaltete Geräte | MDM überträgt Zertifikate und WiFi-Profil | Alle Standorte auf einmal | 2 Wochen plus 2 Wochen für Nachzügler |
| 4. Persönliche Smartphones | Onboarding über das offene Netzwerk | 20-30 Standorte pro Welle | 2 Wochen pro Welle |
| 5. Headless-Geräte | Eindeutiger Schlüssel pro Gerät | Remote oder Einsatz vor Ort | Ein halber Tag pro Standort, parallel ausgeführt |
| 6. Abschaltung | Löschen des alten Schlüssels | Pro Standort | Mindestens 14 störungsfreie Tage pro Standort |
Die Phasen 3, 4 und 5 überschneiden sich. Auf dieser Grundlage sollten Sie mit 10 bis 14 Wochen für 50 Standorte und 20 bis 26 Wochen für 200 Standorte planen.
Praxisbeispiel: Eine Hotelgruppe mit 64 Hotels auf Cisco Meraki
Beispielhafte Zahlen. Jedes Hotel betrieb etwa 40 Geräte über einen gemeinsamen Mitarbeiter-Schlüssel. Das bedeutete 22 verwaltete Geräte, sechs private Smartphones und 12 kopflose Geräte (Headless Devices): Kartenterminals, Belegdrucker und Signage-Player. Das Reinigungspersonal von Agenturen kannte den Schlüssel, sodass jeder Agenturwechsel die PCI-DSS 2.3.2-Bedingung für ausscheidende Mitarbeiter auslöste.
Das Team wandelte die veraltete SSID in iPSK um und behielt das alte Passwort als einen Schlüssel in einem beschränkten VLAN bei. Sie erstellten die Enterprise-SSID in einer Konfigurationsvorlage. Intune spielte in der dritten Woche nach dem Pilotprojekt Zertifikate auf alle 1.408 verwalteten Geräte ein. Die diensthabenden Manager richteten 384 private Smartphones Region für Region ein. Ingenieure versahen die 768 kopflosen Geräte während geplanter Wartungsbesuche mit neuen Schlüsseln.
Ergebnis: In Woche neun wurden über den veralteten Schlüssel nur noch kopflose Geräte betrieben. Das letzte Hotel löschte ihn in Woche 16, ganz ohne nächtliche Umstellung. Das Ausscheiden eines Mitarbeiters bedeutet nun die Deaktivierung eines einzelnen Kontos, anstatt 2.560 Geräte in 64 Hotels neu zu verschlüsseln.
Praxisbeispiel: Ein Einzelhändler mit 180 Filialen auf Juniper Mist
Beispielhafte Zahlen. Jede Filiale betrieb 27 Geräte über den gemeinsamen Schlüssel: 12 Handscanner, drei Backoffice-PCs, vier Etikettendrucker, sechs Kameras und zwei Smartphones von Führungskräften. Die Neuerstellung von Schlüsseln nach dem Ausscheiden von Mitarbeitern war ins Stocken geraten, da niemand alle Filialen am selben Tag erreichen konnte.
Scanner und PCs wurden über das MDM auf EAP-TLS umgestellt, insgesamt 2.700 Geräte. Drucker und Kameras wechselten zu Multi PSK, wobei 1.800 eindeutige Schlüssel zwei VLANs zugeordnet wurden. Die Filialen wurden in sechs Wellen von jeweils 30 Standorten umgestellt. Das Pilotprojekt deckte ein Filialformat auf, dessen Switches das Kamera-VLAN nicht getaggt hatten. Das Team korrigierte die Vorlage vor der ersten Welle.
Ergebnis: Die Anzahl der veralteten Verbindungen pro Filiale sank bis Woche 22 in allen 180 Filialen auf null. Im gesamten Unternehmen existiert kein gemeinsamer Mitarbeiter-Schlüssel mehr.
Wie überprüfen Sie das Gelingen der Migration Standort für Standort?
Nachweis jeder Phase im Pilotprojekt
Führen Sie an jedem Pilotstandort vier Tests durch, bevor Sie skalieren:
- Verbindungstest: Ein neues verwaltetes Gerät, ein eingerichtetes Smartphone und eine neu verschlüsselte Kasse verbinden sich jeweils beim ersten Versuch.
- VLAN-Test: Jedes Gerät landet in dem Segment, das durch seine Identität oder seinen Schlüssel festgelegt werden soll.
- Roaming-Test: Ein Handheld behält seine Sitzung beim Wechsel zwischen Access Points bei.
- Ausscheidenden-Test: Deaktivieren Sie eine Testidentität, widerrufen Sie deren Zertifikat und bestätigen Sie, dass die nächste Authentifizierung verweigert wird.
Fortschritt pro Standort anhand des Authentifizierungsprotokolls messen
Berichten Sie wöchentlich drei Zahlen pro Standort aus dem Authentifizierungsprotokoll und der Client-Liste des Controllers:
- Geräte, die sich mit EAP-TLS auf der sicheren SSID authentifizieren.
- Geräte mit ihrem eigenen xPSK-Schlüssel.
- Geräte, die noch den veralteten Schlüssel verwenden.
Der Fortschritt entspricht den ersten beiden Werten geteilt durch alle eindeutigen Mitarbeitergeräte, die in den letzten 14 Tagen erkannt wurden. Sortieren Sie die Standorte nach der Anzahl veralteter Verbindungen und setzen Sie Ihre Ressourcen dort ein, wo die Anzahl am höchsten ist. Zählen Sie persönliche Smartphones nach Identität, nicht nach MAC-Adresse. iOS und Android randomisieren MAC-Adressen pro Netzwerk, sodass ein Smartphone wie zwei aussehen kann.
Wann schalten Sie das gemeinsame Passwort ab?
Löschen Sie den veralteten Schlüssel an einem Standort, wenn alle vier Bedingungen erfüllt sind:
- Die Anzahl veralteter Verbindungen liegt seit 14 aufeinanderfolgenden Tagen bei null, was zwei vollständige Schichtzyklen abdeckt.
- Jedes bildschirmlose Gerät im Inventar verfügt über einen eigenen Schlüssel.
- Die Helpdesk-Tickets für diesen Standort sind wieder auf das normale Niveau zurückgegangen.
- Die Standortleitung hat die Freigabe erteilt.
Halten Sie das Datum fest. Ab diesem Zeitpunkt existiert kein gemeinsamer Schlüssel mehr, den Sie gemäß 2.3.2 ändern müssten. Ihr Schlüsselregister und Ihr Authentifizierungsprotokoll dienen als Nachweis für die Anforderung. Wenn später ein übersehenes Gerät auftaucht, weisen Sie ihm einen eigenen Schlüssel zu. Stellen Sie den gemeinsamen Schlüssel niemals wieder her.
Was geht bei einer standortübergreifenden 802.1X Einführung schief und wie beheben Sie es?
Geräte wechseln zurück zur veralteten SSID
Geräte merken sich beide Netzwerke und bevorzugen möglicherweise das alte. Entfernen Sie das veraltete Netzwerk per MDM-Profil, sobald die sichere SSID funktioniert. Fügen Sie bei persönlichen Smartphones den Hinweis "Altes Netzwerk ignorieren" in die Onboarding-Anleitung ein.
Geräte verbinden sich ohne Servervalidierung
Ein WiFi Profil, das die Serverzertifikat-Validierung überspringt, vertraut einem gefälschten Access Point, der dieselbe SSID ausstrahlt. Verankern Sie das vertrauenswürdige Root-Zertifikat und den RADIUS-Servernamen in jedem Profil.
Clients authentifizieren sich, erhalten aber keine IP-Adresse
RADIUS hat ein VLAN zugewiesen, das der Switch-Trunk nicht überträgt. Überprüfen Sie die Trunks bei jedem Switch-Modell in der Testphase und korrigieren Sie die Vorlage, nicht den einzelnen Standort.
Windows Laptops schlagen bei PEAP fehl
Microsoft dokumentiert, dass Windows Defender Credential Guard das MSCHAPv2 Single Sign-On mit gespeicherten Anmeldedaten blockiert. Die Umstellung dieser Laptops auf EAP-TLS hebt die Abhängigkeit von Passwörtern auf.
Zertifikate laufen im gesamten Bestand gleichzeitig ab
Zertifikate, die in einem einzigen Schub ausgestellt wurden, laufen innerhalb derselben Woche ab. Richten Sie die automatische Verlängerung im MDM weit vor dem Ablaufdatum ein und staffeln Sie den ersten Schub, falls Ihre Zertifizierungsstelle dies zulässt.
Zu viele SSIDs verlangsamen jedes Netzwerk
Der gleichzeitige Betrieb von Guest-, Legacy-, Secure- und xPSK-SSIDs erzeugt Beacon-Overhead auf jedem Funkkanal. Wandeln Sie die veraltete SSID wie oben beschrieben in das xPSK-Netzwerk um, um die Anzahl bei drei zu halten.
Was kostet eine 802.1X Migration und was bringt sie ein?
Die Kosten betreffen Lizenzen und Arbeitsaufwand, nicht die Hardware. Sie zahlen für Purple Access sowie für MDM-Profilarbeiten, Standortbesuche für bildschirmlose Geräte und Helpdesk-Zeiten während der Onboarding-Wellen. Access Points, Switches und Controller bleiben unverändert.
Der Ertrag liegt in dem, was Sie künftig nicht mehr tun müssen. Im Einzelhandelsszenario bedeutete eine unternehmensweite Erneuerung des gemeinsamen Schlüssels die erneute Eingabe auf 4.860 Geräten. Bei angenommenen drei Minuten pro Gerät entspricht dies 243 Stunden Arbeitszeit pro Erneuerung. Nach der Migration bedeutet das Ausscheiden eines Mitarbeiters lediglich das Deaktivieren einer Identität sowie das Ändern aller Geräteschlüssel, die diese Person eingegeben hat.
Sie erhalten außerdem ein Authentifizierungsprotokoll darüber, welche Identität oder welcher Schlüssel sich wann und an welchem Standort angemeldet hat. Dieses Protokoll dient als Nachweis für PCI DSS 2.3.2 sowie für Überprüfungen der Zugriffsrechte gemäß ISO 27001 Anhang A Control 5.18. Purple ist nach ISO 27001 und Cyber Essentials zertifiziert und läuft mit einer Verfügbarkeit von 99,999 % an über 80.000 aktiven Standorten. Diese Verfügbarkeit ist entscheidend, wenn RADIUS darüber entscheidet, ob Mitarbeiter arbeiten können.
Häufig gestellte Fragen
Benötigen wir neue Access Points, um das Mitarbeiter-WiFi auf 802.1X umzustellen?
Nein. 802.1X und gerätespezifische Schlüssel laufen auf den Access Points, die Sie bereits besitzen. Purple Access ist hardwareunabhängig und funktioniert als Cloud-Overlay auf Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks und Fortinet. Sie konfigurieren eine Enterprise-SSID, die auf den Cloud-RADIUS von Purple verweist, sowie ein Netzwerk für gerätespezifische Schlüssel über die eigene Funktion Ihres Anbieters. Die einzige physische Überprüfung besteht darin, dass jeder Switch-Trunk die neuen VLANs überträgt.
Können wir die SSID mit gemeinsam genutztem Passwort und die 802.1X-SSID gleichzeitig betreiben?
Ja, und das sollten Sie auch, denn der parallele Betrieb erfordert kein Umstellungs-Wochenende mehr. Wenn Ihre Plattform dies zulässt, wandeln Sie die bisherige SSID in das xPSK-Netzwerk um. Behalten Sie das alte Passwort als einen Schlüssel in einem beschränkten VLAN bei, damit die Geräte weiter funktionieren, während Sie sie migrieren. Löschen Sie diesen Schlüssel an jedem Standort, sobald sein Authentifizierungsprotokoll an 14 aufeinanderfolgenden Tagen keine Nutzung durch Geräte mehr anzeigt.
Was passiert mit Geräten, die 802.1X nicht unterstützen?
Diese wechseln in das xPSK-Netzwerk, jedes mit einem eigenen Schlüssel. Kassen, Kartenterminals, Drucker, Kameras und Signage-Player verfügen selten über ein Zertifikat, aber fast alle akzeptieren eine WPA2-Passphrase. Jeder Schlüssel ist einem VLAN für seine Geräteklasse zugeordnet, sodass Sie ein einzelnes Gerät widerrufen können, ohne andere zu beeinträchtigen. Führen Sie ein Register darüber, wer den jeweiligen Schlüssel eingegeben hat, da PCI DSS 2.3.2 weiterhin für Schlüssel gilt, die einem ausscheidenden Mitarbeiter bekannt waren.
Wie lange dauert eine standortübergreifende 802.1X-Migration?
Planen Sie 10 bis 14 Wochen für 50 Standorte und 20 bis 26 Wochen für 200 Standorte ein und testen Sie diese Annahmen in Ihrem Pilotprojekt. Verwaltete Geräte lassen sich am schnellsten migrieren, da das MDM gleichzeitig an alle Standorte ausrollt. Headless-Geräte geben das Tempo vor, da für einige ein Vor-Ort-Besuch erforderlich ist. Jeder Standort benötigt mindestens 14 fehlerfreie Tage im Authentifizierungsprotokoll, bevor Sie das gemeinsam genutzte Passwort deaktivieren.
Macht 802.1X unser Mitarbeiter-WiFi PCI DSS-konform?
Keine einzelne Maßnahme erreicht das allein, und die Beurteilung obliegt Ihrem Auditor. EAP-TLS und gerätespezifische Schlüssel liefern Ihnen Nachweise für die Anforderung 2.3.2 in PCI DSS v4.0.1. Sobald kein gemeinsam genutzter Schlüssel mehr existiert, erzwingt das Ausscheiden eines Mitarbeiters keine unternehmensweite Schlüsseländerung mehr. Das Authentifizierungsprotokoll zeigt, welche Identität oder welcher Schlüssel sich wann und an welchem Standort angemeldet hat, was auch Überprüfungen der Zugriffsrechte gemäß ISO 27001 unterstützt.
Sollten wir PEAP mit Passwörtern anstelle von Zertifikaten verwenden?
Verwenden Sie EAP-TLS, wo immer es möglich ist. PEAP-MSCHAPv2 entfernt zwar den gemeinsam genutzten Schlüssel, verlässt sich aber weiterhin auf Passwörter. Diese Passwörter können abgefangen werden, wenn ein Gerät das Serverzertifikat nicht überprüft. Microsoft dokumentiert außerdem, dass Windows Defender Credential Guard das MSCHAPv2 Single Sign-On mit gespeicherten Anmeldedaten blockiert. Das führt auf vielen verwalteten Windows Laptops zu Problemen mit passwortbasiertem WiFi. Zertifikate, die über Ihr MDM bereitgestellt werden, vermeiden beide Probleme und erfordern kein Eingreifen der Mitarbeiter.
Benötigen wir On-Premises RADIUS-Server für 802.1X?
Nein. Purple Access bietet RADIUS-as-a-Service aus der Cloud, sodass an den einzelnen Standorten nichts installiert, gepatcht oder ausfallsicher gemacht werden muss. Ihre Access Points senden Authentifizierungsanfragen an Purple. Purple prüft das Zertifikat oder den Schlüssel, wendet Identitätsregeln aus Microsoft Entra ID, Okta oder Google Workspace an und liefert das VLAN zurück. Purple läuft mit einer Verfügbarkeit von 99,999 % und ist nach ISO 27001 sowie Cyber Essentials zertifiziert.
Können Mitarbeiter ihre privaten Smartphones im selben 802.1X SSID nutzen?
Ja, sofern Ihre Richtlinien dies zulassen. Mitarbeiter verbinden sich mit dem offenen Netzwerk, melden sich im Captive Portal mit ihrer geschäftlichen Identität an und erhalten das sichere Netzwerkprofil. Ein Passpoint Profil verbindet das Smartphone anschließend an jedem Standort des Unternehmens automatisch. Ordnen Sie private Smartphones einem reinen Internet-Mitarbeiter-VLAN zu, getrennt von Zahlungs- und Back-Office-Segmenten. Testen Sie im Pilotprojekt, ob Ihr Prozess für ausscheidende Mitarbeiter deren Zugriff zuverlässig entfernt.
Frequently asked questions
Benötigen wir neue Access Points, um das Mitarbeiter-WiFi auf 802.1X umzustellen?
Nein. 802.1X und gerätespezifische Schlüssel laufen auf den Access Points, die Sie bereits besitzen. Purple Access ist hardwareunabhängig und funktioniert als Cloud-Overlay auf Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet. Sie konfigurieren eine Enterprise-SSID, die auf den Cloud-RADIUS von Purple verweist, sowie ein Netzwerk für gerätespezifische Schlüssel unter Nutzung der eigenen Funktion Ihres Anbieters. Die einzige physische Prüfung besteht darin, sicherzustellen, dass jeder Switch-Trunk die neuen VLANs überträgt.
Können wir die SSID mit dem gemeinsam genutzten Passwort und die 802.1X-SSID gleichzeitig betreiben?
Ja, und das sollten Sie auch, denn der parallele Betrieb verhindert ein komplettes Umstellungswochenende. Wandeln Sie die bisherige SSID dort, wo Ihre Plattform es zulässt, in das xPSK-Netzwerk um. Behalten Sie das alte Passwort als einen Schlüssel in einem eingeschränkten VLAN bei, damit die Geräte weiter funktionieren, während Sie sie migrieren. Löschen Sie diesen Schlüssel an jedem Standort, sobald das Authentifizierungsprotokoll zeigt, dass ihn 14 Tage hintereinander kein Gerät mehr verwendet hat.
Was passiert mit Geräten, die 802.1X nicht unterstützen?
Diese wechseln in das xPSK-Netzwerk, jedes mit einem eigenen Schlüssel. Kassen, Kartenterminals, Drucker, Kameras und Signage-Player verfügen selten über ein Zertifikat, aber nahezu alle akzeptieren eine WPA2-Passphrase. Jeder Schlüssel ist einem VLAN für seine Geräteklasse zugewiesen, sodass Sie ein einzelnes Gerät sperren können, ohne andere zu beeinträchtigen. Führen Sie ein Register darüber, wer welchen Schlüssel eingegeben hat, da PCI DSS 2.3.2 weiterhin für Schlüssel gilt, die ausscheidenden Mitarbeitern bekannt waren.
Wie lange dauert eine standortübergreifende 802.1X-Migration?
Planen Sie 10 bis 14 Wochen für 50 Standorte und 20 bis 26 Wochen für 200 Standorte ein, und testen Sie diese Annahmen in Ihrem Pilotprojekt. Verwaltete Geräte lassen sich am schnellsten umstellen, da das MDM das Profil an alle Standorte gleichzeitig überträgt. Kopflose Geräte (Headless Devices) bestimmen das Tempo, da für einige ein Vor-Ort-Besuch erforderlich ist. Jeder Standort benötigt mindestens 14 fehlerfreie Tage im Authentifizierungsprotokoll, bevor Sie das gemeinsame Passwort deaktivieren.
Macht 802.1X unser Mitarbeiter-WiFi PCI-DSS-konform?
Keine einzelne Maßnahme garantiert das allein, die Beurteilung obliegt Ihrem Auditor. EAP-TLS und gerätespezifische Schlüssel liefern Ihnen jedoch die Nachweise für Anforderung 2.3.2 von PCI DSS v4.0.1. Sobald kein gemeinsam genutzter Schlüssel mehr existiert, erzwingt das Ausscheiden eines Mitarbeiters keinen unternehmensweiten Schlüsselwechsel mehr. Das Authentifizierungsprotokoll zeigt, welche Identität oder welcher Schlüssel sich wann an welchem Standort angemeldet hat, was auch Zugriffsrechte-Audits nach ISO 27001 unterstützt.
Sollten wir PEAP mit Passwörtern anstelle von Zertifikaten verwenden?
Nutzen Sie EAP-TLS, wo immer es möglich ist. PEAP-MSCHAPv2 eliminiert zwar den gemeinsam genutzten Schlüssel, basiert aber weiterhin auf Passwörtern. Diese Passwörter können abgefangen werden, wenn ein Gerät das Serverzertifikat nicht überprüft. Microsoft dokumentiert zudem, dass Windows Defender Credential Guard das Single Sign-On von MSCHAPv2 mit gespeicherten Anmeldedaten blockiert. Das beeinträchtigt passwortbasiertes WiFi auf vielen verwalteten Windows-Laptops. Zertifikate, die über Ihr MDM bereitgestellt werden, vermeiden beide Probleme und erfordern keinerlei Interaktion der Mitarbeiter.
Benötigen wir lokale RADIUS-Server für 802.1X?
Nein. Purple Access bietet Cloud-RADIUS, sodass an den einzelnen Standorten nichts installiert, gepatcht oder hochverfügbar ausgelegt werden muss. Ihre Access Points senden Authentifizierungsanfragen an Purple. Purple prüft das Zertifikat oder den Schlüssel, wendet Identitätsregeln aus Microsoft Entra ID, Okta oder Google Workspace an und gibt das VLAN zurück. Purple läuft mit einer Verfügbarkeit von 99,999 % und ist nach ISO 27001 sowie Cyber Essentials zertifiziert.
Können Mitarbeiter private Smartphones auf demselben 802.1X-SSID nutzen?
Ja, sofern Ihre Richtlinien dies zulassen. Mitarbeiter verbinden sich mit dem offenen Netzwerk, melden sich im Captive Portal mit ihrer geschäftlichen Identität an und erhalten das sichere Netzwerkprofil. Ein Passpoint-Profil verbindet das Smartphone anschließend an jedem Standort des Unternehmens automatisch. Weisen Sie private Smartphones einem reinen Internet-Mitarbeiter-VLAN zu, getrennt von Zahlungs- und Backoffice-Segmenten. Testen Sie im Pilotprojekt, ob Ihr Offboarding-Prozess deren Zugriff zuverlässig entfernt.