How to Configure SCEP for Automated Enterprise WiFi Certificate Enrollment

Dieser Leitfaden erklärt, wie Sie SCEP (Simple Certificate Enrollment Protocol) für die automatisierte WiFi-Zertifikatsregistrierung in Unternehmen konfigurieren, und deckt die gesamte Architektur von PKI und NDES bis hin zur MDM-Profilbereitstellung und RADIUS-Validierung ab. Er richtet sich an IT-Manager, Netzwerkarchitekten und CTOs in Hotels, Einzelhandelsketten, Stadien, Konferenzzentren und Organisationen des öffentlichen Sektors, die über Pre-Shared Keys hinausgehen und eine skalierbare, identitätsbasierte 802.1X EAP-TLS-Authentifizierung implementieren müssen. Die hardwareunabhängige Cloud-Overlay-Plattform von Purple lässt sich direkt in diese Architektur integrieren und bietet die WiFi-Ebene für Gäste und BYOD, die parallel zu Ihrem zertifikatsauthentifizierten Mitarbeiternetzwerk läuft.

📖 10 Min. Lesezeit📝 2,282 Wörter🔧 2 ausgearbeitete Beispiele❓ 3 Übungsfragen📚 9 Schlüsseldefinitionen

Diesen Leitfaden anhören

Podcast-Transkript ansehen

Welcome to the Purple Technical Briefing series. I am talking today about something that lands in a lot of IT inboxes but rarely gets a straight answer: how do you actually deploy certificate-based WiFi authentication at scale, using SCEP, across a large network. Whether that is a university campus, a multi-site hotel group, or a large public sector estate, the challenges are identical.

We are going to cover the full picture. What SCEP actually does, how it fits into an 802.1X architecture, the deployment sequence that most teams get wrong, two real-world implementation scenarios, and the pitfalls that will cost you a weekend of your life if you do not plan for them.

This is a consultant briefing, not a tutorial. I am assuming you know what a RADIUS server is and you have probably already decided you need to move away from pre-shared keys. What you need now is the implementation map.

Let us get into it.

First principles. SCEP stands for Simple Certificate Enrollment Protocol. It was formalised by the IETF as RFC 8894 in 2020, though it had been in widespread enterprise use for well over a decade before that. Its job is straightforward: automate the process of getting a digital certificate onto a managed device without requiring a human to touch each machine.

In the context of WiFi authentication, SCEP is the delivery mechanism. The actual authentication protocol you are targeting is EAP-TLS, Extensible Authentication Protocol with Transport Layer Security, which sits inside the 802.1X framework. EAP-TLS is widely regarded as the most secure authentication method for enterprise wireless networks because it requires both the client device and the RADIUS server to present valid certificates. Neither side trusts the other without cryptographic proof. That mutual authentication is what protects you against evil twin attacks, where an attacker spins up a rogue access point to harvest credentials.

Here is how the full chain works. A managed device, a student laptop, a staff phone, a hotel point-of-sale terminal, needs to join the corporate wireless network. Your MDM platform, which might be Microsoft Intune or Jamf, pushes a SCEP payload to that device. The payload contains two things: the SCEP URL, which points to your NDES server or cloud SCEP gateway, and a challenge password or shared secret.

The device generates its own public and private key pair locally. This is critical. The private key never leaves the device. It is generated on-device, stored in the secure enclave or TPM, and is never transmitted across the network. The device then creates a Certificate Signing Request, a CSR, and sends it to the SCEP gateway. The gateway validates the challenge, forwards the CSR to your Certificate Authority, and the CA signs it and returns the public certificate to the device.

From that point on, when the device connects to your WiFi SSID, it presents that certificate to the RADIUS server. The RADIUS server validates the certificate against your CA trust chain, checks the Certificate Revocation List to confirm the cert has not been revoked, and if everything checks out, sends an accept message to the access point. The device is on the network. The whole process is invisible to the user.

Now, let us talk about where SCEP sits relative to the alternative, which is PKCS. PKCS, Public Key Cryptography Standards, is the other certificate delivery method supported by platforms like Intune. With PKCS, the CA generates both the public and private key centrally, and the certificate connector pushes the key pair down to the device. That means the private key travels over the network, which introduces a theoretical attack surface. PKCS is fine for use cases like S/MIME email encryption where key escrow is actually desirable. For WiFi authentication, SCEP is the right choice. The private key stays on the device, full stop.

Now, the hardware layer. SCEP and EAP-TLS are vendor-neutral standards, which means they work across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet access points. Your RADIUS configuration, whether that is Windows NPS, FreeRADIUS, or a cloud RADIUS service, is where you define the certificate validation policy and, critically, where you configure dynamic VLAN assignment.

Dynamic VLANs are how you segment the network by identity. A student device gets VLAN 20 for internet access only. A faculty device gets VLAN 10 for access to internal research systems. A facilities management device gets VLAN 30 for access to building management systems. All of this is driven by the certificate attributes and the RADIUS policy, with no manual intervention per device.

For identity provider integration, SCEP certificate attributes, specifically the Subject Alternative Name, can carry the user's principal name from Microsoft Entra ID, Okta, or Google Workspace. That ties the certificate to a specific identity, which means when you disable an account in Entra ID and the MDM unenrols the device, the certificate is revoked and WiFi access is cut automatically. That is the revocation story that pre-shared keys simply cannot tell.

Right, let us talk about the deployment sequence, because this is where most teams trip up.

