Microsoft Intune WiFi Certificate Deployment via SCEP and PKCS
This guide provides a step-by-step technical reference for deploying WiFi authentication certificates via Microsoft Intune using SCEP and PKCS. It is designed for IT managers and network architects implementing passwordless 802.1X WiFi to ensure seamless, secure connectivity across enterprise environments.
Video overview
Part of our core series: Enterprise WiFi Security Guide →
- Executive Summary
- Technischer Deep-Dive: SCEP vs. PKCS
- SCEP (Simple Certificate Enrollment Protocol)
- PKCS (Public Key Cryptography Standards)
- Implementierungsleitfaden: Die Bereitstellungsreihenfolge
- Schritt 1: Bereitstellung des vertrauenswürdigen Root-Zertifikatsprofils
- Schritt 2: Konfigurieren des SCEP-Zertifikatsprofils
- Schritt 3: Bereitstellung des 802.1X WiFi-Profils
- Best Practices & Branchenstandards
- Platzierung und Sicherheit des NDES-Servers
- RADIUS- und CRL-Prüfung
- Fehlerbehebung & Risikominderung
- Problem: WiFi-Profil kann nicht angewendet werden
- Problem: NDES 403 Forbidden-Fehler
- ROI & geschäftliche Auswirkungen

Executive Summary
Für Unternehmensstandorte – ob eine geschäftige Gastgewerbe -Umgebung, ein Einzelhandel -Betrieb mit mehreren Standorten oder ein moderner Campus – ist die Nutzung von Pre-Shared Keys oder einfachen Captive Portals für das Mitarbeiter-WiFi ein Sicherheitsrisiko und ein betrieblicher Engpass. Moderne Netzwerkarchitekturen erfordern eine 802.1X-Authentifizierung mittels EAP-TLS. Dies stellt sicher, dass jedes Gerät kryptografisch verifiziert wird, bevor es auf das Netzwerk zugreift.
Die Herausforderung liegt jedoch in der Verteilung: Wie stellen Sie eindeutige Client-Zertifikate auf Tausenden von Windows-, iOS- und Android-Geräten bereit, ohne Ihren Helpdesk mit Support-Tickets zu überlasten? Microsoft Intune löst dies durch ein automatisiertes Zertifikats-Lebenszyklusmanagement. Durch die Nutzung von SCEP- (Simple Certificate Enrollment Protocol) oder PKCS-Zertifikatsprofilen (Public Key Cryptography Standards) können IT-Teams vertrauenswürdige Root- und Client-Zertifikate geräuschlos auf verwaltete Endpunkte übertragen.
Dieser Leitfaden bietet einen definitiven Architektur-Entwurf und eine schrittweise Implementierungsstrategie für die Intune WiFi-Zertifikatsbereitstellung. Wir untersuchen die entscheidenden Unterschiede zwischen SCEP und PKCS, beschreiben die genaue Bereitstellungsreihenfolge für den Erfolg und skizzieren praxisnahe Strategien zur Risikominderung. So stellen Sie sicher, dass Ihr Gäste-WiFi und Ihre Unternehmensnetzwerke sicher und leistungsstark bleiben.
Hören Sie sich das begleitende Podcast-Briefing an:
Technischer Deep-Dive: SCEP vs. PKCS
Bei der Planung Ihrer Intune WiFi-Zertifikatsbereitstellungsstrategie ist die Wahl des Zertifikatsbereitstellungsmechanismus die erste Architekturentscheidung. Intune unterstützt sowohl SCEP als auch PKCS, diese funktionieren jedoch grundlegend unterschiedlich.
SCEP (Simple Certificate Enrollment Protocol)
SCEP ist der Branchenstandard für die Registrierung von Unternehmensgeräten. In einem SCEP-Workflow weist der Intune-Dienst den Endpunkt an, sein eigenes privates/öffentliches Schlüsselpaar zu generieren. Das Gerät erstellt dann eine Zertifikatsignierungsanforderung (Certificate Signing Request, CSR) und sendet diese über einen NDES-Server (Network Device Enrollment Service) an Ihre Zertifizierungsstelle (Certificate Authority, CA). Die CA signiert die Anforderung und gibt das öffentliche Zertifikat an das Gerät zurück.
Der entscheidende Sicherheitsvorteil von SCEP besteht darin, dass der private Schlüssel das Gerät niemals verlässt. Er wird lokal generiert, in der sicheren Enklave des Geräts gespeichert (wie dem TPM unter Windows oder der Secure Enclave unter iOS) und niemals über das Netzwerk übertragen. Dies macht SCEP zum dringend empfohlenen Ansatz für die 802.1X-Authentifizierung.
PKCS (Public Key Cryptography Standards)
Im Gegensatz dazu generiert die Zertifizierungsstelle bei PKCS sowohl den öffentlichen als auch den privaten Schlüssel zentral. Der Microsoft Intune Certificate Connector exportiert dieses Schlüsselpaar anschließend sicher und überträgt es auf das Zielgerät.
Obwohl PKCS die Bereitstellung und Wartung eines NDES-Servers überflüssig macht – was den Infrastruktur-Aufwand vereinfacht –, birgt es ein theoretisches Sicherheitsrisiko, da der private Schlüssel über das Netzwerk übertragen wird. PKCS eignet sich im Allgemeinen besser für Anwendungsfälle, in denen eine Schlüsselhinterlegung (Key Escrow) erforderlich ist, wie z. B. bei der S/MIME-E-Mail-Verschlüsselung, als für die Netzwerkauthentifizierung.

