Zum Hauptinhalt springen
Deutsch
Preise

Die Checkliste für die Migration von Legacy NAC zu Cloud-Native NAC

Dieser maßgebliche technische Leitfaden bietet eine strukturierte, dreiphasige Checkliste für die Migration von der traditionellen Netzwerkzugriffskontrolle (NAC) zu einer Cloud-nativen Architektur. Er stattet IT-Manager und Netzwerkarchitekten mit umsetzbaren Strategien aus, um die Identitätsintegration, Richtlinienkonsistenz und Compliance zu gewährleisten, ohne den Veranstaltungsbetrieb zu stören.

📖 6 Min. Lesezeit📝 1,336 Wörter🔧 2 ausgearbeitete Beispiele❓ 3 Übungsfragen📚 8 Schlüsseldefinitionen

Diesen Leitfaden anhören

Podcast-Transkript ansehen
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

Zusammenfassung für die Geschäftsleitung

Die Migration von der traditionellen Netzwerkzugriffskontrolle (NAC) zu einer Cloud-nativen Architektur ist kein optionales Upgrade mehr; sie ist eine kritische Anforderung zur Aufrechterhaltung von Sicherheit, Skalierbarkeit und Compliance in modernen Unternehmensumgebungen. Traditionelle Systeme, die oft auf alternder On-Premises-Hardware und starren Verzeichnisstrukturen basieren, haben Schwierigkeiten, das explosive Wachstum von IoT-Geräten, die dynamische Mitarbeitermobilität und die strengen Anforderungen des modernen Gastzugangs zu unterstützen. Für Betriebsleiter von Veranstaltungsorten und IT-Manager in den Bereichen Gastgewerbe, Einzelhandel und öffentlicher Sektor mindert der Übergang zu einem Cloud-nativen NAC die Risiken von Hardwareausfällen und Richtlinienfragmentierung und ermöglicht gleichzeitig die API-gesteuerte Automatisierung.

Dieser technische Leitfaden bietet eine umfassende Checkliste für die Durchführung dieser Migration. Er skizziert einen strukturierten dreiphasigen Ansatz: Pre-Migration Assessment (Vormigrationsbewertung), Parallel Run & Validation (Parallelbetrieb und Validierung) und Full Cutover & Optimisation (Vollständige Umstellung und Optimierung). Durch die Entkopplung der Richtliniendurchsetzung von der Hardware und die Föderation von Identitätsspeichern können Unternehmen Zero-Touch-Provisioning, eine robuste IEEE 802.1X-Durchsetzung und eine nahtlose Integration mit Ökosystem-Tools erreichen. Entscheidend ist, dass dieser Leitfaden detailliert beschreibt, wie Plattformen wie Purple genutzt werden können, um Gastidentität und Netzwerkrichtlinien zu vereinheitlichen und sicherzustellen, dass die Migration einen sofortigen operativen ROI und eine verbesserte Sicherheitslage liefert.

Technischer Tiefen-Einblick

Der grundlegende Wandel beim Übergang von Legacy zu Cloud-native NAC beinhaltet die Entkopplung der Steuerungsebene von der Datenebene. Legacy-Architekturen basieren typischerweise auf monolithischen RADIUS-Servern und physischen Appliances, die am Netzwerkrand bereitgestellt oder in einem zentralen Rechenzentrum aggregiert werden. Dieses Modell erzeugt Engpässe, erhöht die Latenz für verteilte Standorte und erfordert ständige manuelle Eingriffe, um die Richtlinienkonsistenz aufrechtzuerhalten.

Cloud-native NAC abstrahiert die Richtlinien-Engine und den Identitätsanbieter (IdP) in eine skalierbare Cloud-Umgebung. Die Durchsetzung wird an den Netzwerkrand verlagert, entweder über leichte Software-Agenten oder direkte API-Integration mit modernen Access Points und Switches. Diese Architektur verändert grundlegend, wie Authentifizierung und Autorisierung verarbeitet werden.

Identitätsföderation und RADIUS

Im Mittelpunkt der Migration steht der Übergang des Identitätsmanagements. Legacy NAC basiert oft auf direkten LDAP-Bindungen zu lokalen Active Directorys. Cloud-native Lösungen bevorzugen SAML- oder OIDC-Integrationen mit Cloud-Identitätsanbietern wie Azure AD oder Okta. Bei der Migration muss die RADIUS-Infrastruktur modernisiert werden. Cloud RADIUS-Dienste verarbeiten IEEE 802.1X-Authentifizierungen (z. B. EAP-TLS, PEAP-MSCHAPv2) global und reduzieren die Latenz, indem sie Anfragen an den nächstgelegenen geografischen Präsenzpunkt weiterleiten.

Es ist entscheidend, jede derzeit verwendete Extensible Authentication Protocol (EAP)-Methode zu dokumentieren. Eine fehlende Unterstützung bestehender EAP-Typen in der neuen Umgebung führt zu sofortigen Authentifizierungsfehlern für Endpunkte. Darüber hinaus ermöglicht die Integration einer robusten Guest WiFi -Plattform wie Purple für den Gastzugang eine Cloud-basierte Richtliniendurchsetzung, die die Komplexität von RADIUS Change of Authorisation (CoA) und VLAN-Zuweisungen von der lokalen Hardware abstrahiert.

