Wie man Microsoft Intune verwendet, um WiFi-Zertifikate auf Geräte zu pushen

Eine umfassende technische Referenz für IT-Führungskräfte zur Bereitstellung von 802.1X WiFi-Zertifikaten über Microsoft Intune. Behandelt die SCEP- vs. PKCS-Architektur, Implementierungsschritte, Compliance-Mapping und reale Bereitstellungsszenarien für Unternehmensumgebungen.

📖 7 GuidesSlugPage.minRead📝 1,541 GuidesSlugPage.words🔧 2 GuidesSlugPage.workedExamples❓ 3 GuidesSlugPage.practiceQuestions📚 8 GuidesSlugPage.keyDefinitions

GuidesSlugPage.podcastTitle

GuidesSlugPage.podcastTranscript

HOW TO USE MICROSOFT INTUNE TO PUSH WIFI CERTIFICATES TO DEVICES
A Purple Enterprise WiFi Intelligence Briefing

[INTRODUCTION & CONTEXT — approximately 1 minute]

Welcome back. I'm speaking today on behalf of Purple, the enterprise WiFi intelligence platform, and this episode is a focused briefing on one of the most practical — and honestly, most underrated — capabilities in the Microsoft Intune toolkit: automated certificate deployment for 802.1X WiFi authentication.

If you're managing WiFi across a hotel estate, a retail chain, a stadium, or a public-sector estate, you'll know the pain point I'm about to describe. You've got hundreds or thousands of managed devices. You want them to connect to your corporate WiFi automatically, securely, without users typing passwords, without IT touching every single device. And you want that connection to be cryptographically strong — not just a shared password that someone's already emailed to half the organisation.

That's exactly what Intune certificate deployment solves. And in the next nine minutes, I'm going to walk you through how it works, how to deploy it, and the pitfalls that catch most teams out on the first attempt.

[TECHNICAL DEEP-DIVE — approximately 5 minutes]

Let's start with the architecture. The foundation here is IEEE 802.1X — the port-based network access control standard that's been the backbone of enterprise WiFi security for over two decades. When a device connects to your WiFi, 802.1X requires it to authenticate before it gets any network access. The authentication conversation happens between three parties: the device — called the supplicant — your WiFi access point, which acts as the authenticator, and your RADIUS server, which is the authentication server that makes the final decision.

Now, 802.1X supports multiple authentication methods. The most secure is EAP-TLS — Extensible Authentication Protocol with Transport Layer Security. EAP-TLS uses mutual certificate authentication: the device presents a certificate to prove its identity, and the RADIUS server presents a certificate to prove its identity. No passwords involved. No credentials that can be phished. This is what we're aiming for.

The challenge has always been getting those certificates onto devices at scale. That's where Microsoft Intune comes in.

Intune supports two certificate deployment mechanisms: SCEP — Simple Certificate Enrollment Protocol — and PKCS, which stands for Public Key Cryptography Standards. Understanding the difference matters.

With SCEP, the private key is generated on the device itself. The device creates a Certificate Signing Request, sends it to your Certificate Authority via an intermediary server called NDES — the Network Device Enrollment Service — and the CA issues the certificate back. The private key never leaves the device. This is the more secure approach and is recommended for BYOD environments and high-security deployments.

With PKCS, the Certificate Authority generates the key pair, and the Intune Certificate Connector delivers the private key and certificate to the device. It's simpler to set up — no NDES server required — but the private key does transit through the connector, which is a consideration for your security posture.

For most enterprise deployments I'd recommend SCEP for BYOD and mixed-device environments, and PKCS where you have a homogeneous fleet of corporate-owned Windows devices and want to minimise infrastructure complexity.

Now, let's talk about the deployment sequence — because the order matters and getting it wrong is the most common cause of failed rollouts.

Step one: configure your Certificate Authority. You need a certificate template on your Active Directory Certificate Services instance — or if you're fully cloud-native, Microsoft's Intune Cloud PKI is now generally available and removes the on-premises CA requirement entirely. The template needs the correct key usage extensions: Client Authentication is mandatory. Set the minimum key size to 2048 bits, or 4096 if your organisation's security policy requires it.

