Comment utiliser Microsoft Intune pour déployer des certificats WiFi sur les appareils

Une référence technique complète pour les responsables informatiques sur le déploiement des certificats WiFi 802.1X via Microsoft Intune. Couvre l'architecture SCEP vs PKCS, les étapes de mise en œuvre, la cartographie de la conformité et les scénarios de déploiement réels pour les environnements d'entreprise.

📖 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.

Résumé Exécutif

Pour les responsables informatiques d'entreprise gérant des environnements à grande échelle dans les secteurs de l' Hôtellerie , du Commerce de détail ou les lieux du secteur public, un accès sans fil sécurisé est une exigence opérationnelle fondamentale. S'appuyer sur des PSK partagées (clés pré-partagées) ou une authentification par nom d'utilisateur/mot de passe (PEAP-MSCHAPv2) expose le réseau au vol d'identifiants, au phishing et aux échecs de conformité. La norme industrielle pour une sécurité WiFi d'entreprise robuste est le 802.1X avec EAP-TLS (Extensible Authentication Protocol avec Transport Layer Security), qui exige une authentification mutuelle basée sur des certificats entre l'appareil et le réseau.

Cependant, le principal obstacle à l'adoption d'EAP-TLS a toujours été la surcharge opérationnelle de la gestion du cycle de vie des certificats. Microsoft Intune résout ce problème en automatisant la livraison, le renouvellement et la révocation des certificats numériques aux appareils gérés à grande échelle.

Cette référence technique détaille l'architecture, les méthodologies de déploiement (SCEP vs PKCS) et les étapes de mise en œuvre requises pour déployer des certificats WiFi via Microsoft Intune. Elle fournit des conseils exploitables aux architectes réseau et aux ingénieurs systèmes chargés de sécuriser les communications d'entreprise tout en maintenant une séparation stricte des réseaux visiteurs, tels que ceux gérés par une plateforme Guest WiFi .

Plongée Technique : Architecture et Protocoles

Pour implémenter efficacement l'authentification basée sur des certificats, les équipes informatiques doivent comprendre l'interaction entre la plateforme de gestion des appareils mobiles (MDM), l'infrastructure à clé publique (PKI) et la couche de contrôle d'accès réseau.

Le Cadre d'Authentification 802.1X

La norme IEEE 802.1X définit le contrôle d'accès réseau basé sur les ports. Dans un contexte sans fil, elle empêche un appareil de transmettre tout trafic (autre que les trames d'authentification EAP) tant que son identité n'est pas vérifiée. L'architecture se compose de trois composants :

Demandeur : L'appareil client (ordinateur portable, smartphone, tablette) demandant l'accès au réseau.
Authentificateur : Le point d'accès sans fil ou le contrôleur de réseau local sans fil qui bloque le trafic jusqu'à ce que l'authentification réussisse.
Serveur d'Authentification : Le serveur RADIUS (Remote Authentication Dial-In User Service), tel que Microsoft Network Policy Server (NPS) ou Cisco ISE, qui valide les identifiants et autorise l'accès.

EAP-TLS et Authentification Mutuelle

EAP-TLS est la méthode EAP la plus sécurisée car elle nécessite une authentification mutuelle. Le serveur RADIUS présente son certificat au demandeur pour prouver qu'il s'agit du réseau d'entreprise légitime (prévenant les attaques de type « evil twin »), et le demandeur présente son certificat client au serveur RADIUS pour prouver qu'il s'agit d'un appareil ou d'un utilisateur autorisé.

Mécanismes de Déploiement de Certificats Intune : SCEP vs PKCS

Microsoft Intune prend en charge deux protocoles principaux pour le déploiement de certificats clients sur les appareils. Le choix du mécanisme approprié est une décision architecturale critique.

Protocole Simple d'Enrôlement de Certificats (SCEP)

Avec SCEP, la clé privée est générée directement sur l'appareil client. L'appareil crée une demande de signature de certificat (CSR) et la soumet via Intune au serveur Network Device Enrollment Service (NDES), qui agit comme un proxy pour l'infrastructure Active Directory Certificate Services (ADCS). L'autorité de certification (CA) émet le certificat, qui est renvoyé à l'appareil.

Étant donné que la clé privée ne quitte jamais l'appareil, SCEP est considéré comme très sécurisé et est l'approche recommandée pour les déploiements BYOD (Bring Your Own Device) et les architectures de confiance zéro.

