Passer au contenu principal

Qu'est-ce que Cloud RADIUS ? Un guide complet sur RADIUS en tant que 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.

📖 5 min de lecture📝 1,077 mots🔧 2 exemples concrets3 questions d'entraînement📚 8 définitions clés

Écouter ce guide

Voir la transcription du podcast
What is Cloud RADIUS? A Comprehensive Guide to RADIUS as a Service. Welcome to the Purple WiFi Intelligence Podcast. I'm your host, and today we're doing a deep-dive briefing on Cloud RADIUS — what it is, how it works under the hood, and critically, how to evaluate whether it's the right move for your organisation this quarter. Whether you're running a hotel group, a retail estate, a stadium, or a public-sector network, this one's for you. Let's set the scene. Introduction and Context. If you've ever had to explain to a board why your network authentication server went down at 2am — and why it took three hours to bring back up — you already understand the core problem Cloud RADIUS solves. Traditional on-premises RADIUS infrastructure is powerful, but it carries significant operational overhead. Hardware to procure, patch cycles to manage, redundancy to architect manually, and a single point of failure sitting in your server room. Cloud RADIUS, or RADIUS as a Service, moves that authentication layer into a managed, highly available cloud environment. The protocol itself — Remote Authentication Dial-In User Service — hasn't changed. It's still the backbone of IEEE 802.1X network access control, still the mechanism your access points use to validate who gets onto your network. But the infrastructure running it is now someone else's problem. And in enterprise IT, that's a significant shift. So let's get into the technical detail. Technical Deep-Dive. RADIUS was originally defined in RFC 2865, published back in 2000, and it's remained remarkably durable. The protocol operates on a client-server model. Your network access device — whether that's a WiFi access point, a VPN concentrator, or a wired switch — acts as the RADIUS client, also called the Network Access Server or NAS. When a user attempts to connect, the NAS forwards an Access-Request packet to the RADIUS server, which validates the credentials against a user directory — typically Active Directory, LDAP, or a cloud identity provider — and returns either an Access-Accept or Access-Reject. That's the core exchange. But the real complexity sits in what happens around it: EAP methods, VLAN assignment, policy enforcement, accounting records, and certificate management. In a traditional on-premises deployment, you're running FreeRADIUS or Microsoft NPS on dedicated hardware, managing your own certificates, configuring your own failover, and maintaining your own user database sync. For a single-site deployment with a competent IT team, that's manageable. For a 50-site retail estate or a hotel group with properties across multiple countries, it becomes a significant operational burden. Cloud RADIUS abstracts all of that. The authentication logic, the certificate infrastructure, the redundancy, and the policy engine are all delivered as a managed service. Your access points point to cloud-hosted RADIUS endpoints — typically a primary and secondary IP address — and the service handles everything behind that. Now, let's talk about the authentication methods, because this is where the technical decisions really matter. The most common EAP method in enterprise WiFi is PEAP — Protected EAP — which tunnels MSCHAPv2 inside a TLS session. It's widely supported, works with Active Directory natively, and is the default for most Windows and Android devices. However, PEAP has known vulnerabilities, particularly around certificate validation. If your client devices aren't configured to verify the server certificate, you're exposed to credential harvesting attacks via rogue access points. EAP-TLS is the gold standard. It uses mutual certificate authentication — both the server and the client present certificates — which eliminates the password attack surface entirely. The trade-off is client certificate deployment, which requires a PKI infrastructure and MDM integration. For managed device fleets, this is absolutely the right choice. For BYOD environments, it's more complex. EAP-TTLS and EAP-FAST are also worth knowing. TTLS is particularly common in environments where you need to support a wide range of client devices, including Linux systems. EAP-FAST was developed by Cisco as an alternative to PEAP that avoids the certificate validation dependency, using Protected Access Credentials instead. A well-architected Cloud RADIUS service supports all of these methods and lets you configure per-SSID policy — so your corporate SSID uses EAP-TLS with certificate validation, your staff SSID uses PEAP with Active Directory, and your guest network uses a captive portal or social login flow entirely separate from the RADIUS stack. Speaking of which — RADIUS and guest WiFi are often conflated, but they serve different purposes. RADIUS is your authentication and authorisation layer for known users and devices. Guest WiFi typically uses a captive portal flow, which is a different mechanism entirely. Purple's platform, for instance, handles guest authentication through a separate identity layer, capturing first-party data and enabling marketing automation, while RADIUS handles the corporate and staff network access control. These are complementary, not competing, systems. Now, let's talk about what "cloud-hosted" actually means in practice. A properly architected Cloud RADIUS service runs across multiple availability zones, with automatic failover. Authentication requests are load-balanced across nodes, and the service maintains sub-100-millisecond response times even under peak load. For a stadium handling 40,000 concurrent connections during an event, that latency and throughput profile is critical. A single on-premises server simply cannot match that elasticity. From a compliance perspective, Cloud RADIUS providers operating in the UK and EU need to be GDPR-compliant in how they handle authentication logs and user data. For retail and hospitality environments that also process payment card data, PCI DSS requirements around network segmentation and access control are directly relevant — RADIUS is part of your control environment, and your QSA will want to see evidence of proper configuration and audit logging. WPA3 is also worth addressing. The transition from WPA2 to WPA3 introduces Simultaneous Authentication of Equals — SAE — for personal networks, and WPA3-Enterprise for corporate environments. WPA3-Enterprise mandates 192-bit security mode for the highest classification, which requires specific EAP methods and cipher suites. A Cloud RADIUS service needs to support these configurations to be future-proof. Implementation Recommendations and Pitfalls. Right, let's get practical. If you're evaluating Cloud RADIUS for deployment this quarter, here's what I'd focus on. First, integration with your identity provider. Your Cloud RADIUS service needs to sync with wherever your users actually live — whether that's Microsoft Entra ID, formerly Azure AD, Google Workspace, Okta, or an on-premises Active Directory via LDAP proxy. The quality of this integration determines your operational overhead. Native SAML or SCIM provisioning is far preferable to manual CSV imports. Second, certificate management. If you're deploying EAP-TLS, you need a clear answer on how client certificates are issued, renewed, and revoked. The best Cloud RADIUS services include an integrated PKI or integrate cleanly with your existing certificate authority. Certificate expiry is one of the most common causes of authentication failures in enterprise WiFi — it's entirely avoidable with proper automation. Third, network device compatibility. Your access points need to support RADIUS authentication — virtually all enterprise-grade APs do — but you need to verify the specific EAP methods and RADIUS attributes your chosen service supports against your AP vendor's implementation. Cisco, Aruba, Juniper Mist, and Ruckus all have their own nuances in how they handle RADIUS attributes and CoA — Change of Authorisation — messages. Fourth, redundancy configuration. Always configure both a primary and secondary RADIUS server IP. The failover timeout on your NAS devices matters — if it's set too high, users will experience a 30-second authentication delay when the primary is unreachable. A 3-to-5-second timeout with immediate failover is the right configuration for most environments. Fifth — and this is the one people miss — accounting. RADIUS accounting records are your audit trail. They tell you who connected, from which device, at what time, and for how long. For compliance purposes, particularly in healthcare and public-sector environments, these records need to be retained and accessible. Make sure your Cloud RADIUS provider gives you access to accounting data, not just authentication logs. Common pitfalls: shared secret complexity. Your RADIUS shared secret — the pre-shared key between your NAS and the RADIUS server — needs to be long and random. Short or guessable shared secrets are a real attack vector. Use at least 32 characters, generated randomly, and rotate them on a schedule. Also watch out for IP whitelisting. Many Cloud RADIUS services require you to whitelist the source IPs of your NAS devices. In a dynamic cloud environment where your AP management platform might use NAT, this can cause unexpected authentication failures. Confirm the NAT behaviour of your network before deployment. Rapid-Fire Q&A. Let me run through a few questions I get asked regularly. Can Cloud RADIUS support multi-tenant environments? Yes — most enterprise Cloud RADIUS services support tenant isolation, so a managed service provider can run separate RADIUS policies for multiple clients from a single platform. What's the typical latency for a Cloud RADIUS authentication? Sub-100 milliseconds for a well-architected service. The 802.1X handshake itself adds some overhead, but for most EAP methods, total authentication time should be under 500 milliseconds end-to-end. Does Cloud RADIUS work with OpenRoaming? Yes. OpenRoaming — the Wireless Broadband Alliance's roaming framework — uses RADIUS federation at its core. A Cloud RADIUS service that supports Hotspot 2.0 and OpenRoaming allows your users to authenticate automatically across participating networks globally. Purple supports OpenRoaming under its Connect licence, acting as an identity provider in the federation. Is Cloud RADIUS suitable for high-security environments? For most enterprise environments, yes. For environments with classified data or specific government security classifications, you may need to evaluate whether a managed cloud service meets your specific accreditation requirements. Summary and Next Steps. To bring this together: Cloud RADIUS is a mature, production-ready approach to network access control that removes the operational burden of on-premises RADIUS infrastructure without compromising on security or capability. For multi-site organisations, the ROI case is straightforward — you eliminate hardware capex, reduce IT overhead, gain built-in redundancy, and get a service that scales with your estate. The key decisions are: which EAP method is right for your device fleet, how you integrate with your existing identity provider, and whether your chosen service gives you the compliance and audit capabilities your organisation requires. If you're running a hotel group, a retail chain, or managing public-sector networks, I'd recommend starting with a proof-of-concept on a single site — get your RADIUS configuration right, validate the integration with your identity provider, and measure authentication latency before rolling out across your estate. For more on WiFi analytics, guest network management, and how Purple's platform integrates with RADIUS-based authentication, visit purple.ai. Thanks for listening.