Step two: deploy the trusted root certificate. Before any device can validate the RADIUS server's certificate, it needs to trust the CA that issued it. You create a Trusted Certificate configuration profile in Intune, upload the root CA certificate, and assign it to your device groups. This must land on devices before any WiFi profile or client certificate profile. If you get the sequencing wrong, devices will reject the RADIUS server and you'll spend an afternoon staring at Event ID 20271 in the Windows event log.

Step three: deploy the client certificate profile. This is either your SCEP profile — pointing at your NDES server URL — or your PKCS profile, pointing at your Certificate Authority. The Subject Alternative Name should include the User Principal Name for user certificates, or the AAD Device ID for device certificates. This distinction matters: user certificates authenticate the logged-in user, device certificates authenticate the machine itself, which means the device can connect to WiFi before a user logs in — useful for domain join scenarios and kiosk deployments.

Step four: create the WiFi configuration profile. In Intune, this is under Devices, Configuration Profiles, Templates, Wi-Fi. Set the WiFi type to Enterprise, enter your SSID, set EAP type to EAP-TLS, configure the server trust settings — this is where you reference the RADIUS server certificate name — and for client authentication, reference the certificate profile you created in step three.

Step five: assign everything to the right groups and validate. Assign your root certificate, client certificate, and WiFi profiles to the same device or user groups. Use Intune's built-in reporting to monitor profile deployment status. A successful deployment shows all three profiles as Succeeded in the device's configuration profile list.

One critical point on NPS configuration for Windows Server environments: from early 2024, Microsoft tightened certificate mapping requirements. If you're using device certificates with Azure AD-joined devices authenticating against on-premises NPS, you need to ensure the altSecurityIdentities attribute on the computer object in Active Directory is populated with the certificate's thumbprint. This doesn't happen automatically — you need a script or a workflow to handle it, typically triggered when the CA issues a new certificate.

[IMPLEMENTATION RECOMMENDATIONS & PITFALLS — approximately 2 minutes]

Let me give you the three pitfalls that I see most frequently in enterprise deployments.

Pitfall one: certificate chain gaps. The device needs to trust every certificate in the chain from the root CA down to the RADIUS server's certificate. If your RADIUS server certificate was issued by an intermediate CA, you need to deploy both the root and the intermediate to devices. I've seen deployments fail for weeks because someone deployed the root but not the intermediate.

Pitfall two: profile assignment timing. Intune profiles don't land on devices instantaneously. In a large estate, it can take 15 to 30 minutes for profiles to propagate after assignment. Don't test immediately after creating profiles. Use the Sync button in the Intune portal to force a check-in, then wait. Also, client certificate profiles must be deployed and confirmed before the WiFi profile is applied — if the WiFi profile references a certificate that doesn't exist yet, the profile will fail silently on some platforms.

Pitfall three: BYOD certificate revocation. When a device is unenrolled from Intune — because an employee leaves, or a device is lost — you need a process to revoke the certificate. If you're using SCEP with ADCS, configure the Certificate Revocation List distribution point correctly and ensure your RADIUS server is checking CRL or OCSP on every authentication. This is a compliance requirement under frameworks like PCI DSS, which mandates that access control mechanisms be revoked promptly when no longer needed.

On the topic of compliance: if you're operating in a PCI DSS scope — retail payment environments, for example — certificate-based 802.1X authentication is your strongest control for wireless network access. It satisfies PCI DSS Requirement 1.3 around network access controls and Requirement 8.6 around authentication factors. Document your certificate lifecycle management process as part of your compliance evidence.

For GDPR-regulated environments, particularly in hospitality and public-sector, the separation between your corporate 802.1X network and your guest WiFi network is critical. Your corporate Intune-managed network should be on a completely separate VLAN and SSID from any guest or visitor network. Purple's guest WiFi platform handles the visitor-facing side — captive portal, consent capture, analytics — while your Intune-managed corporate network handles staff and operational devices. These two networks should never share authentication infrastructure.

[RAPID-FIRE Q&A — approximately 1 minute]

Let me run through a few questions that come up regularly.