Netzwerksegmentierung und Compliance

Modernes NAC geht nicht nur um den Zugriff; es geht um dynamische Segmentierung. In Umgebungen, die PCI DSS oder GDPR unterliegen, ist die Fähigkeit, VLANs dynamisch zuzuweisen oder Mikrosegmentierungsrichtlinien basierend auf Benutzerrolle, Gerätestatus und Standort anzuwenden, von größter Bedeutung. Cloud-native NAC bewertet den Kontext – wer, was, wo und wann – bevor der Zugriff gewährt wird.

Während der Migration müssen bestehende statische VLAN-Zuweisungen dynamischen Richtlinien zugeordnet werden. Zum Beispiel muss ein POS-Terminal vom Gastnetzwerk und dem allgemeinen Mitarbeiternetzwerk isoliert werden. Die Cloud-Richtlinien-Engine bewertet die MAC-Adresse des Geräts (oder idealerweise ein Gerätezertifikat) und weist die Netzwerkinfrastruktur an, es in die sichere PCI-konforme Zone zu platzieren.

architecture_overview.png

Implementierungsleitfaden

Die Durchführung der Migration erfordert einen disziplinierten, phasenweisen Ansatz, um Störungen des aktiven Betriebs und kritischer Geschäftsabläufe zu minimieren.

Phase 1: Vormigrationsbewertung

Bevor Konfigurationen geändert werden, ist eine vollständige Bestandsaufnahme des bestehenden NAC-Ökosystems obligatorisch. Dies umfasst die Zuordnung aller RADIUS-Server, Supplikantenkonfigurationen, VLAN-Schemata und Integrationen von Drittanbietern (wie SIEM- oder ITSM-Plattformen).

  1. Identitätsquellen prüfen: Identifizieren Sie alle Verzeichnisse und Datenbanken, die für die Authentifizierung verwendet werden. Bereinigen Sie veraltete Konten und erzwingen Sie MFA für privilegierte Identitäten.
  2. EAP-Methoden zuordnen: Dokumentieren Sie alle IEEE 802.1X-Methoden, die in kabelgebundenen und drahtlosen Netzwerken verwendet werden.
  3. Gastflüsse analysieren: Dokumentieren Sie die aktuelle Captive Portal-Integration. Bewerten Sie, wie eine moderne Guest WiFi -Lösung diesen Prozess optimieren kann.
  4. IoT-Geräte überprüfen: Identifizieren Sie Geräte, die auf MAC Authentication Bypass (MAB) basieren, und planen Sie, wo möglich, eine zertifikatbasierte Authentifizierung.

Phase 2: Parallelbetrieb und Validierung

Die effektivste Strategie ist die Bereitstellung des Cloud-nativen NAC im Schattenmodus parallel zum Legacy-System. Dies ermöglicht die Richtlinienvalidierung, ohne den Produktionsverkehr zu beeinträchtigen.

  1. Cloud RADIUS bereitstellen: Konfigurieren Sie das Cloud NAC so, dass es Authentifizierungsanfragen parallel zum Legacy-System empfängt.
  2. Richtlinienkonsistenz validieren: Vergleichen Sie die Zugriffsentscheidungen (Role, VLAN, ACL) beider Systeme. Jede Abweichung muss untersucht und behoben werden.
  3. Latenz testen: Stellen Sie sicher, dass Cloud-Authentifizierungsanfragen innerhalb akzeptabler Schwellenwerte (typischerweise unter 100 ms) abgeschlossen werden.
  4. Pilotgruppen: Migrieren Sie eine kleinTeilmenge von Benutzern (z. B. IT-Mitarbeiter) oder eine spezifische, nicht-kritische SSID in das neue System, um die End-to-End-Funktionalität zu validieren.

migration_phases_diagram.png

Phase 3: Vollständige Umstellung & Optimierung

Sobald die Parität bestätigt ist, führen Sie die Umstellung während eines geplanten Wartungsfensters durch.

  1. Umstellung sequenzieren: Beginnen Sie mit den Netzwerken mit dem geringsten Risiko. Migrieren Sie zuerst Gastnetzwerke, gefolgt von drahtlosen Mitarbeiternetzwerken, kabelgebundenem 802.1X und schließlich IoT/OT-Netzwerken.
  2. Telemetrie überwachen: Nutzen Sie die verbesserte Transparenz der Cloud-Plattform, um die Erfolgsraten der Authentifizierung zu überwachen und anomales Verhalten zu identifizieren.
  3. Analysen integrieren: Speisen Sie Telemetriedaten in eine WiFi Analytics -Plattform ein, um Einblicke in die Verweildauer von Geräten, Verbindungsmuster und räumliche Auslastung zu erhalten.
  4. Alte Hardware außer Betrieb nehmen: Sobald Stabilität erreicht ist, löschen und nehmen Sie die alten NAC-Appliances sicher außer Betrieb.

