Le guide de l'entreprise pour SCEP : Déployer Simple Certificate Enrollment Protocol pour une sécurité WiFi automatisée des campus

Ce guide de référence technique fournit un modèle d'architecture définitif et une stratégie de mise en œuvre étape par étape pour le déploiement de certificats WiFi d'entreprise à l'aide de SCEP. Il couvre les différences critiques entre SCEP et PKCS, la séquence de déploiement exacte requise pour réussir, et des stratégies concrètes de réduction des risques pour les responsables informatiques.

📖 6 min de lecture📝 1,270 mots🔧 2 exemples concrets❓ 3 questions d'entraînement📚 8 définitions clés

Écouter ce guide

Voir la transcription du podcast

Good morning. If you're managing WiFi infrastructure across a hotel group, a retail estate, a stadium, or a university campus, this briefing is for you. We're going to cover SCEP - Simple Certificate Enrollment Protocol - and specifically how it solves one of the most persistent headaches in enterprise WiFi: getting certificates onto thousands of devices automatically, without your helpdesk drowning in tickets.

[short pause]

Let me set the scene. You've decided - correctly - that pre-shared keys are no longer acceptable for staff WiFi. A single compromised password exposes your entire network segment. You've moved, or you're moving, to 802.1X authentication. That's the IEEE standard that requires every device to prove its identity before it gets network access. The most secure flavour of 802.1X is EAP-TLS - Extensible Authentication Protocol with Transport Layer Security - which uses digital certificates rather than passwords. Certificates are cryptographically unique per device, they can't be shared, and they can be revoked instantly if a device is lost or an employee leaves.

[short pause]

So far, so good. The problem is distribution. How do you get a unique certificate onto every laptop, every phone, every tablet in your estate - across Windows, iOS, Android, macOS - without a technician touching each device? That's precisely what SCEP solves.

[medium pause]

SCEP was formalised by the Internet Engineering Task Force in RFC 8894 in 2020, though it's been in use in enterprise environments since the early 2000s. It's a protocol that lets a managed device request its own certificate directly from your Certificate Authority, using a pre-configured URL and a challenge password. The critical security point here: the private key is generated on the device itself, stored in the device's secure enclave - that's the TPM chip on Windows devices, or the Secure Enclave on Apple hardware - and it never travels across the network. The device generates a Certificate Signing Request, sends that to the SCEP gateway, the gateway validates the challenge, forwards the request to your Certificate Authority, the CA signs it, and the signed certificate comes back to the device. The whole process is invisible to the end user.

[short pause]

Now, in a Microsoft environment, the SCEP gateway is typically NDES - Network Device Enrollment Service - a Windows Server role that acts as the intermediary between your MDM platform and your CA. Microsoft Intune pushes the SCEP profile to managed devices, which tells them the NDES URL and the challenge password. Devices do the rest automatically.

[medium pause]

Let me walk you through what a real deployment looks like. Take a hotel group with 150 properties - think Premier Inn scale. They have a mix of Windows laptops for front-of-house staff, iOS devices for housekeeping supervisors, and Android tablets at the restaurant point-of-sale. Before SCEP, they were running WPA2-Personal with a shared password rotated quarterly. Every rotation generated a wave of helpdesk calls. With SCEP and Intune, they deploy three profiles in sequence. First, the Trusted Root Certificate profile - this tells every device to trust the company's Certificate Authority. Second, the SCEP Certificate profile - this instructs devices to go and collect their unique client certificate. Third, the WiFi profile - this configures the SSID, sets the security type to WPA2-Enterprise or WPA3-Enterprise, and points to the SCEP certificate for authentication. Deploy those three profiles to the same device group in Intune, and every managed device connects to the corporate SSID automatically, with a unique certificate, zero user interaction required.

[short pause]

The RADIUS server - typically Microsoft NPS or a cloud RADIUS service - receives the EAP-TLS authentication request, validates the certificate against the CA, checks the Certificate Revocation List, and grants or denies access. If an employee is terminated, you revoke their certificate in the CA. Their device loses WiFi access at the next authentication cycle. No password reset required. No waiting for a quarterly rotation.

[medium pause]

