Passer au contenu principal

The Security Benefits of RADIUS as a Service for Hybrid Workforces

Ce guide de référence technique explique comment RADIUS as a Service sécurise l'accès au réseau pour les effectifs hybrides dans les sites distribués. Il couvre l'architecture, les avantages en matière de sécurité et les étapes de déploiement pour remplacer l'infrastructure RADIUS sur site par un service d'authentification géré dans le cloud. Pour les responsables informatiques et les architectes réseau des hôtels, des chaînes de vente au détail, des stades et des organisations du secteur public, ce guide fournit les preuves nécessaires pour évaluer et mettre en œuvre une migration vers le cloud RADIUS ce trimestre.

📖 9 min de lecture📝 2,171 mots🔧 2 exemples concrets3 questions d'entraînement📚 9 définitions clés

Écouter ce guide

Voir la transcription du podcast
Welcome to this technical briefing from Purple. I am your host, and today we are examining a critical shift in enterprise network architecture: moving from on-premise RADIUS servers to RADIUS as a Service. If you manage IT for a hotel group, a retail chain, a stadium, or any large public venue, you know that securing network access for a hybrid workforce is no longer a peripheral concern. It is central to your operational security, your compliance posture, and frankly, your ability to sleep at night. Today we will cover five areas. First, the context: why traditional on-premise RADIUS infrastructure is struggling to keep pace with hybrid work. Second, the technical architecture of RADIUS as a Service and how it actually works. Third, the specific security benefits you gain. Fourth, practical implementation guidance and the pitfalls to avoid. And fifth, a rapid-fire question and answer section covering the questions we hear most often from IT managers and network architects. Let us start with the context. For two decades, 802.1X authentication relied on physical servers running FreeRADIUS on Linux, Microsoft Network Policy Server on Windows, or Cisco Identity Services Engine on dedicated hardware. These systems worked. They still work. But they require constant attention. You had to patch operating systems, manage certificate chains, configure high availability manually, and build redundancy across multiple servers. In a world where workers move constantly between the office, remote locations, hotel rooms, and client sites, that static, on-premise infrastructure becomes a genuine liability. The problem is compounded by the shift to cloud identity providers. Microsoft NPS, for example, is tightly coupled to Active Directory. It has no native support for Microsoft Entra ID, Google Workspace, or Okta. If your organisation has migrated to any of these cloud directories, you face a painful choice: maintain a parallel Active Directory just to support your RADIUS server, or invest significant engineering effort in custom integrations. Neither option is attractive. RADIUS as a Service changes the equation entirely. It moves the authentication engine to the cloud. You no longer manage the infrastructure; you manage the policies. The provider handles the servers, the patching, the high availability, and the integrations. You define who gets access to what, and the service enforces it. Now let us get into the technical architecture. RADIUS, which stands for Remote Authentication Dial-In User Service, is the protocol defined in RFC 2865. It provides centralised Authentication, Authorisation, and Accounting, what we call AAA, for network access. When a device connects to your WiFi network, the access point acts as a RADIUS client. It forwards the authentication request to the RADIUS server. The server validates the credentials against your identity store and returns either an Access-Accept or an Access-Reject. In a cloud RADIUS deployment, the server is hosted by the provider across multiple geographically distributed data centres. Your access points, whether they are Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, or Ubiquiti UniFi, point to the cloud RADIUS endpoints via secure, encrypted tunnels. The authentication flow is identical to on-premise RADIUS from the access point's perspective. The difference is that the server itself is managed, patched, and scaled by the provider. The most important security enhancement in modern cloud RADIUS deployments is the move to EAP-TLS, which stands for Extensible Authentication Protocol with Transport Layer Security. EAP-TLS is defined in RFC 5216 and provides mutual authentication using digital certificates. Both the client device and the RADIUS server present certificates to each other. This eliminates passwords entirely from the authentication process. A certificate is cryptographically tied to the device and cannot be phished, guessed, or stolen in the way a password can. The second major security capability is dynamic VLAN assignment. When the RADIUS server authenticates a user, it does not just grant or deny access. It also tells the access point which Virtual LAN to place the device in, based on the user's identity and role. A hotel receptionist authenticates and is placed in the front-of-house VLAN with access to the property management system. A housekeeping staff member is placed in a restricted VLAN with internet access only. A guest device is placed in the guest VLAN, completely isolated from all corporate resources. An IoT device, like a security camera, is placed in a dedicated IoT VLAN. This identity-based network segmentation is fundamental to a Zero Trust security model. You are no longer trusting a device because it connected to a particular SSID. You are granting access based on verified identity, and you are limiting that access to only what that identity requires. This is the principle of least privilege applied to network access. Let us also address the compliance angle. PCI DSS version 4.0 requires strong access controls for any network that touches cardholder data. Requirement 8 mandates unique authentication for all users. Requirement 1 requires network segmentation. Cloud RADIUS, with EAP-TLS and dynamic VLAN assignment, satisfies both requirements directly. For GDPR, the centralised audit logging provided by cloud RADIUS gives you a complete record of who accessed the network, when, and from which device. That audit trail is essential for demonstrating compliance and for investigating any potential data breach. Now let me walk you through two concrete implementation scenarios that illustrate how this works in practice. The first scenario is a hotel group. Consider a two-hundred room hotel property. They currently use a shared pre-shared key for their staff WiFi. Every member of staff, from the general manager to the seasonal housekeeping team, uses the same password. When a seasonal employee leaves at the end of summer, the password is rarely changed because changing it means updating every device on the property. This is a textbook security vulnerability. The solution is to deploy RADIUS as a Service integrated with Microsoft Entra ID. The hotel configures its Cisco Meraki access points to use WPA3-Enterprise with 802.1X. Each staff member authenticates using their Entra ID credentials. The RADIUS server reads their role from the directory and assigns them to the appropriate VLAN dynamically. Housekeeping staff are placed in VLAN 10 with access to the housekeeping task management system only. Reception staff are placed in VLAN 20 with access to the property management system. Management are placed in VLAN 30 with broader access. When a seasonal employee's contract ends, their Entra ID account is disabled, and their WiFi access is revoked instantly, across every access point on the property. No password changes required. The second scenario is a national retail chain. Consider a chain with four hundred stores. They currently manage four hundred separate FreeRADIUS instances on local store servers. Each server requires individual patching, monitoring, and maintenance. When a critical vulnerability is disclosed, the security team must patch four hundred servers, often over a period of weeks, leaving the estate exposed during that window. The solution is to migrate to a single RADIUS as a Service instance. All four hundred stores point their HPE Aruba access points to the same cloud RADIUS endpoints. Point-of-sale terminals are authenticated using EAP-TLS with machine certificates pushed via the MDM platform. The RADIUS server places them in a PCI-compliant VLAN, isolated from all other network traffic. Store staff use a separate SSID authenticated via Okta, placing them in a general staff VLAN. The security team now manages one set of policies from a single dashboard. When a vulnerability is disclosed, the provider patches the infrastructure. The retail chain's security team focuses on policy, not plumbing. Now let us cover implementation recommendations and the pitfalls to avoid. Step one is to connect the cloud RADIUS service to your identity provider. For Microsoft Entra ID or Google Workspace, this typically involves authorising an enterprise application. Map your directory groups to specific network policies. Think carefully about your role taxonomy before you start. Getting this right at the beginning saves significant rework later. Step two is to set up certificate deployment for corporate devices. Configure your MDM platform to push client certificates to managed devices. This enables EAP-TLS authentication and removes passwords from the equation entirely. For devices you do not manage, you can use PEAP with a user credential as a fallback, but EAP-TLS should be the target for all corporate-owned devices. Step three is to configure your network hardware. Add the cloud RADIUS IP addresses and shared secrets to your wireless controllers or access points. Always configure both the primary and secondary endpoints to use the provider's built-in redundancy. Step four is to define your VLAN policies. When the RADIUS server authenticates a user, it returns the correct VLAN ID to the access point. Map this out before you deploy. Know which VLAN each user role should land in, and test it thoroughly before rolling out to production. Now, the pitfalls. The most common mistake is a misconfigured firewall blocking UDP ports 1812 and 1813, which are the RADIUS authentication and accounting ports. Always verify connectivity between your access points and the cloud RADIUS endpoints before go-live. The second pitfall is a broken certificate trust chain. If your client devices do not trust the Root Certificate Authority that issued the RADIUS server's certificate, they will silently reject the connection. This can look like a network outage when it is actually a PKI configuration issue. Let us move to the rapid-fire questions. Question one: What happens if our internet connection goes down? If the site loses internet, it cannot reach the cloud RADIUS. However, if the site has no internet, users cannot access cloud applications anyway. For mission-critical local resources, some access points offer local survivability modes. But the primary dependency is your WAN link, and that is true of almost every cloud service your organisation uses. Question two: Is cloud RADIUS compliant with GDPR and PCI DSS? Yes. Centralised authentication with encrypted transport supports strong compliance postures. The audit logs satisfy PCI DSS requirements, and the strict access controls support GDPR principles of data minimisation and access limitation. Question three: Does this work with our existing hardware? Yes. RADIUS is a standard protocol defined in RFC 2865. If your hardware supports 802.1X, and all enterprise gear from Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet does, it will work with any standards-compliant RADIUS as a Service. To summarise the key takeaways. First, RADIUS as a Service replaces on-premise servers with a managed cloud platform, reducing capital expenditure and maintenance overhead. Second, cloud RADIUS integrates natively with Microsoft Entra ID, Okta, and Google Workspace, eliminating the need for complex middleware. Third, it enables dynamic VLAN assignment, ensuring users and devices land in the correct network segment based on their verified identity. Fourth, transitioning to EAP-TLS eliminates the risk of password theft and phishing attacks on your network. Fifth, centralised cloud management ensures consistent security policies across hundreds of distributed venue locations. Sixth, providers handle security patching and high availability. And seventh, cloud RADIUS supports compliance with PCI DSS and GDPR by enforcing strict, identity-based access controls with full audit logging. Your next step is to evaluate your current RADIUS infrastructure. Calculate the true cost of ownership, including licensing, hardware refresh cycles, and the engineering time spent on maintenance. Then, run a proof of concept with a cloud RADIUS provider. You will likely find that the deployment takes hours, not weeks. Thank you for listening. Secure your networks, segment your traffic, and stop managing servers you do not need to own.