The sequence is non-negotiable: Trusted Root certificate first, SCEP certificate profile second, WiFi profile third. Intune and Jamf both enforce profile dependencies. If your WiFi profile references a SCEP certificate that has not yet been deployed to the device, the WiFi profile will fail with a cryptic error that looks like a misconfiguration but is actually just a timing issue.

The second pitfall is group targeting. All three profiles, Trusted Root, SCEP, and WiFi, must be deployed to the exact same Azure AD or Jamf group. If the SCEP profile targets a user group and the WiFi profile targets a device group, Intune cannot resolve the dependency and the WiFi profile will show as Not Applicable. This catches teams out constantly.

Third: NDES server accessibility. Your NDES server needs to be reachable from the internet so that devices can enrol before they arrive on-site. The right way to do this is via Azure AD Application Proxy, not by punching a hole in your firewall. App Proxy gives you secure remote access without inbound ports and lets you apply Conditional Access policies to the enrolment flow.

Fourth: CRL availability. Your RADIUS server checks the Certificate Revocation List every time a device authenticates. If your CRL Distribution Point is unavailable, because a server is down, or the URL has changed, authentication fails for every device on the network simultaneously. That is a campus-wide outage. Make your CRL endpoints highly available, and test revocation before you go live.

For large networks, anything above 500 devices, consider a cloud SCEP gateway rather than on-premises NDES. Cloud gateways eliminate the NDES single point of failure, scale horizontally, and typically integrate directly with cloud RADIUS services, removing another infrastructure dependency.

Let us tackle a few rapid-fire questions we often hear from CTOs.

Can SCEP handle BYOD devices that are not MDM-enrolled? Not directly. SCEP requires MDM enrolment to push the certificate payload. For unmanaged BYOD, you need a different approach, either a self-service onboarding portal, or a separate SSID using a captive portal with identity verification. Purple handles that guest and BYOD layer cleanly, sitting alongside your certificate-authenticated staff network.

What about iOS and Android? Both platforms support SCEP natively. iOS has supported SCEP since iOS 4. Android Enterprise supports SCEP through Intune and other MDMs. The configuration is slightly different per platform but the underlying protocol is identical.

Does EAP-TLS work with WPA3? Yes. WPA3-Enterprise mandates 192-bit security mode for sensitive environments, and EAP-TLS is fully compatible. In fact, WPA3-Enterprise with EAP-TLS is the combination recommended by the Wi-Fi Alliance for government and financial networks.

To bring this together. SCEP certificate WiFi authentication is the right architecture for any network with more than 50 managed devices. It eliminates shared credentials, gives you per-device identity, enables dynamic VLAN segmentation, and integrates directly with your identity provider for automated revocation. The deployment sequence, Trusted Root, then SCEP profile, then WiFi profile, is fixed. Group targeting must be consistent. CRL availability is not optional.

For higher education specifically, the combination of SCEP for staff and faculty devices, alongside a separate guest WiFi layer for students on personal devices, gives you both security and a great user experience without compromise.

If you want to go deeper, Purple's guide on enterprise WiFi authentication covers the cloud-native path. And if you are thinking about what happens when an employee leaves, our guide on revoking WiFi access walks through the full revocation workflow.

Thanks for listening. I am from the Purple technical team, and we will see you in the next briefing.

Wichtigste Erkenntnisse

✓SCEP (RFC 8894) automates certificate enrollment for managed devices - the private key is generated on-device and never transmitted, making it the correct choice for WiFi authentication over PKCS.
✓The deployment sequence is non-negotiable: Trusted Root certificate first, SCEP certificate profile second, WiFi profile third. Violating this order causes profile dependency failures.
✓All three MDM profiles (Trusted Root, SCEP, WiFi) must target the exact same directory group. Cross-group targeting is the most common cause of deployment failures.
✓NDES should be published via Azure AD Application Proxy, not exposed directly to the internet. For networks above 500 devices, a cloud SCEP gateway eliminates the NDES single point of failure.
✓CRL Distribution Point availability is a network-critical dependency. If the RADIUS server cannot reach the CRL, it fails closed and denies all authentication simultaneously.
✓EAP-TLS with SCEP-provisioned certificates satisfies PCI DSS 4.0 Requirement 8.6 for wireless networks in cardholder data environments and is required for WPA3-Enterprise 192-bit (Suite B).
✓SCEP covers managed devices only. Unmanaged BYOD and guest devices require a separate SSID with captive portal and identity verification - Purple's platform handles this layer alongside your certificate-authenticated staff network.

Executive Summary

Für Unternehmensstandorte – ob ein Hotel mit 200 Zimmern, eine Einzelhandelskette mit 50 Standorten oder ein großes Konferenzzentrum – ist die Nutzung von Pre-Shared Keys für das Mitarbeiter-WiFi ein Sicherheitsrisiko und ein betrieblicher Engpass. Ein einziges durchgesickertes Passwort gefährdet das gesamte Netzwerk. Die zertifikatsbasierte Authentifizierung über IEEE 802.1X und EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) eliminiert dieses Risiko vollständig. Jedes Gerät weist seine Identität kryptografisch nach, bevor der Access Point ihm Netzwerkzugriff gewährt.

Die Herausforderung liegt in der Verteilung. Die manuelle Bereitstellung individueller Client-Zertifikate auf Tausenden von Windows-, iOS- und Android-Geräten ist nicht praktikabel. SCEP (Simple Certificate Enrollment Protocol), das 2020 von der IETF als RFC 8894 formalisiert wurde, löst dieses Problem. Es automatisiert den Prozess der Anforderung, Ausstellung und Installation digitaler Zertifikate auf verwalteten Geräten über Ihre MDM-Plattform – ganz ohne Benutzerinteraktion.

