Das Modell wirkt sauber: ein Firmen-WLAN, ein Passwort, per Geräteverwaltung lautlos auf die verwalteten Notebooks verteilt. Die Nutzer tippen nichts ein, sie kennen den Schlüssel angeblich gar nicht — also kann ihn auch niemand weitertragen. So plausibel das klingt, in typischen Unternehmensumgebungen hält die Annahme nicht.
Ein Pre-Shared Key (WPA2- oder WPA3-Personal) ist ein geteiltes, symmetrisches Geheimnis. Damit die Karte sich ins Funknetz einbucht, muss der Schlüssel auf dem Gerät liegen. Und was auf dem Gerät liegt, kann von dort auch wieder heraus. Wir haben die Kette im isolierten Labor mit echten Windows-Bordmitteln nachgestellt — vom Auslesen des Klartext-Schlüssels bis zum zertifikatsbasierten Zielaufbau, der das Grundproblem löst. Alle Screenshots in diesem Beitrag stammen aus diesem Lauf; es kamen ausschließlich synthetische Daten und ein selbst gesetztes Test-Passwort zum Einsatz.
Eine Abgrenzung vorab, weil sie wichtig ist: WPA3-Personal ist gegenüber WPA2 ein echter kryptografischer Fortschritt. Der SAE-Handshake (Simultaneous Authentication of Equals) verhindert das Offline-Ausprobieren mitgeschnittener Handshakes, das WPA2-PSK jahrelang angreifbar machte. Der Punkt dieses Beitrags ist nicht die Chiffre. Es ist das Modell dahinter — ein Schlüssel, den sich alle teilen. Für Gäste-WLANs und isolierte IoT-Segmente bleibt ein PSK eine legitime Wahl.
Problem: Der Schlüssel liegt am Endpunkt — und das Vertrauen endet dort
Wo liegt die Vertrauensgrenze eines geteilten WLAN-Schlüssels wirklich? Nicht in der Luft und nicht am Access Point, sondern auf dem Client. Dort ist der Schlüssel gespeichert, damit sich das Gerät verbinden kann. Windows legt ihn im Profilspeicher des WLAN-Dienstes ab, standardmäßig verschlüsselt. Ruft aber ein Konto mit lokalen Administratorrechten das Bordmittel netsh mit dem Parameter key=clear auf, gibt Windows den Schlüssel im Klartext zurück — laut Microsoft-Dokumentation genau dann, wenn der Aufrufer lokaler Administrator ist.
netsh wlan show profile key=clear gibt den Schlüssel im Klartext aus.Kein Exploit, kein fremder Code, kein Angriff aus der Ferne — ein dokumentiertes Kommando, das genau das tut, wofür es gedacht ist. Die einzige Vorbedingung ist lokaler Administratorzugriff auf dem Gerät. Damit verschiebt sich die eigentliche Frage: Das Vertrauen in den WLAN-Schlüssel endet am privilegiertesten Konto auf dem Client. Wo lokale Adminrechte breit gestreut sind, kennt praktisch jeder Nutzer den Schlüssel — er muss ihn nur einmal abfragen.
Der Schlüssel bleibt dabei nicht am Gerät. Derselbe netsh-Aufruf exportiert das Profil als Datei, mit dem Schlüssel im Klartext im XML:
Eine Textdatei, die den Netzzugang trägt. Sie lässt sich kopieren, verschicken, auf ein beliebiges privates Gerät übertragen. Das „nur verwaltete Geräte"-Versprechen hängt damit an einem Geheimnis, das jedes verwaltete Gerät mit sich führt und jeder lokale Administrator herausgeben kann.
Szenarien: Drei Bruchstellen des geteilten Schlüssels
Aus dieser einen Eigenschaft — ein Geheimnis, das alle teilen und das am Endpunkt liegt — folgen drei praktische Schwächen.
Extraktion hebt das Geräte-Vertrauen auf. Sobald ein Nutzer den Schlüssel hat, hängt er jedes beliebige Gerät ins Firmennetz. Das Gate „nur verwaltete Hardware" ist umgangen, ohne dass ein einziges Sicherheitswerkzeug anschlägt.
Ein geteilter Schlüssel liefert keine Identität. Weil alle Geräte dasselbe Geheimnis vorweisen, kann die Infrastruktur sie nicht auseinanderhalten. Im Zugriffs- oder Verbindungsprotokoll steht keine belastbare Geräteidentität. Ein unbefugtes Gerät ist von einem verwalteten nicht zu unterscheiden — es gibt keine Attribution.
Sperren geht nur gruppenweit. Ist der Schlüssel einmal kompromittiert oder ein Gerät verloren, gibt es kein gezieltes Zurückziehen für dieses eine Gerät. Der einzige Weg ist, den Schlüssel für alle zu ändern und ihn auf den gesamten Bestand neu auszurollen.
Zwischenlösungen mildern das ab, ohne die Wurzel zu treffen. PEAP mit MSCHAPv2 hebt zwar auf eine 802.1X-Anmeldung, bleibt aber ein Passwort-Credential — phishbar und an einen Nutzer, nicht an ein Gerät gebunden. iPSK beziehungsweise Private-PSK vergibt pro Gerät oder Gruppe eigene Schlüssel und begrenzt so den Wirkungsradius einer Kompromittierung; der Schlüssel bleibt aber ein exportierbares, kopierbares Geheimnis auf dem Client. Cloud-PSK-Dienste verlagern die Verwaltung des Geheimnisses, ändern aber nichts daran, dass am Ende ein Schlüssel auf dem Endgerät liegt.
Lösung: Das Gerät beweist, dass es es selbst ist
Der tragfähige Aufbau wechselt das Vertrauensmodell. Statt eines Geheimnisses, das alle kennen, bekommt jedes Gerät eine eigene Identität in Form eines Zertifikats — und der zugehörige private Schlüssel verlässt das Gerät nie. Genau das leistet 802.1X mit EAP-TLS: Jedes Gerät weist beim Verbinden sein Zertifikat gegenüber einem RADIUS-Server nach, der die Zugangsentscheidung trifft und protokolliert.
Der entscheidende Baustein ist, wo der private Schlüssel entsteht und liegt. Über den Microsoft Platform Crypto Provider wird er direkt im TPM erzeugt und als nicht exportierbar markiert. Der Beweis dafür ist ein Nicht-Ereignis: Der Versuch, den privaten Schlüssel zu exportieren, schlägt fehl.
Ein Schlüssel, den das Gerät nicht hergibt, lässt sich nicht kopieren, nicht per netsh auslesen und nicht in eine Datei exportieren. Damit ist die Geräteidentität an genau diese eine Hardware gebunden.
Auf der Netzseite entscheidet ein RADIUS-Server — bei Microsoft der Network Policy Server (NPS) — anhand des Zertifikats über den Zugang. Im Labor haben wir diesen Entscheid gegen einen RADIUS-Server mit EAP-TLS nachgestellt, dessen Zertifikate an dieselbe interne Zertifizierungsstelle gebunden sind. Ein verwaltetes Gerät mit gültigem Zertifikat wird angenommen; ein Gerät ohne gültiges Zertifikat wird abgewiesen — und beide Versuche stehen einzeln, dem Gerät zugeordnet, im Protokoll:
Damit wandert die Vertrauensgrenze von „wer den Schlüssel kennt" zu „welches Gerät kryptografisch nachweisbar es selbst ist". Der Nebengewinn ist die Sichtbarkeit: Jede Anmeldung ist ein Ereignis mit Geräteidentität, statt einer anonymen Assoziation. Ein verlorenes Gerät sperrt man einzeln, indem sein Zertifikat zurückgezogen wird — ohne den ganzen Bestand anzufassen.
In der Praxis trägt diese Architektur eine überschaubare Kette: eine Zertifizierungsstelle (unter Windows die Active-Directory-Zertifikatdienste, ADCS), Zertifikatsvorlagen, die den TPM-gebundenen Schlüsselspeicher erzwingen, die automatisierte Verteilung an verwaltete Geräte über die Geräteverwaltung (etwa Microsoft Intune mit SCEP oder PKCS) und den RADIUS-Server als Policy- und Protokollpunkt. Die eigentliche Wurzelmaßnahme liegt daneben: breit gestreute lokale Adminrechte einzudämmen. Denn der Klartext-Schlüssel aus dem ersten Screenshot war nur deshalb erreichbar, weil ein Konto lokal administrieren durfte.
Wie sich das regulatorisch einordnet
Diese Bewegung — weg vom geteilten Geheimnis, hin zu geräte- und zertifikatsbasierter Authentisierung — deckt sich mit gängigen Vorgaben, ohne dass eine davon „EAP-TLS" wortwörtlich vorschreibt. NIST SP 800-153 empfiehlt für den Unternehmensbetrieb eine 802.1X/EAP-basierte WLAN-Authentisierung statt eines geteilten Schlüssels. Das BSI behandelt 802.1X/EAP im Baustein NET.3.4 Network Access Control; die Anforderung NET.3.4.A7 („SOLLTE") verlangt, Endgeräte automatisiert und sicher nach dem Stand der Technik zu authentisieren — „auf Basis von Zertifikaten oder Zugangskonten" — und unsichere Verfahren nur in begründeten, dokumentierten Ausnahmefällen zu nutzen. Der WLAN-Baustein NET.2.1 führt schwache EAP-Verfahren wie EAP-MD5 als Gefährdung und verlangt bei entwendeten Geräten die Sperrung von Client-Zertifikaten; ein ausdrückliches EAP-TLS-Gebot enthält er nicht. Im Finanzsektor adressiert DORA (Verordnung (EU) 2022/2554) in Artikel 9 Schutz- und Präventionsmaßnahmen; die granularen Anforderungen zu Netzwerksicherheit, Verschlüsselung und Schlüsselverwaltung stehen in der technischen Regulierungsstandard-Verordnung (Delegierte Verordnung (EU) 2024/1774), Artikel 13, 6 und 7. Dieser Abschnitt ist eine fachliche Einordnung und keine Rechtsberatung.
Wenn Sie den Weg von PSK zu 802.1X/EAP-TLS gehen wollen — von der Zertifikatsarchitektur über RADIUS bis zur Verteilung per Geräteverwaltung — oder zuerst die breite Vergabe lokaler Adminrechte eindämmen möchten, unterstützt Blackfort Technology bei der WLAN- und NAC-Architektur und der Least-Privilege-Härtung.
Zum Mitnehmen
- →Ein WLAN-Passwort ist nur so geheim wie das privilegierteste Konto auf dem Client.
- →Ein PSK schützt die Funkstrecke, liefert aber keine Geräteidentität — und damit keine Attribution und keine gezielte Sperrung.
- →Zugangskontrolle im WLAN heißt: Das Gerät beweist kryptografisch, dass es es selbst ist — mit einem Schlüssel, den es nie hergibt.
- →WPA3-Personal ist ein Fortschritt; für Gäste und IoT bleibt PSK sinnvoll. In typischen Unternehmensnetzen trägt erst die zertifikatsbasierte Identität.