Now, people often ask about the difference between SCEP and PKCS - Public Key Cryptography Standards. Both work with Intune. The key difference is where the private key is generated. With SCEP, it's generated on the device. With PKCS, the CA generates both keys centrally and pushes the private key down to the device. That means the private key travels across the network, which introduces a theoretical interception risk. PKCS has its place - it's better suited for S/MIME email encryption where key escrow matters. For WiFi authentication, SCEP is the right choice. Every time.

[short pause]

Let me give you a second scenario - a retail estate. Imagine a fashion retailer with 200 stores across the UK, each running Cisco Meraki access points. Their point-of-sale systems are Windows-based, managed through Intune. They need PCI DSS compliance, which means network segmentation and strong authentication for any device handling cardholder data. SCEP-based EAP-TLS gives them device-level authentication on the staff SSID, with VLAN assignment driven by the RADIUS policy. The POS terminals land on the PCI-scoped VLAN automatically. Guest WiFi - handled separately through a platform like Purple - runs on a completely isolated SSID with its own authentication flow. The two networks never touch. Auditors are happy. The security team sleeps better.

[medium pause]

Right, let's talk about the pitfalls, because there are a few that catch teams out.

[short pause]

The most common failure mode is group targeting mismatches in Intune. Your Trusted Root profile, your SCEP profile, and your WiFi profile must all target the same Azure AD group. If the SCEP profile targets a User group and the WiFi profile targets a Device group, Intune can't resolve the dependency and the WiFi profile shows as an error. Check your assignments first - it's almost always the culprit.

[short pause]

Second pitfall: NDES server availability. Your NDES server needs to be reachable from the internet for remote devices to enrol before they arrive on-site. The secure way to do this is via Azure AD Application Proxy, which gives you remote access without opening inbound firewall ports. Don't expose NDES directly to the internet.

[short pause]

Third: CRL availability. Your RADIUS server checks the Certificate Revocation List every time a device authenticates. If the CRL Distribution Point is unreachable - maybe a server is down, or a firewall rule changed - authentication fails for everyone. Make your CRL endpoints highly available, and test them regularly.

[short pause]

Fourth: certificate template permissions. If your NDES connector service account doesn't have Read and Enroll permissions on the certificate template, devices get HTTP 403 errors when they try to collect their certificate. It's a simple permissions fix, but it's easy to miss during initial setup.

[medium pause]

Now for a rapid-fire round.

[short pause]

Can SCEP work with non-Microsoft MDMs? Yes - Jamf for Apple device fleets, VMware Workspace ONE, and most enterprise MDM platforms support SCEP profiles. The protocol is vendor-neutral.

[short pause]

Does SCEP work with cloud PKI? Yes. Microsoft's own cloud PKI in Intune Suite eliminates the need for an on-premises NDES server entirely. Third-party cloud PKI providers like SecureW2 and Keyfactor also offer cloud SCEP endpoints.

[short pause]

What about WPA3-Enterprise? WPA3-Enterprise uses the same 802.1X and EAP-TLS authentication stack. SCEP-issued certificates work identically. The upgrade is at the wireless protocol layer, not the certificate layer.

[short pause]

How long do certificates last? Typically one year, though you can configure shorter validity periods. Intune handles automatic renewal before expiry, so users never see an interruption.

[medium pause]

To summarise. SCEP automates certificate distribution at scale, eliminating the manual overhead of PKI deployment across large device fleets. The private key stays on the device - that's the security foundation of EAP-TLS. Deploy in sequence: Trusted Root first, SCEP profile second, WiFi profile third, all targeting the same group. Publish your NDES endpoint securely via Application Proxy. Keep your CRL endpoints highly available. And if you're starting fresh, evaluate cloud PKI to remove the on-premises NDES dependency entirely.

[short pause]

For guest WiFi - the separate, visitor-facing network - certificate-based authentication isn't the right model. Guests don't have managed devices. That's where a platform like Purple handles the authentication flow: captive portal, social login, email capture, or SMS verification, all feeding into a first-party data layer that your marketing team can actually use. The two approaches complement each other: SCEP for your managed staff estate, Purple for your guest network. Both running on the same hardware, cleanly segmented by VLAN.

[short pause]