header_image.png

Résumé analytique

Le passage aux effectifs hybrides a mis en évidence une faiblesse fondamentale de la sécurité réseau traditionnelle : les serveurs RADIUS sur site ont été conçus pour un monde où le personnel travaillait dans un seul bâtiment et se connectait à un seul réseau. Ce monde n'existe plus. Aujourd'hui, vos collaborateurs s'authentifient depuis des chambres d'hôtel, des points de vente, des bureaux distants et des lieux d'événements. Vos fournisseurs d'identité résident dans le cloud. Vos points d'accès s'étendent sur des centaines de sites. Pourtant, de nombreuses organisations s'appuient encore sur des serveurs RADIUS physiques qui nécessitent des correctifs manuels, ne peuvent pas s'intégrer nativement avec Microsoft Entra ID ou Google Workspace, et tombent en panne silencieusement en cas de défaillance matérielle.

RADIUS as a Service remplace cette infrastructure par un moteur d'authentification cloud-native. Vous pointez vos points d'accès vers des points de terminaison cloud. Le fournisseur gère les serveurs, les correctifs et la haute disponibilité. Vous gérez les politiques. Pour les équipes informatiques des groupes de l' Hôtellerie , des chaînes de Vente au détail et des lieux publics, cette transition élimine les coûts matériels, impose une segmentation du réseau basée sur l'identité et fournit la piste d'audit exigée par PCI DSS et le GDPR.