header_image.png

Résumé Exécutif

Pour les réseaux d'entreprise modernes, l'architecture RADIUS (Remote Authentication Dial-In User Service) traditionnelle sur site représente un goulot d'étranglement opérationnel important. La gestion des serveurs physiques, la mise à jour des systèmes d'exploitation, la gestion des autorités de certification et l'ingénierie de la redondance multi-sites consomment de précieuses ressources informatiques. Cloud RADIUS (ou RADIUS en tant que service) y remédie en migrant la couche d'authentification IEEE 802.1X vers une infrastructure cloud gérée et hautement disponible. Ce guide offre un aperçu technique complet de Cloud RADIUS aux responsables informatiques, architectes réseau et CTO évaluant les stratégies de déploiement. En passant de systèmes à forte intensité de capital (capex) et maintenus manuellement à un modèle élastique et distribué mondialement, les organisations des secteurs du Commerce de détail , de l' Hôtellerie et du Transport peuvent appliquer des politiques d'accès robustes, assurer la conformité (telle que PCI DSS et GDPR) et s'intégrer de manière transparente avec les fournisseurs d'identité modernes comme Microsoft Entra ID et Google Workspace.

Approfondissement Technique

L'Évolution de l'Architecture RADIUS

RADIUS, défini initialement dans le RFC 2865, fonctionne sur un modèle client-serveur où les serveurs d'accès réseau (NAS) — tels que les points d'accès WiFi ou les concentrateurs VPN — transmettent les requêtes d'authentification à un serveur central. Historiquement, cela impliquait le déploiement de FreeRADIUS ou de Microsoft Network Policy Server (NPS) sur du matériel dédié. Bien que fonctionnelle pour les déploiements sur un seul site, l'extension de cette architecture à des environnements distribués introduit des défis importants en matière de latence et de redondance.