That's your briefing on SCEP enterprise WiFi onboarding. The full written guide, with architecture diagrams, step-by-step Intune configuration, and worked examples, is available on the Purple website. Thanks for listening.

Résumé exécutif

Pour les sites d'entreprise, qu'il s'agisse d'un secteur hôtelier dynamique, d'un réseau de vente au détail multi-sites ou d'un campus d'entreprise moderne, s'appuyer sur des clés pré-partagées ou des Captive Portals basiques pour le WiFi du personnel constitue une faille de sécurité et un goulot d'étranglement opérationnel. L'architecture réseau moderne exige une authentification 802.1X via EAP-TLS, garantissant que chaque appareil est vérifié par cryptographie avant d'accéder au réseau.

Le défi réside dans la distribution : comment déployer des certificats clients uniques sur des milliers d'appareils Windows, iOS et Android sans submerger votre support technique de tickets d'assistance ? Microsoft Intune et d'autres plateformes MDM résolvent ce problème grâce à la gestion automatisée du cycle de vie des certificats. En déployant des profils SCEP (Simple Certificate Enrollment Protocol), les équipes informatiques transmettent silencieusement des certificats racines et clients approuvés aux terminaux gérés.

Ce guide fournit un modèle d'architecture définitif et une stratégie de mise en œuvre étape par étape pour le déploiement de certificats WiFi d'entreprise. Nous explorons les différences critiques entre SCEP et PKCS, détaillons la séquence de déploiement exacte requise pour réussir, et présentons des stratégies concrètes de réduction des risques pour garantir que votre Guest WiFi et vos réseaux d'entreprise restent sécurisés et performants.

Écouter le briefing

Analyse technique approfondie : Architecture SCEP

Lors de la conception de votre stratégie de déploiement de certificats WiFi d'entreprise, la première décision architecturale consiste à sélectionner le mécanisme de distribution des certificats. Les plateformes de gestion des appareils mobiles prennent en charge à la fois SCEP et PKCS, mais fonctionnent de manière fondamentalement différente.

Simple Certificate Enrollment Protocol (SCEP)

SCEP est la norme de l'industrie pour l'enregistrement des appareils d'entreprise. Dans un flux de travail SCEP, le service de gestion demande au terminal de générer sa propre paire de clés privée et publique. L'appareil crée une demande de signature de certificat (CSR) et l'envoie via un serveur NDES (Network Device Enrollment Service) à votre autorité de certification (CA). L'autorité de certification signe la demande et renvoie le certificat public à l'appareil.

L'avantage de sécurité critique de SCEP est que la clé privée ne quitte jamais l'appareil. Elle est générée localement, stockée dans l'enclave sécurisée de l'appareil (comme le TPM sous Windows ou la Secure Enclave sur iOS), et n'est jamais transmise sur le réseau. Cela fait de SCEP l'approche fortement recommandée pour l'authentification 802.1X.

Public Key Cryptography Standards (PKCS)

À l'inverse, avec PKCS, l'autorité de certification génère à la fois les clés publique et privée de manière centralisée. Le connecteur de certificat exporte en toute sécurité cette paire de clés et la transmet à l'appareil cible.

Bien que PKCS élimine le besoin de déployer et de maintenir un serveur NDES, simplifiant ainsi l'empreinte de l'infrastructure, il introduit un risque de sécurité théorique car la clé privée est transmise sur le réseau. PKCS est généralement mieux adapté aux cas d'utilisation où le séquestre de clés est requis, comme le chiffrement des e-mails S/MIME, plutôt qu'à l'authentification réseau.

Guide de mise en œuvre : La séquence de déploiement

La configuration réussie d'un profil WiFi géré pour le 802.1X nécessite le respect strict d'une séquence de déploiement spécifique. Les dépendances de profil imposent que la confiance soit établie avant que l'authentification puisse être configurée.

Étape 1 : Déployer le profil de certificat racine approuvé

Avant qu'un appareil puisse demander un certificat client ou faire confiance à votre serveur RADIUS, il doit faire confiance à l'autorité de certification émettrice.