Analyse technique approfondie

Pourquoi le RADIUS sur site est en difficulté

Le protocole RADIUS, défini dans la norme RFC 2865, fournit un système centralisé d'authentification, d'autorisation et de comptabilisation (AAA) pour l'accès au réseau. Chaque entreprise exécutant un réseau WiFi WPA2-Enterprise ou WPA3-Enterprise en dépend. Le protocole lui-même est robuste. Le problème réside dans le modèle d'infrastructure qui s'est développé autour de lui.

FreeRADIUS sur Linux nécessite une expertise importante pour être déployé, sécurisé et maintenu. Microsoft Network Policy Server (NPS) est étroitement lié à Active Directory et ne prend pas en charge nativement Microsoft Entra ID, Okta ou Google Workspace. Cisco Identity Services Engine (ISE) offre des fonctionnalités de politique de classe entreprise, mais nécessite du matériel dédié, des licences complexes et une équipe spécialisée pour l'exploiter. Tous trois vous obligent à concevoir et à maintenir manuellement la haute disponibilité, généralement en exécutant deux serveurs avec réplication de base de données et un répartiteur de charge en amont.

Pour une organisation sur un seul site dotée d'un Active Directory stable, ce modèle est gérable. Pour un groupe hôtelier de 50 établissements, une chaîne de vente au détail de 400 magasins ou une université dotée d'un campus distribué, cela devient irréalisable. Soit vous centralisez les serveurs RADIUS et acceptez la latence d'authentification des sites distants, soit vous déployez des serveurs sur chaque site et les gérez individuellement. Aucune de ces options n'est évolutive.

L'architecture de RADIUS as a Service

RADIUS as a Service est un modèle de diffusion basé sur le cloud pour le protocole RADIUS. Le protocole lui-même reste inchangé, conformément à la norme RFC 2865 et à ses extensions. Ce qui change, c'est l'entité qui gère l'infrastructure.

Lorsqu'un appareil se connecte à votre réseau WiFi, le point d'accès (le client RADIUS) transmet la demande d'authentification aux points de terminaison RADIUS cloud via un tunnel sécurisé et chiffré. Le service cloud valide les identifiants auprès de votre fournisseur d'identité et renvoie un message Access-Accept ou Access-Reject, ainsi que des attributs de politique tels que des attributions dynamiques de VLAN. Du point de vue du point d'accès, le flux d'authentification est identique à celui du RADIUS sur site.

