Passer au contenu principal
Français
Tarifs

La Checklist pour la Migration d'un NAC Hérité vers un NAC Cloud-Natif

Ce guide de référence technique faisant autorité fournit une checklist structurée en trois phases pour la migration d'un système de contrôle d'accès réseau (NAC) hérité vers une architecture cloud-native. Il dote les responsables informatiques et les architectes réseau de stratégies concrètes pour gérer l'intégration des identités, la parité des politiques et la conformité sans perturber les opérations des sites.

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

Écouter ce guide

Voir la transcription du podcast
The Checklist for Migrating from Legacy NAC to Cloud-Native NAC A Purple WiFi Intelligence Briefing — approximately 10 minutes --- INTRODUCTION AND CONTEXT — approximately 1 minute Welcome to the Purple WiFi Intelligence Briefing. I'm your host, and today we're tackling one of the most consequential infrastructure decisions facing network architects and IT directors right now: migrating away from legacy Network Access Control to a cloud-native NAC architecture. If you're running a hotel group, a retail estate, a stadium, or a public-sector campus, the odds are high that your current NAC deployment is either end-of-life, struggling to scale, or creating compliance headaches you simply cannot afford heading into the second half of this decade. GDPR enforcement is tightening. PCI DSS version 4 is fully in force. And your guest and staff WiFi estate is growing faster than your on-premises hardware can keep up with. So today I want to give you a practical, structured checklist — the kind of thing a senior solutions architect would walk you through before you sign any migration contract. We'll cover what to audit before you start, how to run a parallel deployment safely, where the real risks sit, and how to measure whether the migration has actually delivered value. Let's get into it. --- TECHNICAL DEEP-DIVE — approximately 5 minutes Let's start with the fundamentals. Legacy NAC — think Cisco ISE on ageing hardware, or a RADIUS server bolted onto a decade-old directory — was designed for a world where your network perimeter was well-defined, your devices were corporate-managed, and your guest traffic was an afterthought. That world is gone. Cloud-native NAC flips the model. Policy enforcement is decoupled from hardware. Your control plane lives in the cloud, your enforcement points are lightweight agents or API-integrated access points, and your identity store is federated — typically integrating with Azure Active Directory, Okta, or a purpose-built guest identity platform like Purple. So what does the checklist actually look like? I break it into three phases. Phase one is pre-migration assessment. Before you touch a single configuration, you need a complete inventory of your existing NAC infrastructure. That means every RADIUS server, every supplicant policy, every VLAN assignment, and every integration point — your SIEM, your ITSM ticketing system, your directory services. You need to know exactly what your legacy system is doing before you can replicate it in the cloud. Within that inventory, pay particular attention to three things. First, your IEEE 802.1X deployment. Document every EAP method in use — EAP-TLS, PEAP-MSCHAPv2, whatever you're running — because your cloud-native NAC needs to support the same methods or you'll have endpoint authentication failures on day one. Second, your guest WiFi flows. If you're running a captive portal today, understand exactly how it integrates with your NAC — is it inline, is it redirect-based, is it using a RADIUS CoA to change VLAN post-authentication? Purple's guest WiFi platform, for instance, handles this natively with cloud-based policy enforcement, but you need to map your current flow before you can migrate it. Third, your compliance posture. If you're in scope for PCI DSS, you need to document your current network segmentation — specifically how cardholder data environments are isolated from guest and staff networks. Cloud-native NAC can actually make this cleaner, but the migration itself is a change event that needs to be documented for your QSA. Phase two is the parallel run. This is where most migrations either succeed or fail. The right approach is to deploy your cloud-native NAC in shadow mode alongside your legacy system. You're not cutting over yet — you're validating policy parity. Every access decision your legacy system makes, you want to see the same decision from the cloud-native system. Run this for a minimum of two weeks, ideally four. Use a subset of real endpoints — a pilot group of staff devices, a single guest SSID at one venue — and compare authentication logs side by side. During the parallel run, there are three specific things to validate. One: latency. Cloud-native RADIUS authentication should be sub-100 milliseconds for the vast majority of requests. If you're seeing higher latency, check your RADIUS proxy configuration and your cloud region selection. Two: policy fidelity. Every role assignment, every VLAN tag, every access restriction — does the cloud system match the legacy system? Any divergence is a potential security gap or a user experience failure. Three: failover behaviour. What happens when the cloud control plane is temporarily unreachable? Your enforcement points need a defined fallback policy — typically either fail-open for guest traffic or fail-closed for staff and IoT. Document this explicitly. Phase three is full cutover and optimisation. Once you've validated policy parity, you cut over in a maintenance window. The key here is sequencing: cut over guest traffic first — it's the lowest risk and the easiest to roll back. Then staff SSIDs. Then wired 802.1X if applicable. Finally, IoT and operational technology networks, which often have the most brittle authentication configurations and need the most care. Post-cutover, your first thirty days are about optimisation. Cloud-native NAC gives you telemetry you simply didn't have before — per-device authentication rates, policy hit counts, anomalous behaviour flags. Use that data. Purple's WiFi analytics platform, for example, surfaces device dwell time, connection patterns, and authentication anomalies in a single dashboard, which is enormously useful for tuning your post-migration policies. One more technical point worth calling out: WPA3. If you're migrating your NAC, this is the right moment to also evaluate your encryption standard. WPA3-Enterprise with 192-bit mode is now the recommendation for high-security environments under the Wi-Fi Alliance's security certification programme. It's not mandatory for most guest WiFi deployments, but for staff and IoT networks handling sensitive data, the upgrade is worth the parallel effort. --- IMPLEMENTATION RECOMMENDATIONS AND PITFALLS — approximately 2 minutes Let me give you the three most common failure modes I see in NAC migrations, and how to avoid them. Failure mode one: underestimating the identity dependency. Cloud-native NAC is only as good as your identity infrastructure. If your Active Directory is poorly maintained — stale accounts, inconsistent group memberships, no MFA enforcement — you will replicate those problems in the cloud at scale and with greater visibility to attackers. Before you migrate your NAC, do an identity hygiene audit. Clean up stale accounts. Enforce MFA on all privileged identities. Federate your guest identity through a purpose-built platform rather than trying to bolt guests onto your corporate directory. Failure mode two: ignoring IoT. In hospitality and retail environments, IoT devices — door controllers, HVAC sensors, digital signage, POS terminals — often authenticate via MAC address bypass, which is a weak authentication method that legacy NAC has historically tolerated. Cloud-native NAC gives you the opportunity to enforce proper certificate-based authentication for IoT, but this requires a device certificate deployment project that many organisations underestimate. Budget for it separately. Failure mode three: treating the migration as a one-time project. Cloud-native NAC is not a set-and-forget deployment. The value is in the ongoing telemetry and policy automation. If you don't assign ownership of the platform post-migration — a named network security engineer or a managed service partner — you will drift back to the same compliance and visibility gaps you had with your legacy system within twelve months. --- RAPID-FIRE Q&A — approximately 1 minute A few questions I get asked regularly. "How long does a typical migration take?" For a single-site deployment, four to eight weeks from assessment to full cutover. For a multi-site estate — say, a hotel group with fifty properties — allow six to twelve months, running a rolling programme site by site. "Do we need to replace our access points?" Not necessarily. Most cloud-native NAC platforms support standard RADIUS authentication, so your existing 802.1X-capable APs will work. However, if your APs are more than five years old and don't support WPA3 or modern management APIs, the migration is a good catalyst to refresh the hardware simultaneously. "What about GDPR and guest data?" Cloud-native NAC, combined with a proper guest WiFi platform, actually improves your GDPR posture. You get centralised consent management, data residency controls, and automated retention policies — all of which are significantly harder to implement on legacy on-premises infrastructure. --- SUMMARY AND NEXT STEPS — approximately 1 minute To summarise: migrating from legacy NAC to cloud-native NAC is not just an infrastructure refresh — it's a strategic shift in how you manage network access, compliance, and guest intelligence at scale. The checklist is clear. Audit your existing infrastructure thoroughly before you start. Run a parallel deployment to validate policy parity. Cut over in a sequenced, low-risk order. And invest in the ongoing telemetry and policy automation that makes cloud-native NAC genuinely superior to what came before. If you're evaluating platforms, Purple's guest WiFi and analytics capabilities integrate natively with cloud-native NAC architectures, giving you a single pane of glass for guest identity, network policy, and venue analytics. It's worth a conversation with the team. Thanks for listening to the Purple WiFi Intelligence Briefing. Full technical documentation, architecture diagrams, and the written version of this checklist are available at purple.ai. Until next time.