Normes de Cryptographie à Clé Publique (PKCS)

Avec PKCS, le connecteur de certificats Intune demande le certificat à l'autorité de certification (CA) au nom de l'appareil. L'autorité de certification (CA) génère à la fois le certificat public et la clé privée, que le connecteur livre ensuite en toute sécurité à l'appareil via Intune.

Bien que PKCS simplifie les exigences d'infrastructure (aucun serveur NDES n'est nécessaire), la clé privée est transmise sur le réseau. Ce modèle est généralement acceptable pour les flottes d'appareils appartenant à l'entreprise et entièrement gérées, où la plateforme MDM est déjà un composant hautement fiable.

Guide d'Implémentation : Déploiement Étape par Étape

Le déploiement de certificats WiFi via Intune nécessite un séquençage précis. Le déploiement de profils dans le désordre est la cause la plus fréquente d'échec de mise en œuvre.

Étape 1 : Préparer l'Infrastructure à Clé Publique (PKI)

Qu'il s'agisse d'utiliser ADCS sur site ou une solution cloud native comme Microsoft Cloud PKI, l'autorité de certification doit être configurée avec les modèles appropriés.

Utilisation de la Clé : Le modèle doit inclure l'OID Client Authentication (1.3.6.1.5.5.7.3.2).
Taille de la Clé : Configurez une taille de clé minimale de 2048 bits (RSA) pour vous aligner sur les normes cryptographiques modernes.
Nom du Sujet : Pour les certificats utilisateur, le nom alternatif du sujet (SAN) doit être configuré pour utiliser le nom d'utilisateur principal (UPN). Pour les certificats d'appareil, utilisez l'ID d'appareil Azure AD.

Étape 2 : Déployer le Certificat Racine de Confiance

Avant qu'un appareil ne puisse s'authentifier, il doit faire confiance à l'autorité de certification (CA) qui a émis le certificat du serveur RADIUS.