Dieser Leitfaden deckt die gesamte Architektur ab: was SCEP tut, wie es sich in Microsoft Intune, Jamf und andere MDM-Plattformen integrieren lässt, die genaue Bereitstellungsreihenfolge, bei der die meisten Teams Fehler machen, und die betrieblichen Fallstricke, die zu Ausfällen führen. Wir behandeln auch zwei reale Implementierungsszenarien aus der Hotellerie und dem Einzelhandel und erklären, wo die Guest WiFi -Plattform von Purple neben Ihrem zertifikatsauthentifizierten Mitarbeiternetzwerk Platz findet.

Hören Sie sich das begleitende Podcast-Briefing an:

Technischer Deep-Dive: SCEP, PKI und 802.1X

Was SCEP tatsächlich tut

SCEP ist kein Ersatz für Ihre Public-Key-Infrastruktur (PKI). Es ist die automatisierte Registrierungsebene, die darauf aufsetzt. Ihre PKI – in der Regel eine zweistufige Hierarchie mit einer Offline-Root-CA und einer Online-Ausstellungs-CA – bleibt der Vertrauensanker. SCEP automatisiert den Schritt, bei dem ein Gerät ein Zertifikat von dieser CA anfordert, wodurch die manuelle CSR-Erstellung und Zertifikatsinstallation entfallen.

Im Kontext der WiFi-Authentifizierung ist das Zielprotokoll EAP-TLS. Dies ist die 802.1X-Authentifizierungsmethode, bei der sowohl das Client-Gerät als auch der RADIUS-Server gültige X.509-Zertifikate vorlegen müssen. Keine Seite vertraut der anderen ohne kryptografischen Nachweis. Dieses Modell der gegenseitigen Authentifizierung verhindert den Diebstahl von Anmeldedaten und schützt vor Evil-Twin-Angriffen, bei denen ein Angreifer einen gefälschten Access Point einrichtet, um Benutzernamen und Passwörter abzufangen.

Eine detaillierte Aufschlüsselung des EAP-TLS-Handshakes finden Sie in unserem Leitfaden zu WiFi-Zertifikatsauthentifizierung: Sicherer Netzwerkzugriff .

Der SCEP-Registrierungsablauf Schritt für Schritt

Die vollständige Registrierungskette funktioniert wie folgt. Ihre MDM-Plattform – Microsoft Intune, Jamf oder ein anderes MDM – sendet eine SCEP-Payload an ein verwaltetes Gerät. Diese Payload enthält zwei Dinge: die SCEP-URL, die auf Ihren NDES-Server (Network Device Enrollment Service) oder Ihr Cloud-SCEP-Gateway verweist, und ein Challenge-Passwort oder ein Shared Secret.

Das Gerät generiert lokal sein eigenes öffentliches und privates Schlüsselpaar. Dies ist das entscheidende Sicherheitsmerkmal von SCEP: Der private Schlüssel wird auf dem Gerät generiert, in der Secure Enclave oder dem TPM-Chip gespeichert und niemals über das Netzwerk übertragen. Das Gerät erstellt dann eine Zertifikatsignierungsanforderung (CSR) und sendet sie an das SCEP-Gateway. Das Gateway validiert das Challenge-Passwort, leitet die CSR an Ihre Zertifizierungsstelle (CA) weiter, und die CA signiert sie und gibt das öffentliche Zertifikat an das Gerät zurück.

Ab diesem Zeitpunkt legt das Gerät, wenn es sich mit Ihrer WiFi-SSID verbindet, dieses Zertifikat dem RADIUS-Server vor. Der RADIUS-Server validiert das Zertifikat anhand Ihrer CA-Vertrauenskette, prüft die Zertifikatssperrliste (CRL), um sicherzustellen, dass das Zertifikat nicht widerrufen wurde, und sendet, wenn alles in Ordnung ist, eine Access-Accept-Nachricht an den Access Point. Das Gerät ist im Netzwerk. Der gesamte Prozess ist für den Benutzer unsichtbar.

SCEP vs. PKCS: Was für WiFi zu verwenden ist

MDM-Plattformen wie Intune unterstützen zwei Mechanismen zur Zertifikatsbereitstellung: SCEP und PKCS (Public Key Cryptography Standards). Der architektonische Unterschied ist erheblich.

Bei SCEP wird der private Schlüssel auf dem Gerät generiert und verlässt dieses nie. Bei PKCS generiert die Zertifizierungsstelle sowohl den öffentlichen als auch den privaten Schlüssel zentral, und der Zertifikats-Connector überträgt das Schlüsselpaar über das Netzwerk auf das Gerät. Das bedeutet, dass der private Schlüssel übertragen wird, was eine theoretische Angriffsfläche darstellt.

PKCS eignet sich für Anwendungsfälle, in denen ein Key Escrow erforderlich ist, wie z. B. bei der S/MIME-E-Mail-Verschlüsselung. Für die WiFi-Authentifizierung ist SCEP die richtige Wahl. Der private Schlüssel bleibt auf dem Gerät.

Eigenschaft	SCEP	PKCS
Generierung des privaten Schlüssels	Auf dem Gerät (TPM/Secure Enclave)	Zentralisiert (CA)
Übertragung des privaten Schlüssels	Niemals	Über das Netzwerk
NDES-Server erforderlich	Ja (oder Cloud-Gateway)	Nein
Empfohlen für WiFi	Ja	Nein
Empfohlen für S/MIME	Nein	Ja