header_image.png

Résumé Exécutif

La migration d'un système de contrôle d'accès réseau (NAC) hérité vers une architecture cloud-native n'est plus une mise à niveau facultative ; c'est une exigence essentielle pour maintenir la sécurité, l'évolutivité et la conformité dans les environnements d'entreprise modernes. Les systèmes hérités, souvent dépendants de matériel sur site vieillissant et de structures d'annuaire rigides, peinent à prendre en charge la croissance explosive des appareils IoT, la mobilité dynamique du personnel et les exigences strictes de l'accès invité moderne. Pour les directeurs des opérations de sites et les responsables informatiques des secteurs de l'hôtellerie, du commerce de détail et des services publics, la transition vers un NAC cloud-natif atténue les risques de défaillance matérielle et de fragmentation des politiques tout en permettant une automatisation pilotée par API.

Ce guide de référence technique fournit une checklist complète pour l'exécution de cette migration. Il décrit une approche structurée en trois phases : Évaluation Pré-Migration, Exécution Parallèle & Validation, et Basculement Complet & Optimisation. En découplant l'application des politiques du matériel et en fédérant les référentiels d'identité, les organisations peuvent réaliser un provisionnement sans contact, une application robuste de la norme IEEE 802.1X et une intégration transparente avec les outils de l'écosystème. De manière cruciale, ce guide détaille comment tirer parti de plateformes comme Purple pour unifier l'identité des invités et la politique réseau, garantissant que la migration offre un ROI opérationnel immédiat et une posture de sécurité renforcée.