Exportez votre certificat de CA racine et tous les certificats de CA intermédiaire sous forme de fichiers .cer.
Dans votre console MDM, créez un nouveau profil de configuration.
Sélectionnez la plateforme cible et choisissez le type de profil de certificat approuvé.
Téléchargez le fichier .cer et déployez ce profil sur vos groupes d'appareils cibles.

Étape 2 : Configurer le profil de certificat SCEP

Une fois la confiance établie, configurez le profil SCEP pour indiquer aux appareils comment obtenir leur certificat client.

Créez un nouveau profil de configuration et sélectionnez le certificat SCEP.
Configurez le format du nom de l'objet. Pour l'authentification basée sur l'utilisateur, CN={{UserPrincipalName}} est la norme. Pour l'authentification de l'appareil, utilisez CN={{AAD_Device_ID}}.
Définissez l'utilisation de la clé sur la signature numérique et le chiffrement de la clé.
Sous l'utilisation étendue de la clé, spécifiez l'authentification client (OID : 1.3.6.1.5.5.7.3.2).
Liez ce profil au profil de certificat racine approuvé créé à l'étape 1.
Fournissez l'URL externe de votre passerelle SCEP ou de votre serveur NDES.

Étape 3 : Déployer le profil WiFi 802.1X

La dernière étape consiste à pousser la configuration WiFi qui lie les certificats au SSID du réseau.

Créez un profil de configuration WiFi.
Saisissez le nom du réseau exactement tel qu'il est diffusé par vos points d'accès sans fil.
Sélectionnez WPA2-Enterprise ou WPA3-Enterprise comme type de sécurité.
Définissez le type d'EAP sur EAP-TLS.
Dans les paramètres d'authentificationgs, sélectionnez le profil de certificat SCEP créé à l'étape 2 comme certificat d'authentification client.
Spécifiez le certificat racine de confiance pour la validation du serveur afin de vous assurer que l'appareil se connecte uniquement à votre serveur RADIUS légitime.

Meilleures pratiques et normes du secteur

Lors de la mise en œuvre du déploiement de certificats SCEP, respectez les meilleures pratiques neutres vis-à-vis des fournisseurs suivantes afin de garantir la conformité et la fiabilité.

Emplacement et sécurité de la passerelle SCEP

La passerelle SCEP doit être accessible depuis Internet pour permettre aux appareils distants de provisionner des certificats avant d'arriver sur site. L'exposition directe d'un serveur interne à Internet représente un risque de sécurité majeur. Publiez l'URL SCEP à l'aide d'un proxy d'application ou d'un reverse proxy. Cela permet un accès distant sécurisé sans ouvrir de ports de pare-feu entrants et vous permet d'appliquer des politiques d'accès conditionnel au flux d'enregistrement.

RADIUS et vérification CRL

Le déploiement de certificats ne représente que la moitié de l'équation de sécurité ; la révocation est tout aussi essentielle. Si un employé est licencié, la désactivation de son compte d'annuaire peut ne pas révoquer immédiatement son accès WiFi si son certificat client reste valide et que le serveur RADIUS ne vérifie pas strictement la liste de révocation de certificats (CRL).

Configurez votre serveur RADIUS pour imposer une vérification stricte de la CRL. Assurez-vous que vos points de distribution CRL sont hautement disponibles ; si le serveur RADIUS ne peut pas atteindre la CRL, l'authentification échouera, provoquant une panne généralisée.

Pour des considérations plus larges sur la connectivité moderne, consultez notre guide sur la Gestion de la bande passante : un guide pratique pour 2026 .

Dépannage et atténuation des risques

Même avec une planification méticuleuse, le déploiement de certificats peut rencontrer des problèmes. Voici les modes de défaillance courants et les stratégies d'atténuation.

Échec de l'application du profil WiFi

L'appareil reçoit les certificats racine de confiance et SCEP, mais le profil WiFi s'affiche comme étant en erreur ou non applicable dans la console MDM. Cela est presque toujours dû à une incompatibilité dans le ciblage des groupes. Si le profil SCEP est attribué à un groupe d'utilisateurs, mais que le profil WiFi est attribué à un groupe d'appareils, le MDM ne peut pas résoudre la dépendance. Auditez vos attributions. Assurez-vous que les profils racine de confiance, SCEP et WiFi sont tous déployés sur le même groupe exact.