Cloud RADIUS abstrait l'infrastructure sous-jacente. Les requêtes d'authentification sont acheminées vers des points de terminaison cloud distribués mondialement, garantissant des temps de réponse inférieurs à 100 ms même sous des charges de pointe. Cette élasticité est cruciale pour les environnements à haute densité comme les stades ou les centres de conférence.

architecture_overview.png

Méthodes EAP et Posture de Sécurité

Le choix de la méthode du protocole d'authentification extensible (EAP) dicte fondamentalement votre posture de sécurité :

  • PEAP (Protected EAP) : Tunnelise MSCHAPv2 au sein d'une session TLS. Bien que largement pris en charge et facile à intégrer avec Active Directory, PEAP est vulnérable à la collecte d'informations d'identification via des points d'accès non autorisés si les appareils clients ne sont pas strictement configurés pour valider le certificat du serveur.
  • EAP-TLS : La norme d'or pour les entreprises. Il nécessite une authentification mutuelle par certificat — le serveur et le client doivent tous deux présenter des certificats valides. Cela élimine entièrement les attaques basées sur les mots de passe mais nécessite une infrastructure à clé publique (PKI) robuste et une intégration de la gestion des appareils mobiles (MDM) pour le déploiement des certificats.
  • EAP-TTLS et EAP-FAST : Offrent des alternatives lorsque une large compatibilité client (y compris les systèmes hérités ou Linux) est requise, ou lorsque les dépendances de validation de certificat doivent être contournées à l'aide de Protected Access Credentials (PACs).