Approfondissement Technique

Le changement fondamental dans le passage d'un NAC hérité à un NAC cloud-natif implique le découplage du plan de contrôle du plan de données. Les architectures héritées reposent généralement sur des serveurs RADIUS monolithiques et des appliances physiques déployées en périphérie ou agrégées dans un centre de données central. Ce modèle crée des goulots d'étranglement, augmente la latence pour les sites distribués et exige une intervention manuelle constante pour maintenir la cohérence des politiques.

Le NAC cloud-natif abstrait le moteur de politique et le fournisseur d'identité (IdP) dans un environnement cloud évolutif. L'application est poussée vers la périphérie, soit via des agents logiciels légers, soit par intégration API directe avec des points d'accès et des commutateurs modernes. Cette architecture modifie fondamentalement la manière dont l'authentification et l'autorisation sont traitées.

Fédération d'Identité et RADIUS

Au cœur de la migration se trouve la transition de la gestion des identités. Les NAC hérités s'appuient souvent sur des liaisons LDAP directes vers un Active Directory sur site. Les solutions cloud-natives privilégient les intégrations SAML ou OIDC avec des fournisseurs d'identité cloud tels qu'Azure AD ou Okta. Lors de la migration, l'infrastructure RADIUS doit être modernisée. Les services Cloud RADIUS gèrent les authentifications IEEE 802.1X (par exemple, EAP-TLS, PEAP-MSCHAPv2) à l'échelle mondiale, réduisant la latence en acheminant les requêtes vers le point de présence géographique le plus proche.

Il est essentiel de documenter chaque méthode de protocole d'authentification extensible (EAP) actuellement utilisée. Un échec de prise en charge des types EAP existants dans le nouvel environnement entraînera des échecs d'authentification immédiats pour les terminaux. De plus, pour l'accès invité, l'intégration d'une plateforme Guest WiFi robuste comme Purple permet l'application de politiques basées sur le cloud, en abstrayant la complexité du changement d'autorisation (CoA) RADIUS et des attributions de VLAN du matériel local.

Segmentation Réseau et Conformité

Le NAC moderne ne concerne pas seulement l'accès ; il s'agit de segmentation dynamique. Dans les environnements soumis à PCI DSS ou GDPR, la capacité d'attribuer dynamiquement des VLAN ou d'appliquer des politiques de micro-segmentation basées sur le rôle de l'utilisateur, la posture de l'appareil et l'emplacement est primordiale. Le NAC cloud-natif évalue le contexte — qui, quoi, où et quand — avant d'accorder l'accès.