Can I use Intune Cloud PKI instead of on-premises ADCS? Yes. Microsoft's Intune Cloud PKI, released in 2024, provides a fully managed CA in Azure. It removes the NDES server requirement for SCEP and simplifies the connector setup significantly. For greenfield deployments or organisations without existing ADCS infrastructure, it's the recommended path.

Does this work for macOS and iOS devices? Yes. Intune supports certificate profiles for Windows, iOS, iPadOS, Android, and macOS. The profile types and configuration options vary slightly by platform, but the core architecture — trusted root, client certificate, WiFi profile — is consistent.

What about personal devices in a BYOD programme? SCEP is your friend here. With Intune's device compliance policies, you can require that a device meets minimum security standards before a certificate is issued. If the device falls out of compliance — no screen lock, outdated OS — the certificate can be revoked and network access removed automatically.

Can Purple integrate with this architecture? Absolutely. Purple's platform sits on the guest network side, handling captive portal authentication, consent management, and analytics. The corporate 802.1X network and Purple's guest WiFi operate in parallel — same physical infrastructure, different SSIDs and VLANs — giving you complete separation between staff connectivity and visitor engagement.

[SUMMARY & NEXT STEPS — approximately 1 minute]

To wrap up: deploying WiFi certificates via Intune is a five-step process — CA configuration, trusted root deployment, client certificate profile, WiFi profile, and group assignment. Choose SCEP for BYOD and high-security environments; PKCS for simpler corporate-owned fleets. Get the sequencing right, handle the NPS certificate mapping requirement, and build a certificate revocation workflow from day one.

The business case is straightforward: you eliminate shared WiFi passwords, you get per-device and per-user authentication logs, you satisfy PCI DSS and ISO 27001 wireless security requirements, and you reduce the IT overhead of managing WiFi credentials across a large estate.

If you're planning a deployment and want to understand how Purple's guest WiFi and analytics platform fits alongside your corporate network architecture, visit purple.ai. We've got detailed guides on Azure Entra ID integration, 802.1X architecture, and guest network design for hospitality, retail, and public-sector environments.

Thanks for listening. Until next time.

GuidesSlugPage.keyTakeawaysTitle

✓EAP-TLS is the industry standard for secure enterprise WiFi, replacing vulnerable shared passwords with mutual certificate authentication.
✓Microsoft Intune automates the delivery of these certificates at scale, eliminating manual IT overhead.
✓SCEP is recommended for BYOD and high-security environments because the private key never leaves the device.
✓PKCS is suitable for corporate-owned, fully managed device fleets due to its simpler infrastructure requirements.
✓Profile sequencing is critical: always deploy the Trusted Root CA first, the Client Certificate second, and the WiFi profile last.
✓Corporate 802.1X networks must be logically separated from visitor networks (like those managed by Purple Guest WiFi) to maintain security boundaries.
✓For Windows NPS environments, ensure the Active Directory computer object's altSecurityIdentities attribute is mapped to the device certificate to prevent authentication failures.

Zusammenfassung für Führungskräfte

Für IT-Führungskräfte in Unternehmen, die große Umgebungen in den Bereichen Hospitality , Retail oder im öffentlichen Sektor verwalten, ist ein sicherer drahtloser Zugang eine grundlegende betriebliche Anforderung. Das Vertrauen auf gemeinsame PSKs (Pre-Shared Keys) oder Benutzername-/Passwort-Authentifizierung (PEAP-MSCHAPv2) setzt das Netzwerk Diebstahl von Anmeldeinformationen, Phishing und Compliance-Verstößen aus. Der Industriestandard für robuste Unternehmens-WiFi-Sicherheit ist 802.1X mit EAP-TLS (Extensible Authentication Protocol mit Transport Layer Security), der eine gegenseitige zertifikatbasierte Authentifizierung zwischen dem Gerät und dem Netzwerk vorschreibt.

Die größte Hürde für die Einführung von EAP-TLS war jedoch historisch der operative Aufwand des Zertifikats-Lebenszyklus-Managements. Microsoft Intune löst dies, indem es die Bereitstellung, Erneuerung und den Widerruf digitaler Zertifikate für verwaltete Geräte im großen Maßstab automatisiert.