Hardware-Kompatibilität

SCEP und EAP-TLS sind herstellerneutrale Standards. Sie funktionieren mit Access Points von Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet. In Ihrer RADIUS-Konfiguration – sei es Windows NPS, FreeRADIUS oder ein Cloud-RADIUS-Dienst – definieren Sie die Richtlinien für die Zertifikatsvalidierung und die dynamische VLAN-Zuweisung.

Die dynamische VLAN-Zuweisung ist, wie SSie segmentieren das Netzwerk nach Geräteidentität. Ein Mitarbeitergerät erhält VLAN 10 mit Zugriff auf interne Systeme. Ein Gerät eines externen Dienstleisters erhält VLAN 20 mit reinem Internetzugang. Ein Point-of-Sale-Terminal erhält VLAN 30 mit Zugriff ausschließlich auf Zahlungsverarbeitungssysteme. All dies wird durch Zertifikatsattribute und RADIUS-Richtlinien gesteuert, ohne dass ein manueller Eingriff pro Gerät erforderlich ist.

Weitere Informationen darüber, wie sich WiFi Analytics in die identitätsbasierte Netzwerksegmentierung integrieren lässt, finden Sie in unserer Übersicht über die Analyseplattform.

Implementierungsleitfaden: die Bereitstellungsreihenfolge

Die erfolgreiche Konfiguration von SCEP für Enterprise-WiFi erfordert die strikte Einhaltung einer bestimmten Bereitstellungsreihenfolge. MDM-Plattformen erzwingen Profilabhängigkeiten: Ein WiFi-Profil, das auf ein SCEP-Zertifikat verweist, kann erst angewendet werden, wenn dieses Zertifikat auf dem Gerät vorhanden ist. Die Missachtung dieser Reihenfolge ist die häufigste Ursache für Bereitstellungsfehler.

Die Reihenfolge lautet: Trusted Root zuerst, SCEP-Profil an zweiter Stelle, WiFi-Profil an dritter Stelle. Diese Reihenfolge ist nicht verhandelbar.

Schritt 1: Bereitstellung des Trusted-Root-Zertifikatsprofils

Bevor ein Gerät ein Client-Zertifikat anfordern oder Ihrem RADIUS-Server vertrauen kann, muss es der ausstellenden Zertifizierungsstelle (Certificate Authority) vertrauen. Exportieren Sie Ihr Root-CA-Zertifikat – und alle Intermediate-CA-Zertifikate – als .cer-Dateien. Erstellen Sie in Ihrem MDM-Admin-Center ein Trusted-Certificate-Profil, laden Sie die .cer-Datei hoch und stellen Sie sie für Ihre Zielgerätegruppe bereit.

Wenn Sie eine zweistufige PKI-Hierarchie verwenden (empfohlen), müssen Sie je nach MDM-Plattform sowohl das Root-CA- als auch das ausstellende CA-Zertifikat als separate Trusted-Certificate-Profile oder als Kette in einem einzigen Profil bereitstellen.

Schritt 2: Konfiguration des SCEP-Zertifikatsprofils

Sobald das Vertrauen hergestellt ist, konfigurieren Sie das SCEP-Profil, um den Geräten Anweisungen zum Erhalt ihres Client-Zertifikats zu geben.

Erstellen Sie ein neues Konfigurationsprofil und wählen Sie den Profiltyp SCEP-Zertifikat aus. Konfigurieren Sie das Format des Subject-Namens. Für die benutzergesteuerte Authentifizierung ist CN={{UserPrincipalName}} Standard. Verwenden Sie für die Geräteauthentifizierung (gemeinsam genutzte Geräte, IoT, POS-Terminals) CN={{AAD_Device_ID}}. Stellen Sie die Schlüsselverwendung (Key usage) auf Digitale Signatur (Digital signature) und Schlüsselverschlüsselung (Key encipherment) ein. Stellen Sie die erweiterte Schlüsselverwendung (Extended Key Usage) auf Client-Authentifizierung (Client Authentication) (OID: 1.3.6.1.5.5.7.3.2) ein. Verknüpfen Sie dieses Profil mit dem in Schritt 1 erstellten Trusted-Root-Zertifikatsprofil. Geben Sie die externe URL Ihres NDES-Servers an.

Speziell für Microsoft Intune muss der NDES-Server über den Azure AD-Anwendungsproxy veröffentlicht werden, damit sich Remote-Geräte registrieren können, bevor sie vor Ort eintreffen. Setzen Sie NDES nicht direkt dem Internet aus.

Schritt 3: Bereitstellung des 802.1X-WiFi-Profils

Der letzte Schritt besteht darin, die WiFi-Konfiguration zu übertragen, die die Zertifikate an die Netzwerk-SSID bindet. Erstellen Sie ein Wi-Fi-Konfigurationsprofil. Geben Sie den Netzwerknamen (SSID) genau so ein, wie er von Ihren Access Points übertragen wird. Wählen Sie WPA2-Enterprise oder WPA3-Enterprise als Sicherheitstyp. Stellen Sie den EAP-Typ auf EAP-TLS ein. Wählen Sie in den Authentifizierungseinstellungen das in Schritt 2 erstellte SCEP-Zertifikatsprofil als Client-Authentifizierungszertifikat aus. Geben Sie das Trusted-Root-Zertifikat für die Servervalidierung an – dies stellt sicher, dass sich das Gerät nur mit Ihrem legitimen RADIUS-Server und nicht mit einem betrügerischen Access Point verbindet.