Exportez le certificat de l'autorité de certification racine (et tout certificat d'autorité de certification intermédiaire) au format `.cer`` format.
Dans le centre d'administration Intune, accédez à Appareils > Profils de configuration > Créer un profil.
Sélectionnez la plateforme et choisissez le type de profil Certificat approuvé.
Téléchargez le fichier .cer et attribuez le profil à l'appareil cible ou aux groupes d'utilisateurs.

Remarque : Ce profil doit s'appliquer avec succès aux appareils avant de passer aux étapes suivantes.

Étape 3 : Déployer le profil de certificat client

Créez un profil de certificat SCEP ou PKCS pour délivrer le certificat d'identité au demandeur.

Accédez à Appareils > Profils de configuration > Créer un profil.
Sélectionnez la plateforme et choisissez Certificat SCEP ou Certificat PKCS.
Configurez le format du nom du sujet et le SAN selon vos exigences d'identité (Utilisateur ou Appareil).
Spécifiez le fournisseur de stockage de clés (KSP) — généralement le Trusted Platform Module (TPM) pour une sécurité matérielle.
Attribuez le profil aux mêmes groupes ciblés à l'étape 2.

Étape 4 : Configurer le profil WiFi

Le composant final lie les certificats aux paramètres du réseau sans fil.

Accédez à Appareils > Profils de configuration > Créer un profil.
Sélectionnez la plateforme et choisissez le type de profil Wi-Fi.
Définissez le type de Wi-Fi sur Entreprise et entrez le SSID exact.
Définissez le type EAP sur EAP-TLS.
Sous Approbation du serveur, spécifiez le nom exact du certificat du serveur RADIUS et sélectionnez le profil de certificat racine approuvé déployé à l'étape 2.
Sous Authentification client, sélectionnez le profil de certificat SCEP ou PKCS déployé à l'étape 3.
Attribuez le profil aux groupes cibles.

Bonnes pratiques et recommandations stratégiques

Certificats d'appareil vs. d'utilisateur

Les architectes réseau doivent décider s'il faut émettre des certificats à l'appareil (authentification machine) ou à l'utilisateur (authentification utilisateur).

Certificats d'appareil : Permettent à la machine de se connecter au réseau WiFi avant qu'un utilisateur ne se connecte. Ceci est essentiel pour le provisionnement initial de l'appareil, le traitement des stratégies de groupe et les réinitialisations de mot de passe à l'écran de connexion. Recommandé pour les appareils appartenant à l'entreprise.
Certificats d'utilisateur : Lient l'accès réseau à l'identité de l'individu. Cela offre un audit granulaire et un contrôle d'accès basé sur les rôles. Recommandé pour les scénarios BYOD.

Segmentation du réseau et accès invité

Un principe de sécurité fondamental est la stricte séparation logique du réseau d'entreprise 802.1X des réseaux d'accès visiteurs ou publics. L'infrastructure gérée par Intune doit être dédiée exclusivement aux appareils d'entreprise et au personnel authentifié.

Pour l'accès des visiteurs, les organisations doivent déployer un SSID Guest WiFi dédié, soutenu par un Captive Portal. Cela garantit que les appareils non gérés sont isolés, tout en permettant à l'entreprise de capturer des analyses de visiteurs via une plateforme WiFi Analytics . Pour en savoir plus sur la sécurisation de l'infrastructure DNS sur les deux segments, consultez notre guide sur la façon de Protéger votre réseau avec un DNS et une sécurité robustes .

Traiter l'exigence de mappage de certificat NPS

Pour les organisations utilisant Microsoft Network Policy Server (NPS) avec des appareils joints à Azure AD, un changement de configuration critique a été introduit par Microsoft. NPS exige désormais un mappage de certificat fort.

Lors de l'utilisation de certificats d'appareil, l'objet ordinateur dans l'Active Directory local doit avoir son attribut altSecurityIdentities renseigné avec les détails du certificat (généralement le X509IssuerSerialNumber). Les équipes informatiques doivent implémenter un script planifié ou un flux de travail basé sur les événements pour mettre à jour cet attribut lorsqu'Intune émet un nouveau certificat, sinon l'authentification échouera.

Dépannage et atténuation des risques

Lorsqu'un déploiement 802.1X échoue, le problème réside presque toujours dans la chaîne de certificats ou le séquençage du profil Intune.

Modes de défaillance courants

Échec silencieux du profil WiFi : Si le profil WiFi Intune est appliqué à un appareil avant que le certificat client n'ait été provisionné avec succès, le profil WiFi échouera souvent à s'installer ou échouera silencieusement. Vérifiez toujours la présence du certificat dans le magasin personnel de l'appareil (certmgr.msc sous Windows) avant de dépanner la configuration WiFi.
Erreurs de validation de l'approbation du serveur : Si l'appareil rejette le serveur RADIUS, vérifiez que le nom du serveur spécifié dans le profil WiFi Intune correspond exactement au nom du sujet ou au SAN sur le certificat du serveur RADIUS. De plus, assurez-vous que toute la chaîne de certificats (racine et intermédiaire) est présente dans le magasin des autorités de certification racines approuvées de l'appareil.
Indisponibilité de la liste de révocation de certificats (CRL) : Si le serveur RADIUS ne peut pas atteindre le point de distribution CRL de l'AC pour vérifier l'état du certificat client, l'authentification sera refusée. Assurez-vous que l'URL de la CRL est hautement disponible et accessible depuis le serveur RADIUS.

ROI et impact commercial

La transition vers l'authentification WiFi basée sur les certificats via Intune offre des retours opérationnels et de sécurité significatifs.

Atténuation des risques : Élimine le risque de vol d'identifiants, d'attaques pass-the-hash et d'accès réseau non autorisé via des PSK partagés.
Efficacité opérationnelle : Réduit les tickets du support informatique liés aux expirations de mot de passe et aux problèmes de connectivité WiFi. La gestion automatisée du cycle de vie signifie que les certificats sont renouvelés de manière transparente sans intervention de l'utilisateur.
Facilitation de la conformité : Satisfait aux exigences réglementaires strictes. Pour les environnements de vente au détail, elle répond directement aux exigences PCI DSS en matière de chiffrement et d'authentification sans fil robustes. Pour le secteur public et la santé, elle s'aligne sur les principes d'accès réseau Zero Trust (ZTNA).

En tirant parti de Microsoft Intune pour le déploiement de certificats, les équipes informatiques peuvent offrir une expérience sans fil fluide et hautement sécurisée qui fonctionne silencieusement en arrière-plan, permettant à l'entreprise de se concentrer sur ses opérations principales.

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.