architecture_overview.png

Le fournisseur cloud exploite les serveurs RADIUS dans plusieurs centres de données géographiquement répartis. Le basculement est automatique. Si un point de terminaison devient indisponible, le trafic est acheminé vers le suivant en bon état, sans aucune intervention de votre équipe. Pour les organisations disposant de sites dans plusieurs régions, l'authentification s'effectue au point de terminaison cloud le plus proche, ce qui maintient une faible latence quelle que soit la situation géographique.

Méthodes IEEE 802.1X and EAP

La norme IEEE 802.1X est le standard pour le contrôle d'accès au réseau (NAC) basé sur les ports. Elle oblige un appareil à s'authentifier avant de se voir attribuer une adresse IP et d'être autorisé à transmettre du trafic. RADIUS est le serveur d'authentification dans un déploiement 802.1X.

Le protocole EAP (Extensible Authentication Protocol) définit la manière dont les identifiants sont échangés. Le RADIUS cloud prend en charge l'ensemble des méthodes EAP :

Méthode EAP Type d'authentification Niveau de sécurité Utilisation recommandée
EAP-TLS Basée sur des certificats mutuels Le plus élevé Appareils d'entreprise avec certificats gérés par MDM
PEAP-MSCHAPv2 Nom d'utilisateur et mot de passe Modéré Appareils existants ou BYOD sans MDM
EAP-TTLS Identifiants tunnelisés Modéré Environnements mixtes
MAC Authentication Bypass Adresse MAC de l'appareil Faible Appareils IoT ne pouvant pas prendre en charge le 802.1X

La méthode EAP-TLS, définie dans la norme RFC 5216, est la référence absolue. L'appareil client et le serveur RADIUS se présentent mutuellement des certificats numériques. Cette authentification mutuelle élimine totalement les mots de passe du processus d'accès au réseau. Un certificat est lié de manière cryptographique à l'appareil et ne peut pas être hameçonné, deviné ou volé comme un mot de passe. Pour les organisations ayant subi des failles de sécurité liées aux identifiants, il s'agit de la mesure d'atténuation technique la plus directe disponible.

Attribution dynamique de VLAN

Au-delà de l'authentification, le serveur RADIUS applique l'autorisation. Lorsqu'il accepte une connexion, il renvoie des attributs de politique au point d'accès, y compris l'ID de VLAN à attribuer à l'appareil. Cette attribution dynamique de VLAN est le mécanisme qui permet de créer des réseaux basés sur l'identité.

Un réceptionniste d'hôtel s'authentifie et est placé dans le VLAN de la réception avec accès au système de gestion de l'établissement. Un membre du personnel d'entretien est placé dans un VLAN restreint avec un accès Internet uniquement. Un appareil invité est placé dans le VLAN WiFi invité, complètement isolé de toutes les ressources de l'entreprise. Un appareil IoT, tel qu'une caméra de sécurité, est placé dans un VLAN dédié "" dédié "VLAN IoT. Tout cela se produit automatiquement, sur la base de l'identité vérifiée par le serveur RADIUS, sans aucune configuration manuelle de VLAN par appareil.

C'est le principe du moindre privilège appliqué à l'accès réseau. Vous ne faites pas confiance à un appareil simplement parce qu'il s'est connecté à un SSID particulier. Vous accordez l'accès sur la base d'une identité vérifiée et limitez cet accès à ce que cette identité requiert uniquement. Pour en savoir plus sur la façon dont cela s'intègre dans une stratégie plus large de contrôle d'accès au réseau, consultez notre guide sur les systèmes de contrôle d'accès au réseau .

Intégration native de l'identité cloud

L'avantage opérationnel le plus significatif du RADIUS cloud est son intégration native avec les fournisseurs d'identité modernes. Le RADIUS cloud se connecte directement à Microsoft Entra ID, Okta et Google Workspace via des protocoles standards, notamment OIDC, SAML et LDAP. Lorsque vous configurez un nouvel employé dans votre fournisseur d'identité, il peut s'authentifier immédiatement sur le réseau WiFi. Lorsque vous désactivez un employé, vous désactivez son compte dans l'annuaire et son accès WiFi est révoqué instantanément, sur chaque point d'accès de chaque site.

Cette synchronisation en temps réel élimine l'une des failles de sécurité les plus persistantes du WiFi d'entreprise : l'ancien employé qui possède toujours la clé PSK partagée, ou dont le compte RADIUS n'a pas été supprimé manuellement à son départ. Avec le RADIUS cloud et un fournisseur d'identité cloud, la désactivation d'un compte est une action unique avec un effet immédiat sur l'ensemble du réseau.


Guide d'implémentation

Étape 1 : Connectez votre fournisseur d'identité