Diese technische Referenz beschreibt die Architektur, Bereitstellungsmethoden (SCEP vs. PKCS) und Implementierungsschritte, die erforderlich sind, um WiFi-Zertifikate über Microsoft Intune zu pushen. Sie bietet umsetzbare Anleitungen für Netzwerkarchitekten und Systemingenieure, die für die Sicherung der Unternehmenskommunikation zuständig sind, während eine strikte Trennung von Besuchernetzwerken, wie sie von einer Guest WiFi -Plattform verwaltet werden, aufrechterhalten wird.

Technischer Deep-Dive: Architektur und Protokolle

Um eine zertifikatbasierte Authentifizierung effektiv zu implementieren, müssen IT-Teams die Interaktion zwischen der Mobile Device Management (MDM)-Plattform, der Public Key Infrastructure (PKI) und der Netzwerkzugriffskontrollschicht verstehen.

Das 802.1X Authentifizierungs-Framework

Der IEEE 802.1X-Standard definiert die portbasierte Netzwerkzugriffskontrolle. In einem drahtlosen Kontext verhindert er, dass ein Gerät jeglichen Datenverkehr (außer EAP-Authentifizierungs-Frames) sendet, bis seine Identität überprüft wurde. Die Architektur besteht aus drei Komponenten:

Supplicant: Das Client-Gerät (Laptop, Smartphone, Tablet), das Netzwerkzugriff anfordert.
Authenticator: Der drahtlose Access Point oder Wireless LAN Controller, der den Datenverkehr blockiert, bis die Authentifizierung erfolgreich ist.
Authentifizierungsserver: Der RADIUS (Remote Authentication Dial-In User Service)-Server, wie z.B. Microsoft Network Policy Server (NPS) oder Cisco ISE, der die Anmeldeinformationen validiert und den Zugriff autorisiert.

EAP-TLS und gegenseitige Authentifizierung

EAP-TLS ist die sicherste EAP-Methode, da sie eine gegenseitige Authentifizierung erfordert. Der RADIUS-Server präsentiert sein Zertifikat dem Supplicant, um zu beweisen, dass es sich um das legitime Unternehmensnetzwerk handelt (was Evil-Twin-Angriffe verhindert), und der Supplicant präsentiert sein Client-Zertifikat dem RADIUS-Server, um zu beweisen, dass es sich um ein autorisiertes Gerät oder einen autorisierten Benutzer handelt.

Intune Zertifikatsbereitstellungsmechanismen: SCEP vs. PKCS

Microsoft Intune unterstützt zwei primäre Protokolle für die Bereitstellung von Client-Zertifikaten auf Geräten. Die Auswahl des geeigneten Mechanismus ist eine kritische architektonische Entscheidung.

Simple Certificate Enrollment Protocol (SCEP)

Mit SCEP wird der private Schlüssel direkt auf dem Client-Gerät generiert. Das Gerät erstellt eine Certificate Signing Request (CSR) und übermittelt diese über Intune an den Network Device Enrollment Service (NDES)-Server, der als Proxy zur Active Directory Certificate Services (ADCS)-Infrastruktur fungiert. Die CA stellt das Zertifikat aus, das an das Gerät zurückgegeben wird.

Da der private Schlüssel das Gerät nie verlässt, gilt SCEP als hochsicher und ist der empfohlene Ansatz für BYOD (Bring Your Own Device)-Bereitstellungen und Zero-Trust-Architekturen.

Public Key Cryptography Standards (PKCS)

Mit PKCS fordert der Intune Certificate Connector das Zertifikat im Namen des Geräts von der CA an. Die CA generiert sowohl das öffentliche Zertifikat als auch den privaten Schlüssel, die der Connector dann sicher über Intune an das Gerät liefert.

Während PKCS die Infrastrukturanforderungen vereinfacht (kein NDES-Server erforderlich), wird der private Schlüssel über das Netzwerk übertragen. Dieses Modell ist im Allgemeinen für unternehmenseigene, vollständig verwaltete Geräteflotten akzeptabel, bei denen die MDM-Plattform bereits eine hochvertrauenswürdige Komponente ist.