Implementierungsleitfaden: Die Bereitstellungsreihenfolge
Die erfolgreiche Konfiguration eines Intune WiFi-Profils für 802.1X erfordert die strikte Einhaltung einer bestimmten Bereitstellungsreihenfolge. Die Abhängigkeiten der Intune-Profile schreiben vor, dass Vertrauen etabliert werden muss, bevor die Authentifizierung konfiguriert werden kann.
Schritt 1: Bereitstellung des vertrauenswürdigen Root-Zertifikatsprofils
Bevor ein Gerät ein Client-Zertifikat anfordern oder Ihrem RADIUS-Server vertrauen kann, muss es der ausstellenden Zertifizierungsstelle vertrauen.
- Exportieren Sie Ihr Root-CA-Zertifikat (und alle Intermediate-CA-Zertifikate) als
.cer-Dateien. - Navigieren Sie im Microsoft Endpoint Manager Admin Center zu Geräte > Konfigurationsprofile > Profil erstellen.
- Wählen Sie die Zielplattform (z. B. Windows 10 und neuer) und den Profiltyp Vertrauenswürdiges Zertifikat.
- Laden Sie die
.cer-Datei hoch und stellen Sie dieses Profil für Ihre Zielgerätegruppen bereit.
Faustregel: Weisen Sie alle zusammengehörigen Profile immer denselben Gruppen zu (entweder Benutzern oder Geräten), um Bereitstellungsfehler zu vermeiden.
Schritt 2: Konfigurieren des SCEP-Zertifikatsprofils
Sobald das Vertrauen etabliert ist, konfigurieren Sie das SCEP-Profil, um Geräten mitzuteilen, wie sie ihr Client-Zertifikat abrufen können.
- Erstellen Sie ein neues Konfigurationsprofil und wählen Sie SCEP-Zertifikat.
- Konfigurieren Sie das Format des Antragstellernamens (Subject name format). Für die benutzergesteuerte Authentifizierung ist
CN={{UserPrincipalName}}Standard. Für die Geräteauthentifizierung verwenden SieCN={{AAD_Device_ID}}. - Legen Sie die Schlüsselverwendung (Key usage) auf
Digitale SignaturundSchlüsselverschlüsselungfest. - Geben Sie unter Erweiterte Schlüsselverwendung (Extended key usage)
Clientauthentifizierung(OID: 1.3.6.1.5.5.7.3.2) an. - Verknüpfen Sie dieses Profil mit dem in Schritt 1 erstellten vertrauenswürdigen Root-Zertifikatsprofil.
- Geben Sie die externe URL Ihres NDES-Servers an.
Schritt 3: Bereitstellung des 802.1X WiFi-Profils
Der letzte Schritt besteht darin, die WiFi-Konfiguration bereitzustellen, die die Zertifikate mit der Netzwerk-SSID verknüpft.
- Erstellen Sie ein WiFi-Konfigurationsprofil.
- Geben Sie den Netzwerknamen (SSID) exakt so ein, wie er von Ihren Wireless Access Points übertragen wird.
- Wählen Sie WPA2-Enterprise oder WPA3-Enterprise as security type.
- 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 vertrauenswürdige Root-Zertifikat für die Servervalidierung an, um sicherzustellen, dass sich das Gerät nur mit Ihrem legitimen RADIUS-Server verbindet.