Intégration WPA3 et OpenRoaming

Les déploiements modernes doivent prendre en compte WPA3-Enterprise, qui impose le mode de sécurité 192 bits pour les classifications les plus élevées, nécessitant des suites de chiffrement spécifiques. De plus, Cloud RADIUS facilite la participation aux cadres de fédération comme OpenRoaming. Purple, par exemple, agit comme un fournisseur d'identité gratuit pour OpenRoaming sous sa licence Connect, permettant une authentification transparente et sécurisée sur les réseaux mondiaux participants.

Guide d'Implémentation

Le déploiement de Cloud RADIUS nécessite une approche systématique pour garantir une interruption de service nulle pendant la transition.

Étape 1 : Intégration du Fournisseur d'Identité (IdP)

Votre instance Cloud RADIUS doit se synchroniser avec votre annuaire d'utilisateurs faisant autorité. L'approvisionnement natif SAML ou SCIM avec Microsoft Entra ID, Google Workspace ou Okta est fortement recommandé par rapport aux proxys LDAP manuels ou aux importations CSV. Cela garantit que lorsqu'un employé est désactivé dans le système RH, son accès réseau est révoqué instantanément.

Étape 2 : Stratégie de Gestion des Certificats

Si vous déployez EAP-TLS, définissez le cycle de vie de vos certificats. Sélectionnez un fournisseur Cloud RADIUS qui inclut une PKI intégrée ou s'intègre proprement à votre autorité de certification (CA) existante. Automatisez l'émission et la révocation des certificats via votre plateforme MDM (par exemple, Intune ou Jamf) pour éviter les échecs d'authentification dus à des certificats expirés.

Étape 3 : Configuration des Appareils Réseau