Implementierungsleitfaden: Schritt-für-Schritt-Bereitstellung

Die Bereitstellung von WiFi-Zertifikaten über Intune erfordert eine präzise Reihenfolge. Das Bereitstellen von Profilen in falscher Reihenfolge ist die häufigste Ursache für Implementierungsfehler.

Schritt 1: Vorbereiten der Public Key Infrastructure (PKI)

Unabhängig davon, ob eine lokale ADCS oder eine Cloud-native Lösung wie Microsoft Cloud PKI verwendet wird, muss die Zertifizierungsstelle mit den entsprechenden Vorlagen konfiguriert werden.

Schlüsselverwendung: Die Vorlage muss die OID Client Authentication (1.3.6.1.5.5.7.3.2) enthalten.
Schlüsselgröße: Konfigurieren Sie eine minimale Schlüsselgröße von 2048 Bit (RSA), um den modernen kryptografischen Standards zu entsprechen.
Antragstellername: Für Benutzerzertifikate sollte der Subject Alternative Name (SAN) so konfiguriert werden, dass er den User Principal Name (UPN) verwendet. Für Gerätezertifikate verwenden Sie die Azure AD Device ID.

Schritt 2: Bereitstellen des vertrauenswürdigen Stammzertifikats

Bevor ein Gerät authentifiziert werden kann, muss es der CA vertrauen, die das Zertifikat des RADIUS-Servers ausgestellt hat.