Pendant la migration, les attributions de VLAN statiques existantes doivent être mappées à des politiques dynamiques. Par exemple, un terminal de point de vente (POS) doit être isolé du réseau invité et du réseau général du personnel. Le moteur de politique cloud évalue l'adresse MAC de l'appareil (ou idéalement, un certificat d'appareil) et ordonne à l'infrastructure réseau de le placer dans la zone sécurisée conforme à la norme PCI.

architecture_overview.png

Guide d'Implémentation

L'exécution de la migration nécessite une approche disciplinée et progressive afin de minimiser les perturbations pour les sites actifs et les opérations commerciales critiques.

Phase 1 : Évaluation Pré-Migration

Avant de modifier toute configuration, un inventaire complet de l'écosystème NAC existant est obligatoire. Cela inclut le mappage de tous les serveurs RADIUS, des configurations des supplicants, des schémas VLAN et des intégrations tierces (telles que les plateformes SIEM ou ITSM).

  1. Auditer les Sources d'Identité : Identifier tous les annuaires et bases de données utilisés pour l'authentification. Nettoyer les comptes obsolètes et appliquer la MFA sur les identités privilégiées.
  2. Mapper les Méthodes EAP : Documenter toutes les méthodes IEEE 802.1X utilisées sur les réseaux filaires et sans fil.
  3. Analyser les Flux Invités : Documenter l'intégration actuelle du Captive Portal. Évaluer comment une solution Guest WiFi moderne peut rationaliser ce processus.
  4. Examiner les Appareils IoT : Identifier les appareils s'appuyant sur le MAC Authentication Bypass (MAB) et prévoir une authentification basée sur certificat lorsque cela est possible.

Phase 2 : Exécution Parallèle & Validation

La stratégie la plus efficace consiste à déployer le NAC cloud-natif en mode 'shadow' (mode fantôme) parallèlement au système hérité. Cela permet la validation des politiques sans impacter le trafic de production.

  1. Déployer le Cloud RADIUS : Configurer le NAC cloud pour recevoir les requêtes d'authentification en parallèle avec le système hérité.
  2. Valider la Parité des Politiques : Comparer les décisions d'accès (Rôle, VLAN, ACL) prises par les deux systèmes. Toute divergence doit être investiguée et résolue.
  3. Tester la Latence : S'assurer que les requêtes d'authentification cloud se terminent dans des seuils acceptables (généralement inférieurs à 100 ms).
  4. Groupes Pilotes : Migrer un petitun sous-ensemble d'utilisateurs (par exemple, le personnel informatique) ou un SSID spécifique non critique vers le nouveau système pour valider la fonctionnalité de bout en bout.

migration_phases_diagram.png

Phase 3 : Basculement Complet et Optimisation

Une fois la parité confirmée, exécutez le basculement pendant une fenêtre de maintenance planifiée.

  1. Séquencer le Basculement : Commencez par les réseaux à moindre risque. Migrez d'abord les réseaux invités, suivis par le sans fil du personnel, le 802.1X filaire, et enfin les réseaux IoT/OT.
  2. Surveiller la Télémétrie : Utilisez la visibilité améliorée de la plateforme cloud pour surveiller les taux de réussite d'authentification et identifier les comportements anormaux.
  3. Intégrer l'Analyse : Alimentez la télémétrie dans une plateforme WiFi Analytics pour obtenir des informations sur le temps de séjour des appareils, les modèles de connexion et l'utilisation spatiale.
  4. Désaffecter le Matériel Hérité : Une fois la stabilité atteinte, effacez et désaffectez en toute sécurité les appliances NAC héritées.

Bonnes Pratiques

Pour garantir un déploiement résilient et évolutif, respectez les bonnes pratiques suivantes de l'industrie :

  • Adopter WPA3-Enterprise : Lorsque le matériel le permet, imposez WPA3-Enterprise avec le mode 192 bits pour les réseaux hautement sécurisés (par exemple, finance, RH). Cela s'aligne sur les dernières normes de sécurité de la Wi-Fi Alliance. Pour une compréhension plus approfondie des normes sans fil modernes, consultez notre guide sur Wi Fi Frequencies: A Guide to Wi-Fi Frequencies in 2026 .
  • Fédérer l'Identité des Invités : Ne gérez pas les comptes invités dans les annuaires d'entreprise. Utilisez une plateforme dédiée comme Purple pour gérer l'intégration des invités, la gestion du consentement et la résidence des données, garantissant la conformité GDPR.
  • Mettre en œuvre les Principes Zero Trust : Éloignez-vous de la confiance implicite basée sur l'emplacement du réseau. Appliquez une évaluation continue de la posture pour tous les points d'extrémité avant d'accorder l'accès.
  • Automatiser l'Intégration IoT : Abandonnez le MAB en mettant en œuvre l'approvisionnement automatisé de certificats pour les appareils sans tête.

Pour plus d'informations sur l'évolution de la sécurité réseau, consultez The Future of Wi-Fi Security: AI-Driven NAC and Threat Detection et son équivalent espagnol, El Futuro de la Seguridad Wi-Fi: NAC Impulsado por IA y Detección de Amenazas .

Dépannage et Atténuation des Risques

Les migrations comportent intrinsèquement des risques. Anticiper les modes de défaillance courants est essentiel pour une transition en douceur.

Mode de Défaillance : Problèmes de Synchronisation d'Identité Si l'IdP cloud ne parvient pas à se synchroniser avec les annuaires sur site, l'authentification échouera. Atténuation : Mettez en œuvre une surveillance robuste sur les agents de synchronisation d'annuaire. Configurez des connecteurs de synchronisation redondants sur différents sites physiques.

Mode de Défaillance : Latence d'Authentification Élevée Le routage du trafic RADIUS vers une région cloud distante peut entraîner des délais d'attente sur le demandeur de point d'extrémité. Atténuation : Sélectionnez une région cloud géographiquement proche des sites. Mettez en œuvre des proxys RADIUS locaux ou des appliances de branche résilientes pour les sites critiques comme les grands magasins Retail ou les établissements de Healthcare .

Mode de Défaillance : Perte de Connectivité IoT Les appareils IoT hérités ont souvent des configurations réseau codées en dur ou ne prennent pas en charge les méthodes EAP modernes. Atténuation : Maintenez un SSID dédié et isolé avec un repli MAB spécifiquement pour les appareils IoT hérités jusqu'à ce qu'ils puissent être remplacés. Assurez-vous que ce VLAN dispose de listes de contrôle d'accès (ACL) strictes limitant les mouvements latéraux.

ROI et Impact Commercial

La transition vers un NAC cloud-native offre une valeur commerciale mesurable au-delà de la sécurité améliorée.

  • Efficacité Opérationnelle : L'approvisionnement sans contact et la gestion centralisée des politiques réduisent drastiquement les heures d'ingénierie nécessaires pour les déplacements, ajouts et modifications (MACs).
  • Économies de Matériel : Le démantèlement des appliances sur site élimine les coûts associés à l'alimentation, au refroidissement et aux contrats de maintenance.
  • Expérience Invité Améliorée : L'intégration du NAC avec une plateforme Guest WiFi moderne réduit les frictions d'intégration, entraînant des taux d'adhésion plus élevés et une collecte de données plus riche pour les équipes marketing dans les secteurs de l' Hospitality et du Transport .
  • Réduction des Risques : Les rapports de conformité automatisés et la segmentation dynamique réduisent la probabilité et l'impact potentiel d'une violation de données, diminuant les primes d'assurance cyber et protégeant la réputation de la marque.

Définitions clés

Network Access Control (NAC)

A security solution that enforces policy on devices and users attempting to access a network.

Essential for ensuring only authorised, compliant devices connect to corporate or guest networks.

Cloud-Native Architecture

Designing applications specifically to leverage cloud computing models, typically using microservices and APIs.

Allows NAC to scale infinitely and decouple policy management from local hardware constraints.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol that provides centralised Authentication, Authorization, and Accounting (AAA) management.

The core protocol used by network switches and APs to communicate with the NAC policy engine.

IEEE 802.1X

An IEEE Standard for port-based Network Access Control, providing an authentication mechanism to devices wishing to attach to a LAN or WLAN.

The gold standard for secure, enterprise-grade network authentication for staff devices.

MAC Authentication Bypass (MAB)

A method of granting network access based on the device's MAC address rather than a username/password or certificate.

Commonly used for headless IoT devices (printers, cameras) that cannot support 802.1X, though it is inherently less secure.

Dynamic Segmentation

The ability to assign network access policies (like VLANs or ACLs) dynamically based on user identity, device type, or context.

Crucial for isolating different types of traffic (e.g., keeping POS terminals separate from guest WiFi).

Identity Provider (IdP)

A system entity that creates, maintains, and manages identity information for principals and provides authentication services.

Cloud-native NAC relies on modern IdPs (Azure AD, Okta) rather than legacy on-premise LDAP servers.

Change of Authorisation (CoA)

A RADIUS extension that allows the NAC server to dynamically change the access permissions of an active session.

Used extensively in guest WiFi portals to switch a user from a restricted pre-authentication VLAN to a full access VLAN after they accept terms.

Exemples concrets

A 500-room hotel is migrating to a cloud-native NAC. They currently use a legacy on-premises RADIUS server for staff 802.1X (PEAP) and a basic captive portal for guests. They have 200 IoT devices (smart TVs, door locks) authenticating via MAB. How should they sequence the migration to minimise guest disruption?

  1. Deploy the cloud NAC and integrate it with the existing IdP for staff. 2. Integrate Purple Guest WiFi with the cloud NAC for guest access. 3. Phase 1 Cutover: Migrate the Guest SSID to the new captive portal flow. This is low risk and provides immediate marketing ROI. 4. Phase 2 Cutover: Migrate staff 802.1X. Ensure the new RADIUS server certificate is trusted by staff endpoints to prevent warnings. 5. Phase 3 Cutover: Migrate IoT devices. Create a specific policy in the cloud NAC for MAB, ensuring these devices are placed in an isolated VLAN.
Commentaire de l'examinateur : This sequenced approach isolates risk. Moving guests first provides a quick win and validates the cloud architecture. Leaving IoT until last allows time to meticulously map MAC addresses and ensure the new MAB policies are correctly configured before cutover.

A large retail chain with 150 stores is experiencing high latency (over 500ms) during the parallel run phase of their cloud NAC migration, causing POS terminals to timeout during authentication.

The latency is likely caused by the geographical distance between the stores and the cloud RADIUS region, or inefficient directory lookups. The solution is to: 1. Verify the cloud NAC tenant is hosted in the optimal geographic region. 2. Deploy a lightweight RADIUS proxy or survivable edge appliance in regional hubs to cache authentications and handle local EAP terminations. 3. Ensure the IdP integration is using fast, indexed lookups (e.g., native Azure AD integration rather than querying an on-prem LDAP server over a VPN).

Commentaire de l'examinateur : Retail environments are highly sensitive to latency, especially for POS systems. The solution correctly identifies the need to move the authentication decision closer to the edge, either geographically or via local caching, which is a standard architectural pattern for distributed enterprises.

Questions d'entraînement

Q1. Your organisation is migrating from Cisco ISE to a cloud-native NAC. During the parallel run, you notice that a specific group of older barcode scanners in your warehouse are failing authentication on the cloud NAC, but succeeding on ISE. What is the most likely cause and how should you address it?

Conseil : Consider how older devices handle encryption and protocol negotiation.

Voir la réponse type

The most likely cause is a mismatch in supported EAP methods or cipher suites. The cloud NAC may have deprecated older, less secure protocols (like TLS 1.0 or specific weak ciphers) that the legacy ISE server still permitted. To address this, you must either update the firmware/supplicant on the barcode scanners to support modern protocols, or, if that is not possible, configure a specific, isolated policy in the cloud NAC to temporarily permit the older protocol strictly for that device group, mitigating the security risk via strict network segmentation.

Q2. A university campus wants to implement WPA3-Enterprise for its staff network alongside the NAC migration. However, 15% of staff laptops are running older wireless NICs that do not support WPA3. How should the network architect design the SSIDs?

Conseil : Consider transition modes and the impact on security posture.

Voir la réponse type

The architect should configure the staff SSID to use WPA3-Enterprise Transition Mode. This allows capable devices to connect using WPA3-Enterprise, while older devices fall back to WPA2-Enterprise. Alternatively, if strict security compliance is required for specific departments, a dedicated WPA3-only SSID can be created for compliant devices, leaving the legacy SSID active until the remaining hardware is refreshed.

Q3. During Phase 1 (Pre-Migration Assessment), you discover that the current guest WiFi relies heavily on RADIUS CoA to move users from a walled-garden VLAN to an internet-access VLAN. The new cloud APs do not reliably support CoA over the WAN. What is the recommended architectural change?

Conseil : Consider how modern guest platforms handle policy enforcement without relying on complex local VLAN switching.

Voir la réponse type

The recommended approach is to shift away from local VLAN switching and utilize a cloud-managed guest WiFi platform (like Purple). In this model, the AP places all guest traffic into a single guest VLAN. The captive portal and policy enforcement (bandwidth limiting, content filtering, session time) are handled either by the AP's built-in firewall or a cloud gateway, abstracting the need for RADIUS CoA entirely and simplifying the edge configuration.