Integration von Identitätsanbietern

SCEP-Zertifikatsattribute – insbesondere der Subject Alternative Name (SAN) – können den Principal-Namen des Benutzers aus Microsoft Entra ID, Okta, oder Google Workspace übertragen. Dadurch wird das Zertifikat an eine bestimmte Identität gebunden. Wenn Sie ein Konto in Entra ID deaktivieren und das MDM das Gerät abmeldet, wird das Zertifikat widerrufen und der WiFi-Zugang automatisch gesperrt. Dieser automatisierte Widerruf ist das Sicherheitsmerkmal, mit dem Pre-Shared Keys nicht mithalten können.

Weitere Informationen zu EAP Method WiFi: A Guide to Secure Network Access , einschließlich PEAP-MSCHAPv2-Migrationspfaden, finden Sie in unserem speziellen Leitfaden.

Best Practices und Branchenstandards

Platzierung des NDES-Servers

Der NDES-Server muss aus dem Internet erreichbar sein, damit sich Geräte registrieren können, bevor sie vor Ort eintreffen. Veröffentlichen Sie die NDES-URL über den Azure AD-Anwendungsproxy. Dies ermöglicht einen sicheren Remote-Zugriff, ohne eingehende Firewall-Ports zu öffnen, und erlaubt es Ihnen, Richtlinien für bedingten Zugriff auf den Registrierungsfluss anzuwenden. Setzen Sie NDES niemals direkt dem Internet aus.

Ziehen Sie bei Netzwerken mit mehr als 500 verwalteten Geräten ein Cloud-SCEP-Gateway anstelle eines lokalen NDES in Betracht. Cloud-Gateways eliminieren den Single Point of Failure von NDES, skalieren horizontal und lassen sich in der Regel direkt in Cloud-RADIUS-Dienste integrieren.

CRL-Verfügbarkeit

Ihr RADIUS-Server überprüft bei jeder Authentifizierung eines Geräts die Zertifikatssperrliste (Certificate Revocation List, CRL). Wenn Ihr CRL-Verteilungspunkt (CDP) nicht verfügbar ist – weil ein Server offline ist oder sich die URL geändert hat –, schlägt die Authentifizierung für alle Geräte im Netzwerk gleichzeitig fehl. Konfigurieren Sie Ihren NPS- oder RADIUS-Server so, dass eine strikte CRL-Prüfung erzwungen wird, und stellen Sie eine hohe Verfügbarkeit Ihrer CRL-Endpunkte sicher. Testen Sie den Widerruf vor der Liveschaltung.

Die PCI-DSS-4.0-Anforderung 8.6 schreibt eine Multi-Faktor-Authentifizierung auf Netzwerkebene für Karteninhaber-Datenumgebungen vor. EAP-TLS mit über SCEP bereitgestellten Zertifikaten erfüllt diese Anforderung für drahtlose Netzwerke in Umgebungen des Einzelhandels und des Gastgewerbes .

WPA3-Kompatibilität

EAP-TLS ist vollständig kompatibel mit WPA3-Enterprise. WPA3-Enterprise mit der 192-Bit-Sicherheitssuite (Suite B) schreibt EAP-TLS vor und ist die von der Wi-Fi Alliance empfohlene Kombination für Regierungs-, Finanz- und Gesundheitsnetzwerke. Wenn Sie die Bereitstellung in Umgebungen des Gesundheitswesens oder des Transportwesens mit strengen Compliance-Anforderungen durchführen, ist WPA3-Enterprise mit EAP-TLS die richtige Zielarchitektur.

BYOD und Gast-WWiFi

SCEP erfordert eine MDM-Registrierung, um den Zertifikats-Payload zu übertragen. Unverwaltete BYOD-Geräte oder Gäste werden damit nicht abgedeckt. Für diese Anwendungsfälle benötigen Sie eine separate SSID mit einem Captive Portal und Identitätsprüfung. Die Plattform von Purple übernimmt diese Ebene nahtlos und läuft parallel zu Ihrem zertifikatsauthentifizierten Mitarbeiternetzwerk. Unsere Guest WiFi -Plattform unterstützt bewusste Opt-ins, die Erfassung von First-Party-Daten und die Integration mit Microsoft Entra ID, Okta und Google Workspace zur Identitätsprüfung.

Fehlerbehebung und Risikominderung

WiFi-Profil kann nicht angewendet werden

Symptom: Das Gerät empfängt die Trusted Root- und SCEP-Zertifikate, aber das WiFi-Profil wird im MDM als „Fehler“ oder „Nicht anwendbar“ angezeigt.

Ursache: Diskrepanz bei der Gruppenzuweisung. Wenn das SCEP-Profil auf eine Benutzergruppe und das WiFi-Profil auf eine Gerätegruppe abzielt, kann das MDM die Abhängigkeit nicht auflösen.

Lösung: Überprüfen Sie Ihre Zuweisungen. Stellen Sie sicher, dass die Trusted Root-, SCEP- und WiFi-Profile alle auf dieselbe Verzeichnisgruppe abzielen.

NDES 403 Forbidden-Fehler

Symptom: Geräte können das SCEP-Zertifikat nicht abrufen. Die NDES-IIS-Protokolle zeigen HTTP 403-Fehler.

Ursache: Dem Dienstkonto des MDM Certificate Connectors fehlen die Berechtigungen „Lesen“ und „Registrieren“ (Read and Enroll) für die Zertifikatsvorlage, oder die URL-Filterung der Firewall blockiert SCEP-Abfragezeichenfolgen-Parameter.