Got questions about your specific setup?
Our team works with venue operators, IT managers, and network engineers across 80,000 venues. Book a 20-minute call and we will show you how others like you solved it.
Best Practices & Branchenstandards
Halten Sie sich bei der Implementierung der Intune WiFi-Zertifikatsbereitstellung an die folgenden herstellerneutralen Best Practices, um Compliance und Zuverlässigkeit zu gewährleisten.
Platzierung und Sicherheit des NDES-Servers
Der NDES-Server muss aus dem Internet erreichbar sein, damit Remote-Geräte Zertifikate bereitstellen können, bevor sie vor Ort eintreffen. Die direkte Freigabe eines internen Servers im Internet stellt jedoch ein erhebliches Sicherheitsrisiko dar.
Empfehlung: Veröffentlichen Sie die NDES-URL über den Azure AD Application Proxy. Dies ermöglicht einen sicheren Remote-Zugriff, ohne eingehende Firewall-Ports zu öffnen, und erlaubt es Ihnen, Richtlinien für bedingten Zugriff auf den Registrierungs-Flow anzuwenden.
RADIUS- und CRL-Prüfung
Die Zertifikatsbereitstellung ist nur die halbe Miete; der Widerruf ist ebenso wichtig. Wenn ein Mitarbeiter das Unternehmen verlässt, entzieht das Deaktivieren seines Active Directory-Kontos möglicherweise nicht sofort den WiFi-Zugriff, wenn sein Client-Zertifikat gültig bleibt und der RADIUS-Server die Zertifikatsperrliste (Certificate Revocation List, CRL) nicht strikt prüft.
Empfehlung: Konfigurieren Sie Ihren Network Policy Server (NPS) oder RADIUS-Server so, dass eine strikte CRL-Prüfung erzwungen wird. Stellen Sie sicher, dass Ihre CRL-Verteilungspunkte (CDPs) hochverfügbar sind. Wenn der RADIUS-Server die CRL nicht erreichen kann, schlägt die Authentifizierung fehl, was zu einem weitreichenden Ausfall führt.
Weitere Einblicke in sicheres Netzwerkdesign finden Sie unter Die wichtigsten SD-WAN-Vorteile für moderne Unternehmen .
Fehlerbehebung & Risikominderung
Selbst bei sorgfältiger Planung können bei der Zertifikatsbereitstellung Probleme auftreten. Hier sind typische Fehlerbilder und Strategien zu deren Behebung.
Problem: WiFi-Profil kann nicht angewendet werden
Symptom: Das Gerät empfängt die vertrauenswürdigen Root- und SCEP-Zertifikate, aber das WiFi-Profil wird in Intune als 'Fehler' oder 'Nicht anwendbar' angezeigt.
Ursache: Dies wird fast immer durch eine fehlerhafte Gruppenzuweisung verursacht. Wenn das SCEP-Profil einer Benutzergruppe, das WiFi-Profil jedoch einer Gerätegruppe zugewiesen ist, kann Intune die Abhängigkeit nicht auflösen.
Behebung: Überprüfen Sie Ihre Zuweisungen. Stellen Sie sicher, dass die vertrauenswürdigen Root-, SCEP- und WiFi-Profile alle für dieselbe Azure AD-Gruppe bereitgestellt werden.
Problem: NDES 403 Forbidden-Fehler
Symptom: Geräte können das SCEP-Zertifikat nicht abrufen, und die NDES-IIS-Protokolle zeigen HTTP 403-Fehler.
Ursache: Dem Dienstkonto des Intune Certificate Connectors fehlen die erforderlichen Berechtigungen für die Zertifikatvorlage, oder die URL-Filterung auf Ihrer Firewall blockiert die spezifischen von SCEP verwendeten Abfragezeichenfolgen-Parameter.
Behebung: Überprüfen Sie, ob das Connector-Konto die Berechtigungen 'Lesen' und 'Registrieren' für die CA-Vorlage besitzt. Überprüfen Sie die Firewall-Protokolle, um sicherzustellen, dass URLs, die ?operation=GetCACaps enthalten, nicht blockiert werden.
ROI & geschäftliche Auswirkungen
Der Übergang zur 802.1X-Zertifikatsbereitstellung mit Microsoft Intune liefert messbare Vorteile für Sicherheit und Betrieb.
- Reduzierung von Helpdesk-Tickets: Passwortbasiertes WiFi verursacht ein erhebliches Aufkommen an Support-Tickets (abgelaufene Passwörter, Sperren, Tippfehler). Die zertifikatsbasierte Authentifizierung ist für den Benutzer unsichtbar und reduziert das WiFi-bezogene Helpdesk-Volumen in der Regel um 70–80 %.
- Verbesserte Sicherheitslage: EAP-TLS eliminiert das Risiko von Credential Harvesting und Man-in-the-Middle-Angriffen (MitM). Dies ist entscheidend für die Einhaltung von Frameworks wie PCI-DSS und GDPR, insbesondere im Gesundheitswesen und im Einzelhandel.
- Nahtloses Onboarding: Für Unternehmen, die neben Windows auch große Flotten von Apple-Geräten verwalten, sorgt die Integration von Intune in bestehende MDM-Workflows (siehe unseren Leitfaden zu Jamf und RADIUS: Zertifikatsbasierte WiFi-Authentifizierung für Apple-Geräteflotten ) vom ersten Tag an für eine einheitliche, berührungslose Bereitstellung (Zero-Touch-Provisioning).
Key Definitions
SCEP (Simple Certificate Enrollment Protocol)
A protocol that allows devices to request digital certificates from a Certificate Authority, where the private key is generated and stored securely on the device itself.
The recommended method for deploying WiFi authentication certificates due to its high security and scalability.
PKCS (Public Key Cryptography Standards)
A set of standards where both the public and private keys are generated by the Certificate Authority and then securely delivered to the endpoint.
Often used for S/MIME email encryption, but less ideal for WiFi due to the network transmission of the private key.
NDES (Network Device Enrollment Service)
A Microsoft Windows Server role that acts as a bridge, allowing devices without domain credentials to obtain certificates via SCEP.
A required infrastructure component when implementing SCEP certificate deployment with Microsoft Intune.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
The most secure 802.1X authentication method, requiring both the server and the client to present valid digital certificates.
The target authentication protocol that the Intune WiFi and certificate profiles are designed to enable.
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.
Critical for security; RADIUS servers must check the CRL to ensure terminated employees cannot access the WiFi using an otherwise valid certificate.
Intune Certificate Connector
A software agent installed on an on-premises Windows Server that brokers requests between Microsoft Intune and the internal Certificate Authority.
Required for both SCEP (to validate requests) and PKCS (to export keys) deployments.
Subject Alternative Name (SAN)
An extension to a digital certificate that allows multiple values (like UPN, email, or MAC address) to be associated with the certificate.
Configured in the Intune SCEP profile to ensure the RADIUS server can accurately identify the user or device.
Azure AD Application Proxy
A feature that provides secure remote access to on-premises web applications without requiring a VPN or opening inbound firewall ports.
The best practice method for securely publishing the internal NDES server URL to the internet for remote device enrollment.
Worked Examples
A national retail chain with 500 locations is migrating from WPA2-Personal (Pre-Shared Key) to WPA3-Enterprise for their store associate tablets (Android Enterprise Dedicated Devices). They use Intune for MDM. How should they architect the certificate deployment?
- Deploy an NDES server published via Azure AD App Proxy.
- Create a Device-based SCEP certificate profile in Intune, as these are dedicated (kiosk) devices not tied to a specific user. Use
CN={{AAD_Device_ID}}for the Subject Name. - Deploy the Root CA profile to the 'All Store Tablets' Azure AD Device Group.
- Deploy the SCEP profile to the same 'All Store Tablets' group.
- Create a WiFi profile configured for WPA3-Enterprise, EAP-TLS, referencing the SCEP profile, and deploy it to the same group.
- Configure the central RADIUS servers to authenticate the device certificates against the Active Directory computer objects.
A large conference centre uses Purple for their [WiFi Analytics](/products/wifi-analytics) and Guest WiFi, but needs to secure their internal staff network. Staff use a mix of corporate-owned Windows laptops and BYOD iOS devices. How do they handle the Intune deployment for the BYOD devices?
- Require BYOD users to enroll their iOS devices via Intune User Enrollment (creating a secure work partition).
- Create a User-based SCEP certificate profile using
CN={{UserPrincipalName}}. - Deploy the Root CA, SCEP, and WiFi profiles to an Azure AD User Group (e.g., 'All Staff').
- When the user enrolls their personal device, Intune pushes the profiles specifically to the managed work partition.
- The device connects to the staff SSID using the user's identity, allowing the RADIUS server to apply role-based access control (VLAN assignment) based on their AD group membership.
Practice Questions
Q1. You have deployed the Root CA, SCEP, and WiFi profiles to your Windows 10 devices. The certificates install successfully, but the WiFi profile fails to apply, showing 'Error' in the Intune console. What is the most likely cause?
Hint: Check how the profiles are assigned to Azure AD groups.
View model answer
The most likely cause is a mismatch in group targeting. If the SCEP profile was assigned to a User Group, but the WiFi profile was assigned to a Device Group, Intune cannot resolve the dependency between them. All three profiles (Root, SCEP, WiFi) must be targeted to the exact same group type.
Q2. Your security team mandates that private keys must never be transmitted across the network, even if encrypted. Which certificate deployment method must you use in Intune, and what additional infrastructure server is required?
Hint: Think about where the key pair is generated.
View model answer
You must use SCEP (Simple Certificate Enrollment Protocol). Because SCEP instructs the endpoint device to generate the private key locally, it never traverses the network. This deployment requires a Network Device Enrollment Service (NDES) server to act as a bridge to the Certificate Authority.
Q3. A remote employee provisions a new laptop at home via Windows Autopilot. The Intune profiles deploy successfully, but the device fails to obtain the SCEP certificate. What infrastructure configuration is likely missing?
Hint: How does the device reach the internal CA from the internet?
View model answer
The NDES server has likely not been published to the internet. For remote devices to request certificates before arriving at the corporate office, the NDES URL must be externally accessible, ideally published securely via Azure AD Application Proxy.
Continue reading in this series
Sophos Firewall and guest WiFi: captive portal setup with Purple
How Purple's cloud guest WiFi works with Sophos Firewall and its access points through a standard external captive portal and RADIUS, and where to check support and find the steps.
Aruba Central and Purple WiFi: Cloud-Managed Integration
A comprehensive technical reference guide for integrating Aruba Central with Purple's cloud-hosted guest WiFi intelligence platform. This guide covers architecture, step-by-step configuration of external captive portals and RADIUS, and multi-site rollout strategies for enterprise IT teams.
Azure AD and Entra ID WiFi Authentication: Integration and Configuration Guide
This technical reference guide provides IT managers, network architects, and venue operations directors with a practical roadmap for integrating Microsoft Entra ID (Azure AD) with enterprise WiFi networks using RADIUS and 802.1X. It covers the architectural decision between on-premise Windows NPS and cloud-native RADIUS, the deployment of certificate-based EAP-TLS authentication via Microsoft Intune, and the operational best practices for securing wireless access across hospitality, retail, and public-sector environments. For organisations already invested in the Microsoft 365 and Entra ID ecosystem, this guide bridges the gap between cloud identity management and physical network security.
Got questions about your specific setup?
Our team works with venue operators, IT managers, and network engineers across 80,000 venues. Book a 20-minute call and we will show you how others like you solved it.