Erreurs Gateway 403 Forbidden

Les appareils ne parviennent pas à récupérer le certificat SCEP et les journaux de la passerelle affichent des erreurs HTTP 403. Le compte de service du connecteur ne dispose pas des autorisations nécessaires sur le modèle de certificat, ou le filtrage d'URL sur votre pare-feu bloque les paramètres de chaîne de requête spécifiques utilisés par SCEP. Vérifiez que le compte du connecteur dispose des autorisations de lecture et d'inscription sur le modèle de l'autorité de certification (CA). Vérifiez les journaux du pare-feu pour vous assurer que les URL contenant ?operation=GetCACaps ne sont pas bloquées.

ROI et impact commercial

La transition vers un déploiement de certificats 802.1X basé sur SCEP offre des retours mesurables en matière de sécurité et d'opérations.

Réduction des tickets d'assistance : Le WiFi basé sur mot de passe génère un volume important de tickets d'assistance concernant les expirations de mots de passe, les verrouillages et les fautes de frappe. L'authentification par certificat est invisible pour l'utilisateur, réduisant généralement de 70 % le volume de tickets d'assistance liés au WiFi.
Posture de sécurité renforcée : L'EAP-TLS élimine le risque de vol d'identifiants et d'attaques de type Man-in-the-Middle. Cela est essentiel pour la conformité avec des cadres tels que PCI DSS et GDPR, en particulier dans les environnements du Commerce de détail et de la Santé .
Intégration fluide : L'intégration du déploiement de certificats aux flux de travail MDM existants garantit une expérience de provisionnement unifiée et sans contact (zero-touch) dès le premier jour.

Alors que SCEP sécurise vos appareils d'entreprise gérés, les réseaux d'invités et de visiteurs nécessitent une approche différente. Pour les appareils non gérés, un Captive Portal avec connexion via les réseaux sociaux ou vérification par SMS alimente une couche de données de première partie, vous offrant des informations exploitables. Explorez notre plateforme WiFi Analytics pour voir comment ces données génèrent des revenus.

Définitions clés

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 across enterprise fleets.

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 authentication 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 on-premises Microsoft PKI.

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 MDM WiFi and certificate profiles are designed to enable, eliminating password-based access.

CRL (Certificate Revocation List)

A list published by the Certificate Authority containing the serial numbers of certificates that have been revoked before their scheduled expiration date.

RADIUS servers must check the CRL during authentication to ensure terminated employees cannot access the network using a previously valid certificate.

CSR (Certificate Signing Request)

A block of encoded text given to a Certificate Authority when applying for an SSL/TLS certificate, containing the public key and identity information.

Generated locally by the managed device during the SCEP flow to request its unique identity credential.

802.1X

An IEEE standard for port-based network access control that provides an authentication mechanism to devices wishing to attach to a LAN or WLAN.

The foundational framework that enforces the requirement for EAP-TLS certificate validation before granting network access.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol that provides centralized authentication, authorization, and accounting management for users who connect and use a network service.

The server that evaluates the client certificate against the CA and CRL to make the final allow or deny decision for WiFi access.

Exemples concrets

A 150-property hotel group needs to secure their staff network across a mix of Windows laptops for front-of-house, iOS devices for housekeeping, and Android tablets for restaurant point-of-sale. They currently use WPA2-Personal with a shared password rotated quarterly, generating massive helpdesk volume.

The hotel group deploys three Intune profiles in sequence to a unified device group. First, a Trusted Root Certificate profile establishes trust with the corporate CA. Second, a SCEP Certificate profile instructs devices to request a unique client certificate. Third, a WiFi profile configures the corporate SSID with WPA3-Enterprise and EAP-TLS, pointing to the SCEP certificate for authentication. The RADIUS server enforces strict CRL checking to revoke access instantly upon employee termination.

Commentaire de l'examinateur : This approach eliminates the quarterly password rotation overhead and secures the network against credential sharing. SCEP is chosen over PKCS to ensure the private key never leaves the individual devices, maintaining a zero-trust posture across diverse hardware.