Connectez le service RADIUS cloud à votre fournisseur d'identité. Pour Microsoft Entra ID ou Google Workspace, cela implique généralement d'autoriser une application d'entreprise via OAuth ou de configurer un connecteur LDAP. Associez vos groupes d'annuaire à des politiques réseau spécifiques. Définissez votre taxonomie de rôles avant de commencer : quels groupes correspondent à quels VLANs, et quels droits d'accès chaque VLAN comporte. Faire cela correctement dès le départ évite d'importants ajustements ultérieurs.

Étape 2 : Déployez des certificats pour les appareils d'entreprise

Pour les appareils appartenant à l'entreprise, configurez votre plateforme de gestion des appareils mobiles (MDM), telle que Microsoft Intune ou Jamf, pour déployer des certificats clients sur les appareils. Cela permet l'authentification EAP-TLS. Assurez-vous que l'autorité de certification racine (CA) qui a émis le certificat du serveur RADIUS est approuvée par tous les appareils clients. Une chaîne de confiance rompue est la cause la plus fréquente d'échecs d'authentification silencieux.

Étape 3 : Configurez votre matériel réseau

Ajoutez les adresses IP et les secrets partagés du RADIUS cloud à vos contrôleurs sans fil ou points d'accès. Configurez toujours les points de terminaison principal et secondaire pour utiliser la redondance intégrée du fournisseur. Assurez-vous que les ports UDP 1812 (authentification) et 1813 (comptabilité) sont ouverts en sortie depuis vos points d'accès vers les points de terminaison du RADIUS cloud. Vérifiez cela avant la mise en service. Des règles de pare-feu mal configurées sont la deuxième cause la plus fréquente d'échecs de déploiement.