Exportieren Sie das Stamm-CA-Zertifikat (und alle Zwischen-CA-Zertifikate) im Format `.cer`` format.
Navigieren Sie im Intune Admin Center zu Geräte > Konfigurationsprofile > Profil erstellen.
Wählen Sie die Plattform und den Profiltyp Vertrauenswürdiges Zertifikat.
Laden Sie die .cer-Datei hoch und weisen Sie das Profil dem Zielgerät oder den Benutzergruppen zu.

Hinweis: Dieses Profil muss erfolgreich auf die Geräte angewendet werden, bevor Sie mit den nächsten Schritten fortfahren.

Schritt 3: Clientzertifikatsprofil bereitstellen

Erstellen Sie entweder ein SCEP- oder PKCS-Zertifikatsprofil, um das Identitätszertifikat an den Anfragenden zu übermitteln.

Navigieren Sie zu Geräte > Konfigurationsprofile > Profil erstellen.
Wählen Sie die Plattform und entweder SCEP-Zertifikat oder PKCS-Zertifikat.
Konfigurieren Sie das Format des Antragstellernamens (Subject Name) und SAN gemäß Ihren Identitätsanforderungen (Benutzer vs. Gerät).
Geben Sie den Key Storage Provider (KSP) an – typischerweise das Trusted Platform Module (TPM) für hardwaregestützte Sicherheit.
Weisen Sie das Profil denselben Gruppen zu, die in Schritt 2 festgelegt wurden.

Schritt 4: Das WiFi-Profil konfigurieren

Die letzte Komponente verknüpft die Zertifikate mit den Einstellungen des drahtlosen Netzwerks.

Navigieren Sie zu Geräte > Konfigurationsprofile > Profil erstellen.
Wählen Sie die Plattform und den Profiltyp Wi-Fi.
Stellen Sie den Wi-Fi-Typ auf Enterprise ein und geben Sie die genaue SSID ein.
Stellen Sie den EAP-Typ auf EAP-TLS ein.
Unter Serververtrauen geben Sie den genauen Namen des RADIUS-Serverzertifikats an und wählen das in Schritt 2 bereitgestellte Profil für vertrauenswürdige Stammzertifikate aus.
Unter Clientauthentifizierung wählen Sie das in Schritt 3 bereitgestellte SCEP- oder PKCS-Zertifikatsprofil aus.
Weisen Sie das Profil den Zielgruppen zu.

Best Practices & Strategische Empfehlungen

Geräte- vs. Benutzerzertifikate

Netzwerkarchitekten müssen entscheiden, ob Zertifikate für das Gerät (Maschinenauthentifizierung) oder den Benutzer (Benutzerauthentifizierung) ausgestellt werden sollen.

Gerätezertifikate: Ermöglichen es dem Gerät, sich mit dem WiFi-Netzwerk zu verbinden, bevor sich ein Benutzer anmeldet. Dies ist entscheidend für die anfängliche Gerätebereitstellung, die Verarbeitung von Gruppenrichtlinien und das Zurücksetzen von Passwörtern am Anmeldebildschirm. Empfohlen für unternehmenseigene Geräte.
Benutzerzertifikate: Verknüpfen den Netzwerkzugriff mit der Identität des Einzelnen. Dies ermöglicht eine detaillierte Überwachung und rollenbasierte Zugriffskontrolle. Empfohlen für BYOD-Szenarien.

Netzwerksegmentierung und Gastzugang

Ein fundamentales Sicherheitsprinzip ist die strikte logische Trennung des Unternehmens-802.1X-Netzwerks von Besucher- oder öffentlichen Zugangsnetzwerken. Die von Intune verwaltete Infrastruktur sollte ausschließlich Unternehmensgeräten und authentifiziertem Personal vorbehalten sein.

Für den Besucherzugang sollten Organisationen eine dedizierte Guest WiFi SSID bereitstellen, die durch ein Captive Portal unterstützt wird. Dies stellt sicher, dass nicht verwaltete Geräte isoliert sind, während das Unternehmen weiterhin Besucheranalysen über eine WiFi Analytics Plattform erfassen kann. Um mehr über die Absicherung der DNS-Infrastruktur in beiden Segmenten zu erfahren, lesen Sie unseren Leitfaden zum Thema Schützen Sie Ihr Netzwerk mit starkem DNS und Sicherheit .

Anforderung der NPS-Zertifikatszuordnung berücksichtigen

Für Organisationen, die Microsoft Network Policy Server (NPS) mit in Azure AD eingebundenen Geräten verwenden, wurde von Microsoft eine kritische Konfigurationsänderung eingeführt. NPS erfordert nun eine starke Zertifikatszuordnung.

Bei der Verwendung von Gerätezertifikaten muss das Computerobjekt im lokalen Active Directory sein altSecurityIdentities-Attribut mit den Details des Zertifikats (typischerweise der X509IssuerSerialNumber) gefüllt haben. IT-Teams müssen ein geplantes Skript oder einen ereignisgesteuerten Workflow implementieren, um dieses Attribut zu aktualisieren, wenn Intune ein neues Zertifikat ausstellt, da sonst die Authentifizierung fehlschlägt.

Fehlerbehebung & Risikominderung

Wenn eine 802.1X-Bereitstellung fehlschlägt, liegt das Problem fast immer in der Zertifikatskette oder der Reihenfolge der Intune-Profile.

Häufige Fehlerursachen

Stiller WiFi-Profilfehler: Wenn das Intune WiFi-Profil auf einem Gerät angewendet wird, bevor das Clientzertifikat erfolgreich bereitgestellt wurde, schlägt die Installation des WiFi-Profils oft fehl oder schlägt stillschweigend fehl. Überprüfen Sie immer die Anwesenheit des Zertifikats im persönlichen Speicher des Geräts (certmgr.msc unter Windows), bevor Sie die WiFi-Konfiguration beheben.
Fehler bei der Serververtrauensvalidierung: Wenn das Gerät den RADIUS-Server ablehnt, überprüfen Sie, ob der im Intune WiFi-Profil angegebene Servername exakt mit dem Antragstellernamen (Subject Name) oder SAN auf dem Zertifikat des RADIUS-Servers übereinstimmt. Stellen Sie außerdem sicher, dass die gesamte Zertifikatskette (Stamm- und Zwischenzertifikate) im Speicher der vertrauenswürdigen Stammzertifizierungsstellen des Geräts vorhanden ist.
Nichtverfügbarkeit der Zertifikatsperrliste (CRL): Wenn der RADIUS-Server den CRL-Verteilungspunkt der CA nicht erreichen kann, um den Status des Clientzertifikats zu überprüfen, wird die Authentifizierung verweigert. Stellen Sie sicher, dass die CRL-URL hochverfügbar und vom RADIUS-Server aus zugänglich ist.

ROI & Geschäftsauswirkungen

Der Übergang zur zertifikatsbasierten WiFi-Authentifizierung über Intune liefert erhebliche betriebliche und sicherheitstechnische Vorteile.

Risikominderung: Eliminiert das Risiko von Credential Harvesting, Pass-the-Hash-Angriffen und unbefugtem Netzwerkzugriff über gemeinsam genutzte PSKs.
Operative Effizienz: Reduziert IT-Helpdesk-Tickets im Zusammenhang mit abgelaufenen Passwörtern und WiFi-Verbindungsproblemen. Das automatisierte Lebenszyklusmanagement bedeutet, dass Zertifikate transparent und ohne Benutzereingriff erneuert werden.
Compliance-Ermöglichung: Erfüllt strenge regulatorische Anforderungen. Für Einzelhandelsumgebungen adressiert es direkt die PCI DSS-Anforderungen für robuste drahtlose Verschlüsselung und Authentifizierung. Für den öffentlichen Sektor und das Gesundheitswesen entspricht es den Prinzipien des Zero-Trust Network Access (ZTNA).

Durch den Einsatz von Microsoft Intune für die Zertifikatsbereitstellung können IT-Teams eine reibungslose, hochsichere drahtlose Erfahrung erzielen, die im Hintergrund geräuschlos funktioniert und es dem Unternehmen ermöglicht, sich auf die Kernoperationen zu konzentrieren.

GuidesSlugPage.keyDefinitionsTitle

802.1X

An IEEE standard for port-based network access control that prevents unauthorized devices from accessing a LAN or WLAN until they successfully authenticate.

The foundational security protocol that replaces shared WiFi passwords with enterprise-grade authentication in corporate environments.

EAP-TLS

Extensible Authentication Protocol with Transport Layer Security. An authentication framework that requires both the client and the server to prove their identities using digital certificates.

The specific protocol configured in the Intune WiFi profile to enforce mutual certificate authentication, eliminating the risk of credential theft.

SCEP

Simple Certificate Enrollment Protocol. A mechanism where the client device generates its own private key and requests a certificate from the CA via an intermediary server.

The preferred deployment method for BYOD environments because the private key is never transmitted across the network.

PKCS

Public Key Cryptography Standards. In the context of Intune, a deployment method where the CA generates the private key and the Intune Connector securely delivers it to the device.

A simpler deployment architecture often used for corporate-owned device fleets, as it removes the need for an NDES server.

NDES

Network Device Enrollment Service. A Microsoft server role that acts as a proxy, allowing devices running without domain credentials to obtain certificates from an Active Directory Certificate Authority.

A mandatory infrastructure component when deploying certificates via SCEP in an on-premises ADCS environment.

RADIUS

Remote Authentication Dial-In User Service. A networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management.

The server (like Microsoft NPS or Cisco ISE) that receives the authentication request from the WiFi access point and validates the device's certificate.

Supplicant

The software client on the end-user device (laptop, smartphone) that initiates the 802.1X authentication process.

The Intune WiFi profile configures the native OS supplicant (e.g., Windows WLAN AutoConfig) to use the correct certificates and EAP methods.

Certificate Revocation List (CRL)

A digitally signed list published by the Certificate Authority containing the serial numbers of certificates that have been revoked and should no longer be trusted.

Crucial for security compliance; the RADIUS server must check the CRL to ensure a connecting device hasn't been reported lost or stolen.

GuidesSlugPage.workedExamplesTitle

A 400-location retail chain is deploying corporate-owned tablets for inventory management. The devices are fully managed via Intune and joined to Azure AD. They need immediate network access upon boot to sync inventory databases, before any specific user logs in. The network infrastructure uses Cisco ISE as the RADIUS server. What is the optimal certificate deployment strategy?

The IT team should implement PKCS device certificates.

Configure a device certificate template on the CA.
Deploy the Root CA certificate to the tablets via Intune.
Create a PKCS certificate profile in Intune, setting the Subject Name format to the Azure AD Device ID ({{AAD_Device_ID}}).
Create an Enterprise WiFi profile specifying EAP-TLS, referencing the ISE server's certificate name and the deployed PKCS profile.
Assign all profiles to the device group containing the tablets.

GuidesSlugPage.examinerCommentary PKCS is appropriate here because the devices are corporate-owned and fully managed, reducing the risk associated with private key transit. Device certificates are mandatory because the tablets require network access prior to user login. By targeting the Azure AD Device ID, Cisco ISE can authenticate the specific hardware asset and assign it to the correct restricted inventory VLAN.

A large teaching hospital allows medical staff to use their personal smartphones (BYOD) to access clinical scheduling applications. The devices are enrolled in Intune via a Work Profile. Security policy mandates that no corporate credentials be stored on personal devices, and network access must be revoked immediately if a device is compromised. How should the WiFi authentication be designed?

The hospital must implement SCEP user certificates combined with Intune Compliance Policies.

Deploy an NDES server to proxy requests to the CA.
Create a SCEP user certificate profile in Intune, with the SAN configured to the User Principal Name ({{UserPrincipalName}}).
Create an Intune Compliance Policy requiring a minimum OS version, an active screen lock, and no jailbreak/root access.
Configure the CA to publish a highly available Certificate Revocation List (CRL).
Configure the RADIUS server to strictly enforce CRL checking on every authentication attempt.

GuidesSlugPage.examinerCommentary SCEP is the only acceptable choice for BYOD because the private key is generated on the personal device and cannot be intercepted. User certificates are required to tie network activity to the specific clinician for HIPAA/GDPR auditing. The critical component is the integration with Intune Compliance Policies; if a device becomes non-compliant, Intune can trigger certificate revocation, and the RADIUS server's CRL check will immediately block network access.

GuidesSlugPage.practiceQuestionsTitle

Q1. Your organisation is migrating from PEAP-MSCHAPv2 (username/password) to EAP-TLS for the corporate WiFi. During the pilot phase, several Windows 11 laptops receive the Intune configuration profiles successfully but fail to connect to the network. Reviewing the Windows Event Logs shows Event ID 20271 indicating the RADIUS server certificate was rejected. What is the most likely cause?

GuidesSlugPage.hintPrefixConsider the chain of trust required for mutual authentication.

GuidesSlugPage.viewModelAnswer

The devices lack the Trusted Root CA certificate that issued the RADIUS server's certificate. In EAP-TLS, the device must validate the RADIUS server's identity. The IT team must ensure the 'Trusted certificate' profile containing the Root CA (and any Intermediate CAs) is deployed to the devices via Intune and successfully installed before the WiFi profile attempts to connect.

Q2. A public sector venue is deploying 802.1X for staff devices using Intune and PKCS certificates. They also operate a separate visitor network managed by a Guest WiFi platform. An auditor notes that if a staff laptop is stolen, the certificate remains valid for 12 months. How should the network architect address this risk?

GuidesSlugPage.hintPrefixHow does the authentication server know a certificate is no longer valid before it expires?

GuidesSlugPage.viewModelAnswer

The architect must implement a robust Certificate Revocation workflow. First, ensure the CA publishes a Certificate Revocation List (CRL) to a highly available distribution point. Second, configure the RADIUS server (e.g., NPS) to mandate CRL checking during every authentication attempt. Finally, establish an Intune operational procedure to explicitly revoke the certificate of any device marked as lost or stolen, which updates the CRL and blocks network access.

Q3. You are designing the Intune deployment for a fleet of shared kiosk devices in a retail environment. These devices reboot daily and must immediately connect to the corporate network to download updates before any user interacts with them. Should you deploy User certificates or Device certificates, and what Subject Alternative Name (SAN) format should be used?

GuidesSlugPage.hintPrefixConsider the state of the device immediately after a reboot.

GuidesSlugPage.viewModelAnswer

You must deploy Device certificates. Because the kiosks need network access before a user logs in, a User certificate would be unavailable at boot time. The Subject Alternative Name (SAN) in the Intune certificate profile should be configured to use the Azure AD Device ID ({{AAD_Device_ID}}) or the device's fully qualified domain name, allowing the RADIUS server to authenticate the specific hardware asset.