Best Practices

Um eine robuste und skalierbare Bereitstellung zu gewährleisten, halten Sie sich an die folgenden Branchen-Best Practices:

  • WPA3-Enterprise nutzen: Wo die Hardware es unterstützt, schreiben Sie WPA3-Enterprise mit 192-Bit-Modus für hochsichere Netzwerke (z. B. Finanzen, Personalwesen) vor. Dies entspricht den neuesten Sicherheitsstandards der Wi-Fi Alliance. Für ein tieferes Verständnis moderner WLAN-Standards lesen Sie unseren Leitfaden zu Wi Fi Frequencies: A Guide to Wi-Fi Frequencies in 2026 .
  • Gastidentitäten föderieren: Verwalten Sie Gastkonten nicht in Unternehmensverzeichnissen. Nutzen Sie eine speziell entwickelte Plattform wie Purple, um das Onboarding von Gästen, das Einwilligungsmanagement und die Datenresidenz zu handhaben und so die GDPR-Konformität sicherzustellen.
  • Zero-Trust-Prinzipien implementieren: Verabschieden Sie sich vom impliziten Vertrauen basierend auf dem Netzwerkstandort. Erzwingen Sie eine kontinuierliche Statusbewertung für alle Endpunkte, bevor der Zugriff gewährt wird.
  • IoT-Onboarding automatisieren: Gehen Sie weg von MAB, indem Sie eine automatisierte Zertifikatsbereitstellung für Headless-Geräte implementieren.

Für weitere Einblicke in die Entwicklung der Netzwerksicherheit lesen Sie The Future of Wi-Fi Security: AI-Driven NAC and Threat Detection und dessen spanisches Pendant, El Futuro de la Seguridad Wi-Fi: NAC Impulsado por IA y Detección de Amenazas .

Fehlerbehebung & Risikominderung

Migrationen bergen naturgemäß Risiken. Die Antizipation gängiger Fehlerursachen ist entscheidend für einen reibungslosen Übergang.

Fehlermodus: Probleme bei der Identitätssynchronisation Wenn der Cloud-IdP die Synchronisation mit lokalen Verzeichnissen nicht durchführt, schlägt die Authentifizierung fehl. Abhilfe: Implementieren Sie eine robuste Überwachung der Verzeichnissynchronisations-Agenten. Konfigurieren Sie redundante Synchronisations-Konnektoren über verschiedene physische Standorte hinweg.

Fehlermodus: Hohe Authentifizierungslatenz Das Routing von RADIUS-Verkehr zu einer entfernten Cloud-Region kann zu Timeouts beim Endpunkt-Supplikanten führen. Abhilfe: Wählen Sie eine Cloud-Region, die geografisch nahe an den Standorten liegt. Implementieren Sie lokale RADIUS-Proxys oder überlebensfähige Zweigstellen-Appliances für kritische Standorte wie große Retail -Geschäfte oder Healthcare -Einrichtungen.

Fehlermodus: Verlust der IoT-Konnektivität Alte IoT-Geräte haben oft fest codierte Netzwerkkonfigurationen oder unterstützen keine modernen EAP-Methoden. Abhilfe: Pflegen Sie eine dedizierte, isolierte SSID mit MAB-Fallback speziell für alte IoT-Geräte, bis diese ersetzt werden können. Stellen Sie sicher, dass dieses VLAN strenge ACLs zur Begrenzung der lateralen Bewegung aufweist.

ROI & Geschäftsauswirkungen

Der Übergang zu einem Cloud-nativen NAC liefert messbaren Geschäftswert, der über eine verbesserte Sicherheit hinausgeht.

  • Betriebliche Effizienz: Zero-Touch-Provisioning und zentralisiertes Richtlinienmanagement reduzieren die für Moves, Adds und Changes (MACs) erforderlichen Ingenieurstunden drastisch.
  • Hardware-Einsparungen: Die Außerbetriebnahme von lokalen Appliances eliminiert die damit verbundenen Kosten für Strom, Kühlung und Wartungsverträge.
  • Verbessertes Gasterlebnis: Die Integration des NAC mit einer modernen Guest WiFi -Plattform reduziert die Onboarding-Reibung, was zu höheren Opt-in-Raten und einer reichhaltigeren Datenerfassung für Marketingteams in den Sektoren Hospitality und Transport führt.
  • Risikoreduzierung: Automatisierte Compliance-Berichterstattung und dynamische Segmentierung reduzieren die Wahrscheinlichkeit und den potenziellen Einfluss einer Datenpanne, senken die Prämien für Cyberversicherungen und schützen den Markenruf.

Schlüsseldefinitionen

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.

Ausgearbeitete Beispiele

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.
Kommentar des Prüfers: 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).

Kommentar des Prüfers: 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.

Übungsfragen

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?

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

Musterlösung anzeigen

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?

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

Musterlösung anzeigen

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?

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

Musterlösung anzeigen

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.