Le RADIUS cloud fonctionne avec Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Les étapes de configuration varient selon le fournisseur, mais le protocole RADIUS est standardisé, de sorte que les paramètres de base (IP du serveur, secret partagé, port d'authentification) restent les mêmes.

Étape 4 : Définissez les politiques de VLAN

Configurez l'attribution dynamique de VLAN dans votre moteur de politiques RADIUS. Associez chaque rôle d'utilisateur ou type d'appareil à un ID de VLAN spécifique. Testez chaque politique avant le déploiement en production. Une matrice de test simple - un appareil par rôle, un VLAN par rôle, vérification du placement - permet de détecter la plupart des erreurs de configuration avant qu'elles n'affectent les utilisateurs.


Bonnes pratiques

Imposez l'EAP-TLS pour tous les appareils d'entreprise. Abandonnez PEAP-MSCHAPv2 aussi rapidement que votre déploiement MDM le permet. PEAP repose sur des mots de passe, qui peuvent être compromis. EAP-TLS repose sur des certificats, ce qui n'est pas le cas.

Segmentez tout. Ne placez jamais le personnel, les invités et les appareils IoT sur le même sous-réseau. Utilisez RADIUS pour imposer des limites strictes de VLAN. C'est essentiel pour les environnements du Commerce de détail gérant des données de cartes de paiement sous PCI DSS, et pour les environnements de la Santé protégeant les données des patients.

Alignez-vous sur WPA3-Enterprise. WPA3-Enterprise, la norme de sécurité WiFi actuelle, nécessite une authentification 802.1X. Assurez-vous que vos points d'accès prennent en charge WPA3-Enterprise et configurez-le comme norme de sécurité minimale pour les réseaux du personnel.

Auditez régulièrement vos journaux RADIUS. Le RADIUS cloud fournit des journaux d'audit centralisés. Examinez les échecs d'authentification chaque semaine. Un pic d'échecs provenant d'un appareil ou d'un site spécifique est un indicateur précoce d'une mauvaise configuration ou d'une attaque potentielle.

Testez le basculement. Au moins une fois par trimestre, simulez une panne du point de terminaison RADIUS principal et vérifiez que l'authentification se poursuit via le point de terminaison secondaire. Documentez le résultat. C'est un test simple que la plupart des équipes n'exécutent jamais avant d'en avoir besoin.

Pour les sites déployant le WiFi dans des environnements complexes, y compris des zones maritimes ou isolées, consultez notre guide sur la configuration d'un Captive Portal sur Starlink pour connaître les aspects liés à la dépendance au réseau WAN.


Dépannage et atténuation des risques

Expirations de l'authentification

Si les appareils ne parviennent pas à s'authentifier, vérifiez d'abord la connectivité entre vos points d'accès et les points de terminaison du RADIUS cloud. Vérifiez que les ports UDP 1812 et 1813 sont ouverts en sortie. L'inspection approfondie des paquets (DPI) sur les pare-feu modernes peut retarder ou rejeter les paquets RADIUS. Si vous constatez des expirations de délai, vérifiez votre politique de pare-feu pour y rechercher des règles susceptibles d'inspecter ou de limiter le débit du trafic UDP vers les points de terminaison RADIUS.

Échecs de la chaîne de confiance des certificats

Si vous utilisez EAP-TLS, assurez-vous que les appareils clients font confiance à la CA racine qui a émis le certificat du serveur RADIUS. Si la chaîne de confiance est rompue, l'appareil rejettera silencieusement la connexion pour empêcher une attaque de l'homme du milieu. Cela se traduit par un échec de connexion sans message d'erreur évident. Vérifiez les journaux du serveur RADIUS pour "Échecs de la négociation EAP-TLS. Déployez le certificat Root CA sur tous les appareils gérés via MDM.

Dépendance WAN

Cloud RADIUS nécessite une connexion Internet active. Si la liaison WAN échoue, les demandes d'authentification ne peuvent pas atteindre le serveur. Pour les ressources locales critiques, évaluez les points d'accès qui prennent en charge la survie locale ou la mise en cache de l'authentification. Pour la plupart des déploiements, la dépendance WAN est acceptable car un site sans Internet ne peut de toute façon pas accéder aux applications cloud.

Incohérences de secret partagé

Chaque point d'accès ou contrôleur sans fil doit être configuré comme un client RADIUS avec le secret partagé correct. Une non-correspondance entraîne le rejet silencieux de toutes les demandes d'authentification de cet appareil. Si un point d'accès spécifique échoue alors que d'autres réussissent, vérifiez la configuration du secret partagé sur cet appareil.


ROI et impact commercial

comparison_chart.png

L'argument commercial en faveur de RADIUS as a Service repose sur trois piliers : la réduction des dépenses d'investissement, la diminution des coûts opérationnels et l'amélioration de la posture de sécurité.

Concernant les dépenses d'investissement, vous éliminez les coûts d'achat, de licence et de renouvellement des serveurs physiques. Un déploiement RADIUS sur site minimum viable nécessite deux serveurs pour la haute disponibilité, des licences de système d'exploitation et un renouvellement du matériel tous les trois à cinq ans. Pour un groupe hôtelier de 50 établissements, cela représente un investissement matériel important sur l'ensemble du parc.

Concernant les coûts opérationnels, votre équipe d'ingénierie ne perd plus de temps à appliquer des correctifs sur Windows Server, à dépanner les configurations FreeRADIUS ou à gérer les renouvellements de certificats sur l'infrastructure physique. Ce temps est réorienté vers l'élaboration de politiques de sécurité qui améliorent directement votre posture.

Concernant la posture de sécurité, le passage à EAP-TLS et à l'attribution dynamique de VLAN réduit considérablement la surface d'attaque. Le vol d'identifiants est la principale cause de failles réseau. L'élimination des mots de passe du processus d'authentification réseau répond directement à ce risque. La journalisation centralisée des audits facilite la conformité avec PCI DSS v4.0 et le GDPR, réduisant ainsi le coût et la complexité des audits de conformité.

Pour les organisations qui gèrent des hubs de Transport ou des sites à forte fréquentation, la capacité d'appliquer des politiques de sécurité cohérentes sur tous les sites à partir d'un tableau de bord unique constitue une amélioration opérationnelle mesurable. Purple opère dans plus de 80 000 sites actifs et a traité 440 millions de connexions en 2024 (données internes Purple, 2024). L'infrastructure qui soutient cette envergure est cloud-native par conception.

Pour une vision plus large de la manière dont les analyses WiFi et l'intelligence réseau sont liées aux résultats commerciaux, consultez notre plateforme d'analyses WiFi .


Références

[1] Norme IEEE pour les réseaux locaux et métropolitains - Contrôle d'accès réseau basé sur les ports. IEEE Std 802.1X-2020. [2] IETF. Remote Authentication Dial In User Service (RADIUS). RFC 2865. 1997. [3] IETF. The EAP-TLS Authentication Protocol. RFC 5216. 2008. [4] IronWiFi. Benefits of a Cloud RADIUS Server: Why Enterprises Are Moving Authentication Online. Février 2026. [5] SecureW2. Cloud vs. On-Site RADIUS: Which is Better? Mai 2026. [6] Portnox. RADIUS as a Service. 2026. [7] PCI Security Standards Council. PCI DSS v4.0. Mars 2022. [8] Purple. Données internes de la plateforme : 440 millions de connexions, plus de 80 000 sites. 2024.

Définitions clés

RADIUS

Remote Authentication Dial-In User Service. A networking protocol defined in RFC 2865 that provides centralised Authentication, Authorisation, and Accounting (AAA) management for users connecting to a network service.

IT teams use RADIUS as the central decision engine to verify whether a device or user is allowed onto the corporate WiFi network. It sits between the access point and the identity provider.

802.1X

An IEEE Standard for port-based Network Access Control. It provides an authentication mechanism to devices wishing to attach to a LAN or WLAN, forcing them to authenticate before receiving an IP address.

This is the standard that underpins enterprise WiFi security. Without 802.1X, any device that connects to the SSID gets network access. With 802.1X, every device must prove its identity first.

EAP-TLS

Extensible Authentication Protocol - Transport Layer Security. An authentication method defined in RFC 5216 that requires both the client device and the RADIUS server to present digital certificates, providing mutual authentication without passwords.

Considered the gold standard for enterprise WiFi security. Certificates are deployed to corporate devices via MDM. EAP-TLS eliminates the risk of password theft and phishing attacks on the network.

PEAP

Protected Extensible Authentication Protocol. An EAP method that tunnels a username and password exchange inside a TLS session. Less secure than EAP-TLS because it relies on passwords.

PEAP-MSCHAPv2 is widely deployed in legacy environments. IT teams should plan a migration to EAP-TLS for corporate devices, using PEAP only as a fallback for unmanaged or BYOD devices.

Dynamic VLAN assignment

A process where the RADIUS server instructs the access point which Virtual LAN to place a device in, based on the user's verified identity and role, rather than the SSID they connected to.

Essential for network segmentation in multi-role environments. A single 'Staff' SSID can securely separate housekeeping, reception, and management traffic into different VLANs with different access rights.

AAA

Authentication, Authorisation, and Accounting. The three functions performed by a RADIUS server: verifying identity (authentication), determining what access is permitted (authorisation), and recording session data for audit purposes (accounting).

IT teams and auditors use AAA as a framework for evaluating network access control. Cloud RADIUS delivers all three functions from a managed service.

WPA3-Enterprise

The current WiFi security standard for enterprise networks, requiring 802.1X authentication via a RADIUS server. It offers improved cryptographic strength over WPA2-Enterprise, including 192-bit security mode for high-security environments.

IT managers should configure WPA3-Enterprise as the minimum security standard for staff networks. Guest networks can use WPA2 or open authentication with a captive portal.

Network Access Control (NAC)

A security approach that enforces policy on devices seeking to access network resources, combining endpoint security assessment, identity authentication, and network enforcement.

RADIUS is a foundational component of NAC. Cloud RADIUS extends NAC to distributed, multi-site environments without requiring on-premise infrastructure at each location.

Captive portal

A web page that a user of a public-access network must interact with before being granted internet access. Typically used for Guest WiFi to collect consent or display terms of use.

Captive portals handle unauthenticated guest access, while 802.1X handles authenticated staff access. The two mechanisms operate on separate SSIDs and VLANs.

Exemples concrets

A 200-room hotel needs to secure its staff network across housekeeping, reception, and management, while keeping Guest WiFi entirely separate. They currently use a shared PSK for the staff network, which has not been changed in two years.

Deploy RADIUS as a Service integrated with Microsoft Entra ID. Configure the Cisco Meraki access points to use WPA3-Enterprise with 802.1X. Housekeeping staff authenticate using their Entra ID credentials; the RADIUS server reads their directory group and dynamically assigns them to VLAN 10 (housekeeping task system access only). Reception staff are assigned to VLAN 20 (property management system access). Management are assigned to VLAN 30 (broader access). Guest WiFi remains on a separate SSID with a captive portal, isolated on VLAN 40. When a seasonal staff member leaves, their Entra ID account is disabled, instantly revoking WiFi access across all access points on the property.

Commentaire de l'examinateur : This approach eliminates the shared PSK vulnerability and the risk of former employees retaining access. Dynamic VLAN assignment ensures a compromised housekeeping device cannot reach the property management system. Using cloud RADIUS removes the need for a physical server in the hotel's limited IT closet. The integration with Entra ID means offboarding is a single action with immediate network-wide effect.

A national retail chain with 400 stores needs to ensure PCI DSS compliance for its point-of-sale terminals. They currently manage 400 separate FreeRADIUS instances on local store servers, each requiring individual patching.

Migrate to a single RADIUS as a Service instance. Configure HPE Aruba access points at all 400 stores to authenticate POS devices using EAP-TLS with machine certificates pushed via Microsoft Intune. The cloud RADIUS server authenticates the certificates and places POS devices into a PCI-compliant VLAN (VLAN 30), isolated from all other network traffic. Store staff use a separate SSID authenticated via Okta, placing them in a general staff VLAN (VLAN 20). Shoppers on the guest network are isolated on VLAN 40. The security team manages all policies from a single dashboard.

Commentaire de l'examinateur : Centralising the RADIUS infrastructure eliminates the maintenance burden of patching 400 local servers. Using EAP-TLS for POS devices removes passwords entirely, preventing credential theft. This architecture satisfies PCI DSS v4.0 Requirement 8 (unique authentication) and Requirement 1 (network segmentation). When a vulnerability is disclosed, the provider patches the cloud infrastructure rather than the retail chain's security team patching 400 servers over several weeks.

Questions d'entraînement

Q1. Your university campus currently uses Microsoft NPS on Windows Server to authenticate students via PEAP-MSCHAPv2. The institution is migrating to Google Workspace and wants to decommission all on-premise servers within 12 months. What is the most secure and operationally efficient architectural change for the WiFi authentication infrastructure?

Conseil : Microsoft NPS does not natively support Google Workspace. Consider what replaces both the server and the authentication method.

Voir la réponse type

Migrate to RADIUS as a Service with native Google Workspace integration. The cloud RADIUS service connects directly to Google Workspace via LDAP or OIDC, eliminating the need for Active Directory or NPS. Simultaneously, transition managed student and staff devices from PEAP-MSCHAPv2 to EAP-TLS by deploying client certificates via the institution's MDM platform. This removes passwords from the authentication process and ensures that only managed, trusted devices can access the staff and student networks. The migration can be phased: deploy cloud RADIUS alongside NPS, migrate one SSID at a time, then decommission NPS once all devices are using the new service.

Q2. A stadium with 80,000 capacity requires secure WiFi for corporate staff, ticketing terminals, media press members, and event-day contractors. How should the network be configured using cloud RADIUS to enforce appropriate access for each group?

Conseil : Consider how RADIUS handles authorisation, not just authentication. Each group needs different access rights.

Voir la réponse type

Deploy a single 802.1X SSID for all authenticated groups. Configure the cloud RADIUS service to use dynamic VLAN assignment based on the user's role in the identity provider. Corporate staff are assigned to VLAN 10 with access to internal systems. Ticketing terminals, authenticated via machine certificates (EAP-TLS), are placed in a restricted VLAN 20 with access only to the ticketing platform. Media press members are assigned to VLAN 30 with high-bandwidth internet access but no access to internal systems. Event-day contractors are assigned to VLAN 40 with limited internet access only. A separate open SSID with a captive portal handles fan and attendee guest access on VLAN 50, isolated from all other traffic.

Q3. During a security audit, it is discovered that your organisation's FreeRADIUS server has not received a security patch for eight months. The team has been reluctant to patch it because the last update caused a two-hour authentication outage. How does migrating to RADIUS as a Service resolve both the security risk and the operational risk?

Conseil : Consider the division of responsibility in a managed service model and how providers handle patching without downtime.

Voir la réponse type

RADIUS as a Service shifts the responsibility for OS patching and vulnerability management to the provider. The provider operates highly available, multi-region clusters, allowing them to patch individual endpoints and roll updates progressively without causing authentication downtime. Your team no longer needs to schedule maintenance windows or accept the risk of a patch-induced outage. The security risk is eliminated because the provider patches the infrastructure as vulnerabilities are disclosed, often before the CVE is widely publicised. The operational risk is eliminated because the provider's SLA guarantees uptime regardless of patching activity. Your team's role changes from infrastructure maintenance to policy management.

Continuer la lecture de cette série

Integrating RADIUS as a Service with Cloud Directories (Azure AD & Google Workspace)

Ce guide de référence technique détaille comment intégrer RADIUS as a Service avec les annuaires cloud (Microsoft Entra ID et Google Workspace) pour l'authentification WiFi d'entreprise. Il couvre la transition architecturale du NPS sur site vers un RADIUS natif cloud, le déploiement de l'authentification EAP-TLS basée sur des certificats, ainsi que les meilleures pratiques opérationnelles pour sécuriser l'accès sans fil dans les secteurs de l'hôtellerie, du commerce de détail et du secteur public. Destiné aux responsables informatiques et aux architectes réseau déjà engagés dans l'identité cloud, ce guide comble le fossé entre la gestion des annuaires et la sécurité physique du réseau.

Lire le guide →

How to Implement 802.1X Authentication with Cloud RADIUS

Ce guide de référence technique fournit un cadre complet pour l'implémentation de l'authentification 802.1X avec Cloud RADIUS à travers les infrastructures d'entreprise distribuées. Il détaille l'architecture, la sélection de la méthode EAP, le séquençage du déploiement et les stratégies d'atténuation des risques nécessaires pour sécuriser l'accès au réseau tout en éliminant la charge opérationnelle de l'infrastructure sur site.

Lire le guide →

What is Cloud RADIUS? A Comprehensive Guide to RADIUS as a Service

Ce guide complet explore Cloud RADIUS (RADIUS en tant que service), détaillant son architecture, ses méthodes EAP et ses stratégies de mise en œuvre. Il fournit aux leaders informatiques des informations exploitables sur la migration des serveurs sur site vers un modèle d'authentification basé sur le cloud, évolutif, sécurisé et conforme.

Lire le guide →