Lösung: Überprüfen Sie, ob das Connector-Konto über die Berechtigungen „Lesen“ und „Registrieren“ für die CA-Vorlage verfügt. Überprüfen Sie die Firewall-Protokolle, um sicherzustellen, dass URLs, die ?operation=GetCACaps enthalten, nicht blockiert werden.

Massenauthentifizierungsfehler nach CRL-Ablauf

Symptom: Bei allen Geräten im Netzwerk schlägt die Authentifizierung gleichzeitig fehl.

Ursache: Die CRL ist abgelaufen oder die CDP-URL ist nicht erreichbar. Der RADIUS-Server kann die Gültigkeit der Zertifikate nicht bestätigen und blockiert den Zugriff (fails closed).

Lösung: Konfigurieren Sie die CRL-Überwachung und -Alarmierung. Veröffentlichen Sie CRLs mit einer Gültigkeitsdauer, die deutlich über dem Veröffentlichungsintervall liegt. Testen Sie die CDP-Erreichbarkeit vom RADIUS-Server aus vor der Liveschaltung.

Zertifikatsablauf führt zu unbemerkten Ausfällen

Symptom: Einzelne Geräte können sich sporadisch und ohne klares Muster nicht verbinden.

Ursache: Client-Zertifikate sind abgelaufen und das MDM hat sie nicht erfolgreich erneuert.

Lösung: Konfigurieren Sie die Zertifikatsverlängerung so, dass sie bei 80 % der Zertifikatslebensdauer ausgelöst wird. Überwachen Sie die MDM-Registrierungsstatusberichte auf Geräte mit Zertifikatsfehlern. Legen Sie die Gültigkeitsdauer von Zertifikaten passend zu Ihrem Geräteaktualisierungszyklus fest – in der Regel ein bis zwei Jahre für verwaltete Endpunkte.

ROI und geschäftliche Auswirkungen

Der Übergang zur SCEP-basierten 802.1X-Zertifikatsauthentifizierung liefert messbare Vorteile in den Bereichen Sicherheit, Betrieb und Compliance.

Reduzierung von Helpdesk-Tickets: Passwortbasiertes WiFi verursacht ein erhebliches Volumen an Support-Tickets – durch abgelaufene Passwörter, Sperrungen und Tippfehler. Die zertifikatsbasierte Authentifizierung ist für den Benutzer unsichtbar. Unternehmen verzeichnen nach der Migration in der Regel eine Reduzierung des WiFi-bezogenen Helpdesk-Volumens um 70–80 %.

Sicherheitsniveau: EAP-TLS eliminiert das Abgreifen von Anmeldedaten (Credential Harvesting) und Man-in-the-Middle-Angriffe. Dies unterstützt direkt die Einhaltung von PCI DSS 4.0 für Netzwerke im Einzelhandel und im Gastgewerbe sowie die Anforderungen von Artikel 32 der GDPR für geeignete technische Sicherheitsmaßnahmen.

Automated Revocation: Wenn ein Mitarbeiter das Unternehmen verlässt, führt die Deaktivierung seines Kontos in Microsoft Entra ID zum automatischen Widerruf des Zertifikats und zur MDM-Abmeldung. Der WiFi-Zugriff wird ohne manuelles Eingreifen des Netzwerkteams gesperrt.

Netzwerksegmentierung: Die dynamische VLAN-Zuweisung über RADIUS-Zertifikatsattribute bietet Ihnen eine kryptografisch erzwungene Netzwerksegmentierung. Geräte landen basierend auf den Zertifikatseigenschaften im richtigen Netzwerksegment, nicht auf Basis der SSID-Auswahl oder der MAC-Adressfilterung – beides lässt sich leicht umgehen.

Purple ist an über 80.000 Live-Standorten mit einer Betriebszeit von 99,999 % im Einsatz, und unsere Plattform ist nach ISO 27001, GDPR, CCPA und Cyber Essentials zertifiziert. Unser hardwareunabhängiges Cloud-Overlay lässt sich in Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet integrieren – sodass Ihr zertifikatsauthentifiziertes Mitarbeiternetzwerk und unsere Gast-WiFi-Ebene auf derselben Infrastruktur aufbauen.

Weitere Informationen darüber, wie Verhaltensanalysen: Einblicke für WiFi-Netzwerke Ihre sichere Netzwerkbereitstellung ergänzen kann, finden Sie in unserem Leitfaden für Analysen.

Referenzen