Configurez vos appareils NAS (points d'accès, commutateurs) pour qu'ils pointent vers les adresses IP Cloud RADIUS primaires et secondaires. Assurez-vous que le secret partagé est cryptographiquement complexe (minimum 32 caractères aléatoires). Ajustez les paramètres de délai d'expiration du basculement ; un délai de 3 à 5 secondes est optimal pour éviter les retards d'authentification prolongés si le nœud principal est inaccessible.

Étape 4 : Définition des Politiques

Établissez des politiques par SSID. Par exemple, imposez EAP-TLS pour le réseau d'entreprise, PEAP pour les appareils IoT hérités et isolez l'accès invité. Notez que RADIUS gère les utilisateurs connus ; pour les visiteurs, déployez une solution Guest WiFi dédiée avec un Captive Portal pour collecter des données de première partie, en l'intégrant à une plateforme WiFi Analytics . Pour en savoir plus sur l'engagement des invités, consultez Comment améliorer la satisfaction des invités : Le guide ultime .

comparison_chart.png

Bonnes Pratiques

  • Mettre en œuvre des Certificats Serveur StrictsValidation des certificats : Pour les déploiements PEAP, appliquez des stratégies de groupe ou des profils MDM qui forcent les clients à valider le certificat du serveur RADIUS et à restreindre la confiance à des Root CAs spécifiques.
  • Segmenter le trafic de comptabilité et d'authentification : Assurez-vous que les données de comptabilité RADIUS sont activement surveillées et conservées. Cette piste d'audit est essentielle pour les rapports de conformité (par exemple, PCI DSS, HIPAA).
  • Surveiller la latence d'authentification : Une latence élevée indique souvent un routage sous-optimal ou des problèmes de synchronisation IdP. Utilisez des outils de surveillance pour suivre le temps écoulé entre le paquet Access-Request et le paquet Access-Accept.
  • Optimiser la planification du signal et des canaux : Une authentification fiable repose sur une couche physique stable. Consultez des guides tels que Comprendre le RSSI et la force du signal pour une planification optimale des canaux pour vous assurer que votre environnement RF prend en charge l'itinérance 802.1X transparente.

Dépannage et atténuation des risques

Même avec des services gérés, des erreurs de configuration peuvent entraîner des échecs d'accès. Les modes de défaillance courants incluent :

  • Expiration du certificat : La cause numéro un des échecs EAP-TLS. Atténuation : Mettez en œuvre une alerte automatisée 30 jours avant l'expiration du certificat CA ou du serveur.
  • Incompatibilité du secret partagé : Se produit souvent lors de l'ajout de nouveaux points d'accès. Atténuation : Standardisez les modèles de configuration dans votre système de gestion de réseau.
  • Problèmes de NAT et de liste blanche IP : Les fournisseurs Cloud RADIUS exigent généralement la mise en liste blanche des NAS IP. Si vos succursales utilisent des IPs dynamiques ou des configurations NAT complexes, les requêtes d'authentification peuvent être abandonnées. Atténuation : Utilisez des IPs de sortie statiques ou déployez un proxy RADIUS local si nécessaire.
  • Échecs de synchronisation IdP : Si l'annuaire cloud ne parvient pas à se synchroniser avec l'AD sur site, les nouveaux utilisateurs ne peuvent pas s'authentifier. Atténuation : Surveillez activement l'état du connecteur SCIM/LDAP.

ROI et impact commercial

La transition vers Cloud RADIUS offre une valeur commerciale mesurable :

  1. Réduction du Capex d'infrastructure : Élimine le besoin d'acheter, d'installer et d'alimenter des serveurs RADIUS physiques sur chaque site majeur.
  2. Réduction des frais généraux d'exploitation : Les équipes informatiques ne passent plus des heures à corriger les vulnérabilités OS ou à gérer manuellement le basculement des serveurs. Les mises à jour gérées par le fournisseur garantissent une conformité continue.
  3. Amélioration de la posture de sécurité : La transition vers EAP-TLS via une PKI cloud atténue le risque de vol d'identifiants, réduisant directement le coût potentiel d'une violation de données.
  4. Agilité et évolutivité : Lors de l'ouverture d'une nouvelle succursale de vente au détail ou d'un hôtel, l'authentification réseau peut être provisionnée en quelques minutes plutôt qu'en quelques semaines. Pour des stratégies de déploiement pratiques, consultez Mettre en place le WiFi pour les entreprises : Un guide pour 2026 .

En centralisant le contrôle d'accès, les organisations sécurisent non seulement leurs périmètres, mais libèrent également les ingénieurs seniors pour qu'ils se concentrent sur des initiatives stratégiques plutôt que sur la maintenance d'infrastructures héritées.

Définitions clés

Cloud RADIUS

A managed service that hosts the Remote Authentication Dial-In User Service protocol in a highly available cloud environment, eliminating the need for on-premises authentication servers.

Evaluated by IT teams seeking to reduce hardware capex and operational overhead while maintaining secure 802.1X network access.

EAP-TLS (Extensible Authentication Protocol-Transport Layer Security)

A highly secure authentication method requiring both the client and the server to present digital certificates to prove their identity.

The recommended standard for enterprise networks to prevent password-based attacks, requiring PKI and MDM for deployment.

NAS (Network Access Server)

The device—such as a WiFi access point, switch, or VPN concentrator—that acts as the RADIUS client, forwarding user credentials to the RADIUS server.

Network engineers must configure the NAS with the correct RADIUS server IPs and shared secrets to enable 802.1X authentication.

Shared Secret

A cryptographic text string known only to the NAS and the RADIUS server, used to encrypt RADIUS packets and verify the sender's authenticity.

A weak shared secret is a major security vulnerability; enterprise deployments should use long, randomly generated strings.

SCIM (System for Cross-domain Identity Management)

An open standard that automates the exchange of user identity information between IT systems or cloud applications.

Used to automatically provision and de-provision users in the Cloud RADIUS directory when changes are made in the primary HR or IT identity system.

OpenRoaming

A federation framework developed by the Wireless Broadband Alliance that allows users to automatically and securely connect to participating WiFi networks globally.

Cloud RADIUS providers that support OpenRoaming (like Purple) allow venues to offer seamless, secure connectivity to visitors without captive portals.

Accounting Logs

Records generated by the RADIUS server detailing user connection events, including start time, end time, data transferred, and IP address assigned.

Critical for security audits, troubleshooting, and demonstrating compliance with frameworks like PCI DSS and GDPR.

Change of Authorization (CoA)

A RADIUS feature that allows the server to dynamically modify a user's active session, such as changing their VLAN or disconnecting them, without requiring a reconnection.

Used by network administrators to instantly quarantine a compromised device or apply new policy restrictions mid-session.

Exemples concrets

A 200-room hotel currently uses on-premises Microsoft NPS for staff WiFi authentication via PEAP. They are experiencing authentication timeouts during peak check-in hours and want to migrate to Cloud RADIUS with EAP-TLS for better security and reliability. How should the IT Director architect this migration?

  1. Deploy a Cloud RADIUS tenant and integrate it with the hotel's Microsoft Entra ID via SCIM for automated user lifecycle management. 2. Configure the Cloud RADIUS integrated PKI to issue client certificates. 3. Use the existing MDM (e.g., Intune) to push the Root CA, client certificates, and a new WiFi profile configured for EAP-TLS to all staff devices. 4. Configure the hotel's access points to point to the primary and secondary Cloud RADIUS IPs, using a new, complex 32-character shared secret. 5. Run both the old NPS and new Cloud RADIUS in parallel on different SSIDs for a two-week transition period before decommissioning the on-premise servers.
Commentaire de l'examinateur : This approach minimizes risk by running parallel SSIDs during the transition. Moving to EAP-TLS eliminates the credential harvesting risks associated with PEAP, and leveraging MDM for certificate deployment ensures zero friction for the end users. The SCIM integration guarantees that when staff leave, their access is instantly revoked.

A national retail chain with 500 locations needs to ensure PCI DSS compliance for its point-of-sale (POS) terminals, which connect via WiFi. They are moving to Cloud RADIUS. What specific configurations are required to meet compliance?

  1. Implement strict network segmentation: POS terminals must authenticate to a dedicated, hidden SSID mapped to an isolated VLAN. 2. Enforce EAP-TLS authentication for all POS devices to ensure mutual authentication and prevent rogue devices from joining the POS network. 3. Configure the Cloud RADIUS service to retain all accounting logs (Access-Accept, Access-Reject, connection duration) for a minimum of one year, as mandated by PCI DSS. 4. Ensure the RADIUS shared secrets between the branch APs and the Cloud RADIUS service are rotated every 90 days using an automated script.
Commentaire de l'examinateur : This solution directly addresses PCI DSS requirements for logical segmentation, strong access control, and auditability. Relying on MAC address filtering is insufficient for compliance; EAP-TLS provides the necessary cryptographic proof of device identity. Retaining accounting logs in the cloud simplifies the audit process for the QSA.

Questions d'entraînement

Q1. Your organisation is migrating from an on-premises Active Directory to Google Workspace. You currently use PEAP-MSCHAPv2 for WiFi authentication. Why is this a problem, and what is the recommended solution?

Conseil : Consider how PEAP validates credentials against the directory protocol.

Voir la réponse type

PEAP-MSCHAPv2 relies on the NT hash of a user's password, which Google Workspace does not store or expose natively. The recommended solution is to migrate to EAP-TLS using a Cloud RADIUS provider that features an integrated PKI. The Cloud RADIUS service can sync user identities from Google Workspace via SAML/SCIM, and authenticate devices using client certificates rather than passwords.

Q2. A branch office reports that users are experiencing 30-second delays when connecting to the WiFi network, followed by a successful connection. The primary Cloud RADIUS IP in that region is currently undergoing maintenance. What configuration error is causing this delay?

Conseil : Look at the communication between the NAS and the RADIUS servers.

Voir la réponse type

The NAS (Access Point or Switch) has the RADIUS server timeout configured too high (e.g., 30 seconds). It is waiting for the primary server to respond before failing over to the secondary server. The timeout should be reduced to 3-5 seconds to ensure rapid failover without impacting the user experience.

Q3. You are deploying Cloud RADIUS for a hospital. The security team mandates that only corporate-owned devices can connect to the internal network, even if an employee knows a valid username and password. How do you enforce this?

Conseil : Which EAP method verifies the device's identity, not just the user's knowledge?

Voir la réponse type

Deploy EAP-TLS. Configure the hospital's MDM solution to push a unique client certificate only to enrolled, corporate-owned devices. Configure the Cloud RADIUS policy to reject any authentication request that does not present a valid certificate signed by the trusted internal PKI, effectively blocking BYOD or rogue devices regardless of password knowledge.