A fashion retailer with 200 stores requires PCI DSS compliance for their Windows-based point-of-sale systems managed through Intune. They must ensure strong authentication and strict network segmentation for any device handling cardholder data.

The retailer implements SCEP-based EAP-TLS for device-level authentication on the staff SSID. The RADIUS policy drives VLAN assignment, placing authenticated POS terminals onto a strictly isolated, PCI-scoped VLAN automatically. Guest WiFi is handled on a completely separate SSID with its own captive portal authentication flow, ensuring the two networks never intersect.

Commentaire de l'examinateur : By tying network segmentation directly to certificate-based authentication, the retailer satisfies PCI DSS requirements without manual network configuration per store. The physical separation of the guest network using a platform like Purple prevents scope creep for the PCI audit.

Questions d'entraînement

Q1. Your Intune deployment shows the Trusted Root and SCEP profiles successfully applied to a user's laptop, but the WiFi profile shows an 'Error' state. The user cannot connect to the corporate SSID. What is the most likely architectural cause?

Conseil : Consider how MDM platforms resolve dependencies between related configuration profiles.

Voir la réponse type

A group targeting mismatch. The SCEP profile is likely assigned to a User group, while the WiFi profile is assigned to a Device group (or vice versa). Intune cannot resolve the dependency across different group types, causing the WiFi profile deployment to fail. Audit the assignments and ensure all three profiles target the exact same Azure AD group.

Q2. A newly acquired subsidiary requires 802.1X authentication for their staff devices. Their security team mandates that private keys must never traverse the network and must be generated within the hardware TPM of the endpoint. Which certificate deployment method must you use?

Conseil : Compare where the private key is generated in the SCEP workflow versus the PKCS workflow.

Voir la réponse type

You must use SCEP (Simple Certificate Enrollment Protocol). In a SCEP workflow, the device generates its own private and public key pair locally within its secure enclave (TPM) and only sends a Certificate Signing Request (CSR) across the network. PKCS generates the private key centrally on the CA and transmits it over the network, which violates the security team's mandate.

Q3. An employee is terminated and their Active Directory account is disabled. However, their laptop remains connected to the corporate WiFi network for several hours before losing access. How do you resolve this security gap?

Conseil : Disabling an account does not invalidate an existing certificate. What mechanism does the RADIUS server use to check certificate validity?

Voir la réponse type

You must configure the RADIUS server to enforce strict Certificate Revocation List (CRL) checking. When an employee is terminated, their certificate must be explicitly revoked in the Certificate Authority. The RADIUS server will then check the CRL during the next authentication cycle and immediately deny access, regardless of the Active Directory account status.

Continuer la lecture de cette série

Comment configurer un WiFi invité : Guide de configuration d'entreprise sécurisé

Ce guide de référence fournit aux responsables informatiques et aux architectes réseau un plan d'action définitif pour déployer un WiFi invité d'entreprise sécurisé. Il couvre l'architecture essentielle, la migration vers le WPA3, la segmentation VLAN et l'intégration du Captive Portal pour protéger les systèmes internes tout en collectant des données de première partie conformes.

Comment configurer SCEP pour un BYOD sécurisé et l'authentification réseau 802.1X

Ce guide fournit une référence technique complète pour configurer SCEP afin de déployer une authentification réseau 802.1X basée sur des certificats. Il couvre la transition architecturale des mots de passe partagés vers EAP-TLS, l'intégration de la gestion des appareils mobiles (MDM) et une segmentation réseau stricte pour un accès BYOD sécurisé dans les environnements d'entreprise.

Mesurer le ROI commercial du WiFi invité et des analyses de localisation

Ce guide fournit un cadre technique et opérationnel pour mesurer le ROI commercial du WiFi invité et des analyses de localisation. Il détaille comment calculer la valeur des investissements matériels grâce à l'augmentation du temps de séjour, à l'efficacité opérationnelle et à la capture de données de première partie dans les secteurs du commerce de détail, de l'hôtellerie et des lieux publics. Les responsables informatiques, les architectes réseau, les CTO et les directeurs d'exploitation de sites y trouveront des cadres de mesure concrets, des études de cas réelles et des conseils de conformité pour justifier et maximiser leur investissement WiFi.