[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Infrastruktur zur Unterstützung von SCEP mit Intune konfigurieren - Microsoft Learn [3] PCI DSS Wireless-Richtlinien - PCI Security Standards Council

Schlüsseldefinitionen

SCEP (Simple Certificate Enrollment Protocol)

A protocol formalised in RFC 8894 that allows managed devices to automatically request and receive X.509 digital certificates from a Certificate Authority via HTTP, using a shared challenge password for initial authentication. The private key is generated on the device and never transmitted.

The standard mechanism used by MDM platforms like Microsoft Intune and Jamf to deploy WiFi authentication certificates to managed endpoints at scale.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

The most secure 802.1X authentication method, requiring both the client device and the RADIUS server to present valid X.509 certificates. Mutual authentication means neither side trusts the other without cryptographic proof.

The target authentication protocol for enterprise WiFi. Mandated or strongly recommended by PCI DSS 4.0, WPA3-Enterprise 192-bit (Suite B), and HIPAA for wireless networks handling sensitive data.

NDES (Network Device Enrollment Service)

A Microsoft Windows Server role that acts as a Registration Authority (RA) between SCEP-enabled devices and a Certificate Authority. It validates challenge passwords and forwards CSRs to the CA on behalf of devices that lack domain credentials.

Required infrastructure for SCEP deployment with Microsoft Intune. Should be published via Azure AD Application Proxy rather than exposed directly to the internet.

PKI (Public Key Infrastructure)

The hierarchy of Certificate Authorities, policies, and procedures used to issue, manage, and revoke digital certificates. A two-tier PKI consists of an offline root CA (the master trust anchor) and an online issuing CA (which handles day-to-day certificate issuance).

The non-negotiable prerequisite for EAP-TLS and SCEP deployment. The root CA should be kept air-gapped; its private key is the foundation of your entire certificate trust chain.

CSR (Certificate Signing Request)

A message generated by a device containing its public key and identity information, sent to a Certificate Authority to request a signed digital certificate. In SCEP, the CSR is generated on-device and wrapped in a PKCS envelope before transmission.

Generated automatically by the device during the SCEP enrollment flow. The private key used to sign the CSR never leaves the device.

CRL (Certificate Revocation List)

A list published by the Certificate Authority containing the serial numbers of certificates that have been revoked before their expiration date. RADIUS servers check the CRL on every authentication attempt to ensure revoked certificates cannot access the network.

CRL Distribution Point (CDP) availability is critical. If the RADIUS server cannot reach the CRL, it fails closed and denies all authentication - causing a network-wide outage.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol that provides centralised Authentication, Authorisation, and Accounting (AAA) for network access. In 802.1X WiFi, the RADIUS server validates client certificates, checks the CRL, and returns an Access-Accept or Access-Reject message to the access point.

The authentication server in the 802.1X supplicant-authenticator-server model. Common implementations include Windows NPS, FreeRADIUS, and cloud RADIUS services.

Dynamic VLAN assignment

A RADIUS feature that places an authenticated device on a specific VLAN based on certificate attributes or directory group membership, rather than relying on SSID selection or MAC address filtering. Enforces network segmentation by device identity.

Enables a single SSID to serve multiple device types with different network access levels. A staff device gets VLAN 10 (internal access); a contractor device gets VLAN 20 (internet only); a POS terminal gets VLAN 30 (payment systems only).

MDM (Mobile Device Management)

Software used by IT teams to enroll, configure, secure, and manage smartphones, tablets, and laptops. MDM platforms like Microsoft Intune and Jamf use SCEP profiles to push certificate enrollment instructions to managed devices without user interaction.

The prerequisite for SCEP-based certificate deployment. Devices must be MDM-enrolled before they can receive SCEP and WiFi profiles. Unmanaged BYOD devices require a separate onboarding approach.

Ausgearbeitete Beispiele

A 200-room Premier Inn property needs to secure its staff WiFi for point-of-sale tablets and housekeeping smartphones. They currently use a pre-shared key that has been leaked to contractors. They manage devices via Microsoft Intune and have a mix of iOS and Android devices. The property uses HPE Aruba access points.

Deploy an internal Microsoft AD CS two-tier PKI. Configure NDES on a dedicated Windows Server and publish it via Azure AD Application Proxy.
In Intune, create a Trusted Root Certificate profile containing the Root CA and Issuing CA certificates. Deploy to a 'Property Staff Devices' Azure AD group.
Create a SCEP Certificate profile in Intune pointing to the NDES external URL. Set Subject Name format to CN={{AAD_Device_ID}} since these are shared devices. Set Key Usage to Digital Signature and Key Encipherment, Extended Key Usage to Client Authentication. Deploy to 'Property Staff Devices'.
Create a Wi-Fi profile for the staff SSID, configuring WPA2-Enterprise and EAP-TLS. Select the SCEP profile for client authentication and the Root CA for server validation. Deploy to 'Property Staff Devices'.
Configure the HPE Aruba RADIUS settings to point to Windows NPS. On NPS, configure a Network Policy requiring EAP-TLS and assigning VLAN 10 for staff devices.
Once devices receive profiles and connect successfully, rotate the PSK on the old SSID and schedule its decommission.

Kommentar des Prüfers: This approach correctly identifies that shared devices (POS, housekeeping) require device-based authentication (CN={{AAD_Device_ID}}) rather than user-based authentication, since multiple staff members use the same device. It follows the mandatory profile deployment sequence and ensures all three profiles target the same Azure AD group. Publishing NDES via App Proxy rather than direct internet exposure is the correct security posture for a hospitality environment.

A retail chain with 50 locations wants to deploy 802.1X for corporate laptops across all sites. They use Cisco Meraki access points and Microsoft Intune. They do not want to deploy and maintain on-premises NDES servers or AD CS infrastructure at each location or in their data centre.

Implement a cloud-based PKI and SCEP gateway service that integrates with Intune via the SCEP protocol. The cloud CA issues certificates; the cloud SCEP gateway handles CSR validation.
Configure the cloud RADIUS service (provided by the PKI vendor) within the Cisco Meraki dashboard under Wireless > Access Control for the corporate SSID. Set security to WPA2-Enterprise and point RADIUS to the cloud service.
In Intune, create a Trusted Root Certificate profile containing the cloud CA root certificate. Deploy to 'Corporate Laptops' device group.
Create a SCEP Certificate profile pointing to the cloud SCEP gateway URL. Set Subject Name to CN={{UserPrincipalName}} for user-based authentication. Deploy to 'Corporate Laptops'.
Create a Wi-Fi profile for the corporate SSID with EAP-TLS, referencing the SCEP profile and the cloud CA root. Deploy to 'Corporate Laptops'.
When laptops enroll in Intune, they automatically request certificates from the cloud CA via the cloud SCEP gateway. No on-premises infrastructure is required at any of the 50 locations.

Kommentar des Prüfers: This is the optimal modern architecture for distributed retail environments. By leveraging cloud PKI and cloud RADIUS, the organisation eliminates the need to maintain complex on-premises infrastructure (NDES, AD CS, NPS) at each site. The cloud SCEP gateway scales horizontally and is inherently highly available, removing the single point of failure that on-premises NDES introduces. Cisco Meraki's cloud-managed architecture aligns well with this approach.

Übungsfragen

Q1. Your organisation is migrating from PEAP-MSCHAPv2 to EAP-TLS. You have successfully deployed the Trusted Root and SCEP profiles to your 'Corporate Users' Azure AD group in Intune. You deploy the WiFi profile to 'All Corporate Devices'. Users report they cannot connect and the WiFi profile shows as Not Applicable.

Hinweis: Check the profile dependencies and group targeting rules. Intune resolves profile dependencies based on the assigned group.

Musterlösung anzeigen

The issue is a group targeting mismatch. The WiFi profile depends on the SCEP profile, which was targeted at a User group ('Corporate Users'). The WiFi profile was targeted at a Device group ('All Corporate Devices'). Intune cannot resolve the dependency across group types. The fix is to change all three profile assignments - Trusted Root, SCEP, and WiFi - to target the same group. Decide whether to use a User group or a Device group based on your authentication model (user-based vs device-based), and apply that consistently across all three profiles.

Q2. A security audit reveals that when an employee is terminated and their Microsoft Entra ID account is disabled, their corporate smartphone can still connect to the staff WiFi network for up to a week after termination.

Hinweis: Consider how the RADIUS server determines whether a certificate is still valid after the account is disabled. What is the mechanism for communicating revocation status?

Musterlösung anzeigen

The RADIUS server is not performing strict Certificate Revocation List checking, or the CRL is published infrequently. When an employee is terminated, the MDM should unenroll the device and the CA should revoke the certificate. However, if the RADIUS server is not checking the CRL on every authentication attempt - or if the CRL is only published weekly - the revoked certificate continues to be accepted. The fix involves three steps: configure the RADIUS server to enforce strict CRL checking on every authentication; configure the CA to publish the CRL at a shorter interval (daily or more frequently); and ensure the MDM is configured to trigger certificate revocation when a device is unenrolled.

Q3. You need to provide secure WiFi access for headless IoT devices (smart thermostats, digital signage players) that cannot run an MDM agent and cannot display a captive portal. Can you use SCEP for these devices, and if not, what is the recommended alternative?

Hinweis: Consider the prerequisites for SCEP enrollment and what alternatives exist for devices that cannot be MDM-enrolled or interact with a browser.

Musterlösung anzeigen

SCEP cannot be used for these devices. SCEP requires an MDM agent to receive the enrollment URL and challenge password, generate the key pair, and install the resulting certificate. Headless IoT devices that cannot run an MDM agent cannot participate in the SCEP enrollment flow. The recommended alternatives are: (1) MAC Authentication Bypass (MAB) combined with strict VLAN segmentation - the RADIUS server allows the device based on its MAC address and places it on an isolated IoT VLAN with no access to corporate systems; (2) if the device supports it, EST (Enrollment over Secure Transport, RFC 7030) can provision certificates to devices that support HTTPS but not MDM; (3) for devices with a management interface, some vendors support SCEP enrollment directly via the device firmware without requiring an MDM agent. In all cases, IoT devices should be isolated on a dedicated VLAN regardless of the authentication method used.

Weiterlesen in dieser Reihe

Einrichtung eines Captive Portals auf Starlink: Ein Leitfaden für abgelegene und maritime Standorte

Dieser Leitfaden beschreibt detailliert, wie Sie die native Starlink-Hardware umgehen und ein Cloud-gesteuertes Captive Portal mithilfe von Enterprise-Routing-Geräten integrieren. Sie erfahren, wie Sie die CGNAT-Einschränkung überwinden, eine VLAN-Segmentierung erzwingen, Bandbreitenbeschränkungen von Satelliten verwalten und die Einhaltung gesetzlicher Vorschriften sicherstellen.

Hotel Guest WiFi Management: Integrating PMS, Portals, and Brand Standards

Dieser technische Leitfaden beschreibt detailliert die Architektur von Hotel-WiFi-Netzwerken der Enterprise-Klasse, mit Schwerpunkt auf VLAN-Segmentierung, PMS-Integration für automatisiertes Sitzungsmanagement und Captive Portal-Optimierung für eine GDPR-konforme Datenerfassung.

Captive Portal Best Practices: Designing for High Conversion and Compliance

Dieser technische Leitfaden bietet IT-Managern, Netzwerkarchitekten und Betriebsleitern von Veranstaltungsorten eine vollständige Blaupause für die Bereitstellung von Captive Portals, die Netzwerksicherheit mit hoher User-Conversion in Einklang bringen. Er deckt die gesamte Architektur ab – von der VLAN-Segmentierung und RADIUS-Authentifizierung bis hin zu GDPR-konformem Consent-Design und der Auswahl von Authentifizierungsmethoden. Basierend auf der operativen Erfahrung von Purple in über 80.000 Standorten und 440 Millionen Logins im Jahr 2024 basiert jede Empfehlung auf realen Bereitstellungsdaten.