Cloud RADIUS-Server erklärt: Ein praktischer Leitfaden

Sie blicken auf einen Network Policy Server, den niemand patchen möchte, einen Wireless Controller, der auf ein einzelnes RADIUS Gerät in einem Serverraum zeigt, und eine Helpdesk Warteschlange voller Passwort-Zurücksetzungen. Das Identitätsmanagement ist zu Microsoft Entra ID oder Okta umgezogen, aber die WiFi Authentifizierung hängt immer noch von einer lokalen Infrastruktur ab, die für ein lokales Active Directory gebaut wurde. Genau bei diesem Ungleichgewicht beginnen Unternehmen über einen Cloud RADIUS Server nachzudenken - nicht weil das Verschieben eines Servers spannend ist, sondern weil das alte Modell nicht mehr dazu passt, wie Benutzer, Geräte und Standorte funktionieren.

Was ein Cloud RADIUS Server ist

Stellen Sie sich RADIUS wie einen Sicherheitsdienst am Gebäudeeingang vor. Eine Person kommt an, zeigt einen Ausweis vor und der Sicherheitsdienst gleicht den Ausweis mit einer Freigabeliste ab, bevor er die Tür öffnet. Ist der Ausweis gültig, entscheidet der Sicherheitsdienst auch, welche Etagen diese Person betreten darf. Ist er ungültig, bleibt die Tür geschlossen.

Ein Cloud RADIUS Server verlegt diese Pförtnerfunktion von einer lokalen Kabine zu einem zentral verwalteten Dienst. Die Prüfung findet weiterhin an der Tür statt, was im WiFi-Bereich Ihrem Access Point oder Switch entspricht. Die Entscheidung stammt jedoch von einem gehosteten Dienst, den Sie über Richtlinien konfigurieren, anstatt Server selbst zu patchen, zu sichern und zu clustern.

So funktioniert der Authentifizierungsablauf

Ein Laptop oder Smartphone verbindet sich mit einer WPA-Enterprise-SSID, die durch 802.1X geschützt ist. Der Access Point entscheidet nicht selbstständig. Er leitet die Authentifizierungsanfrage an den Cloud-RADIUS-Server weiter, der die Anmeldedaten, das Zertifikat oder die Geräteidentität mit Ihrem Verzeichnisdienst oder Ihrer Zertifizierungsstelle abgleicht.

Der Server gibt eine Zusage oder Ablehnung zurück, häufig mit Attributen wie einem VLAN, einer Rolle oder einem Sitzungslimit. Der Access Point setzt diese Entscheidung lokal durch. Diese Trennung ist wichtig, da RADIUS der Entscheidungspunkt ist, nicht das gesamte Netzwerk und nicht Ihr Identity Provider selbst.

• Supplicant: Der Laptop, das Telefon oder das Gerät, das Zugang anfordert und Anmeldedaten oder ein Zertifikat vorlegt.
• Authenticator: Der Access Point, Controller oder Switch, der die Anfrage weiterleitet und das Ergebnis durchsetzt.
• Identitätsquelle: Microsoft Entra ID, Okta, Google Workspace, Active Directory oder eine Zertifizierungsstelle, die den maßgeblichen Datensatz hält.

Warum Hybrid der normale Ausgangspunkt ist

Britische Unternehmen haben nicht alles in einem Schritt in die Cloud verlagert. Forum Cloud Industry berichtete in seiner Studie von 2016, dass 84 % der britischen Unternehmen offiziell mindestens einen Cloud Dienst eingeführt hatten, verglichen mit 48 % im Jahr 2010. Dies erklärt, warum Cloud RADIUS in der Regel als Teil einer hybriden Architektur bereitgestellt wird und nicht als sofortiger Ersatz für jede lokale Komponente, wie in der Studie Cloud Industry Forum UK cloud adoption research for 2016 dargelegt.

In der Praxis bleiben Ihre Switches, Access Points, Drucker und Altsysteme vor Ort. Was sich ändert, ist der Ort, an dem die Authentifizierungsentscheidung getroffen wird, und wie konsistent Sie diese über mehrere Standorte hinweg anwenden können. Das ist eine präzisere und nützlichere Definition, als es nur als gehosteten Serveraustausch zu bezeichnen.

Cloud RADIUS vs. On-Premises RADIUS

Der ehrliche Vergleich lautet nicht "Cloud gut, On-Premises schlecht". Es geht darum, wer den betrieblichen Aufwand trägt, wie viel Kontrolle Sie benötigen und was passiert, wenn etwas ausfällt. Ein gut verwaltetes On-Premises-Paar kann jahrelang reibungslos laufen. Ein vernachlässigtes System wird zu einem Single Point of Failure, den sich niemand mehr anzufassen traut.

Auch die Infrastrukturen in Großbritannien bleiben gemischt. Eine Überprüfung der britischen Regierung aus dem Jahr 2025 ergab, dass ungefähr 55 % der zentralstaatlichen Organisationen angaben, mehr als 60 % ihrer Technologieinfrastruktur in der Cloud zu haben, während etwa 28 % der Technologieinfrastrukturen der Zentralregierung veraltet blieben, so der State of Digital Government Review. Genau diese Mischung ist der Grund, warum Sie nach wie vor Cloud Identitäten mit Gebäuden und WLAN Netzwerken vor Ort verbinden müssen.

Kosten und Wartung im direkten Vergleich

Kriterium	Cloud RADIUS	On-Premises RADIUS
Investitionskosten	Gering, abonnementbasiert	Höhere Vorabkosten für Hardware und Lizenzen
Wartung	Anbieter patcht und betreibt den Dienst	Ihr Team patcht Betriebssystem, RADIUS und Zertifikate
Skalierbarkeit	Standorte einfach per Konfiguration hinzufügen	Zusätzliche Server, Clustering und Load Balancing erforderlich
Kontrolle	Richtlinienkontrolle, weniger Infrastrukturkontrolle	Volle Kontrolle, volle Verantwortung
Ausfallsicherheit	Redundante Endpunkte durch den Anbieter	Failover muss selbst entwickelt und getestet werden

FreeRADIUS wirkt so lange kostenlos, bis Sie die Arbeitszeit der Techniker, Zertifikatserneuerungen, Überwachung und Fehlerbehebung außerhalb der Arbeitszeiten einrechnen. Microsoft NPS wirkt so lange enthalten, bis Sie eine native Integration mit einem Cloud-Verzeichnis benötigen, für das es nicht entwickelt wurde. Cisco ISE bietet umfassende Richtlinienfunktionen, erfordert jedoch Lizenzen und Fachkenntnisse, die viele Teams allein für WiFi nicht rechtfertigen können.

Das Missverständnis bezüglich der Sicherheit

Der Serverstandort macht die Authentifizierung nicht automatisch sicher. Konfiguration, Identitätsintegration, verschlüsselte Übertragung und Überwachung tun es.

Die Cloud verlagert Risiken, anstatt sie zu beseitigen. Sie profitieren von konsistentem Patching und standortübergreifenden Richtlinien, sind jedoch von der Internetverbindung, der Steuerungsebene des Anbieters und dem Identitätsanbieter abhängig. On-Premises hält den Datenverkehr lokal, aber ein einzelner ungepatchter Server mit überall gemeinsam genutzten Secrets ist nicht sicherer, nur weil er in Ihrem Gebäude steht.

Wählen Sie die Cloud, wenn Ihnen das Personal fehlt, um ein hochverfügbares Paar ordnungsgemäß zu betreiben, Sie viele Standorte verwalten oder die Identitätsverwaltung bereits in die Cloud verlagert haben. Bleiben Sie On-Premises, wenn Vorschriften, Latenzzeiten oder ein getrennter Standort tatsächlich lokale Entscheidungen erfordern. Viele HR- und IT-Migrationen folgen derselben hybriden Logik, weshalb dieser Leitfaden für Microsoft 365 HR-Teams eine nützliche parallele Lektüre ist, wie man Kernsysteme verlagert, ohne so zu tun, als würde Legacy-Software über Nacht verschwinden.

Integration mit Microsoft Entra ID, Okta und Zertifikaten

Ein Cloud-RADIUS-Server beweist seinen Wert an den Schnittstellen. Wenn er nicht sauber mit Ihrem Verzeichnisdienst, Ihrer Zertifizierungsstelle und Ihren Gäste-Flows kommunizieren kann, haben Sie einen gehosteten Engpass gekauft. Wenn die Integrationsmuster stimmen, folgt der Netzwerkzugriff derselben Logik für Neueinstellungen, Rollenwechsel und Austritte wie die restliche IT.

RADIUS selbst beherrscht keine moderne Web-Föderation. Wenn Ihr Team klären möchte, wo die Netzwerkauthentifizierung endet und das Single Sign-On für Anwendungen beginnt, hilft diese Übersicht zu SAML- und OIDC-Authentifizierung bei der Trennung dieser Ebenen. RADIUS regelt den Netzwerkzugang, während SAML und OIDC in der Regel die Anwendungsanmeldung übernehmen, nachdem ein Benutzer bereits verbunden ist.

Verzeichnisgestützte Authentifizierung für Mitarbeiter

Mit Microsoft Entra ID oder Okta prüft der RADIUS-Dienst den Benutzer oder das Gerät anhand von Gruppen und Attributen im Verzeichnis. Ein Finanzbenutzer kann eine andere Rolle erhalten als ein externer Gebäudetechniker, selbst bei derselben SSID. Wenn die Personalabteilung ein Konto deaktiviert, sollte sich diese Änderung ohne ein separates Ticket an das Netzwerkteam auf den Netzwerkzugriff auswirken.

Validieren Sie speziell für Microsoft Entra ID, wie Gruppen, Geräteobjekte und bedingte Signale in RADIUS-Richtlinien einfließen, bevor Sie einen flächendeckenden Rollout durchführen, wie in diesem Entra ID RADIUS-as-a-Service Integrationsleitfaden beschrieben. Testen Sie während des Pilots einen ausscheidenden Mitarbeiter, eine Rollenänderung und ein deaktiviertes Gerät. Diese drei Fälle sind aufschlussreicher als hundert erfolgreiche Anmeldungen.

Zertifikate für von Ihnen verwaltete Geräte

EAP-TLS verwendet Zertifikate auf beiden Seiten, sodass es kein Passwort gibt, das durch Phishing, Weitergabe oder Brute-Force-Angriffe kompromittiert werden kann. Es ist das stärkste Muster für verwaltete Laptops, vorausgesetzt, Sie können Zertifikate über MDM oder SCEP ohne manuellen Aufwand ausstellen, erneuern und widerrufen. Wenn die Zertifikatsbereitstellung fehlerhaft ist, werden die Benutzer Sie wieder zu Passwörtern drängen - und sich durchsetzen.

1. Identität ausstellen: Übertragen Sie ein Benutzer- oder Gerätezertifikat über Intune, Jamf oder Ihr MDM mit einem eindeutigen Eigentümer und Ablaufdatum.
2. Vertrauen validieren: Konfigurieren Sie den RADIUS-Dienst so, dass er Ihrer ausstellenden CA vertraut und den Sperrstatus überprüft.
3. An Richtlinie binden: Ordnen Sie Zertifikatsfelder und Verzeichnisgruppen VLANs oder Rollen am Access Point zu.
4. Schnell widerrufen: Entfernen Sie das Zertifikat und den Verzeichniszugriff gemeinsam, wenn ein Gerät verloren geht oder eine Person das Unternehmen verlässt.

Gäste und Geräte, die kein 802.1X unterstützen

Gäste sollten kein Unternehmenskonto benötigen, um sicheren Zugang zu erhalten. Mit Passpoint und OpenRoaming kann sich ein Gerät einmal authentifizieren und bei späteren Besuchen wieder mit verschlüsseltem Zugang verbinden, was sich ideal für Hotels, Verkehrsknotenpunkte und Multi-Site-Standorte eignet. Für Drucker, Zahlungsterminals und ältere IoT-Geräte, die keine Zertifikate vorweisen können, nutzen Sie MAC Authentication Bypass oder individuelle Pre-Shared Keys mit strikter Segmentierung und behandeln Sie diese Geräte standardmäßig als nicht vertrauenswürdig.

Sicherheits- und Zero-Trust-Überlegungen

Betrachten Sie einen Cloud-RADIUS-Server als Sicherheitsgrenze und nicht als bloßes Hilfsmittel. Er entscheidet, wer Zugang zu Ihrem Netzwerk erhält, kommuniziert mit Ihrem Verzeichnisdienst und seine Verwaltungskonsole kann die Richtlinien für alle Standorte gleichzeitig ändern. Diese Machtkonzentration ist nützlich - und genau deshalb müssen die Kontrollmechanismen dahinter sorgfältig geprüft werden.

Das NCSC empfiehlt, dass Cloud-Dienst-Schnittstellen den Zugriff nur für authentifizierte und autorisierte Identitäten freigeben, mit kontextbezogener Authentifizierung unter Verwendung kryptografischer Bestätigungen oder sicherem Schlüsselaustausch, wie im NCSC-Grundsatz 10 zu Identität und Authentifizierung beschrieben. Für Cloud RADIUS bedeutet dies, den Dienst und seine Verwaltungsschnittstellen als getrennte Vertrauensgrenzen zu behandeln - mit eindeutigen Dienstidentitäten, genau definierten Berechtigungen und überprüfbaren Authentifizierungsereignissen anstelle von geteilten Administrator-Anmeldedaten.

Vertrauen Sie nicht mehr allein auf den Netzwerkstandort

Zero Trust ändert die Frage von "Befindet sich dieses Gerät in unserem VLAN?" zu "Wer ist dieser Benutzer, was ist das für ein Gerät und worauf sollte es genau jetzt zugreifen können?". Das bloße Vorhandensein in einem Unternehmens- oder Gäste-VLAN ist kein Berechtigungsnachweis. Der Zugriff muss an die authentifizierte Identität und die Richtlinie für die jeweilige Sitzung, den Mandanten und den Standort gekoppelt bleiben.

Dieses Prinzip hat praktische Konsequenzen für das WiFi-Design. Der Laptop eines externen Dienstleisters und der Laptop der Finanzabteilung können zwar dieselbe SSID nutzen, sollten aber nicht untereinander erreichbar sein. Ihre umfassenderen Sicherheitskontrollen sollten an einem Enterprise WiFi Security Guide für Zero Trust Network Access ausgerichtet sein, damit Authentifizierungsentscheidungen mit Segmentierung, Überwachung und dem Prinzip der geringsten Rechte verknüpft sind - und nicht nur mit dem Herstellen einer Verbindung.

Kriterien, die Sie von einem Anbieter verlangen sollten

• Verschlüsselter Transport: RadSec oder gleichwertiger Schutz für RADIUS Verkehr sowie modernes TLS für APIs und Administratorzugriff.
• Erneuerung und Widerruf: Dokumentierte Zertifikats- und Secret-Erneuerung sowie schneller Widerruf, wenn Konten oder Geräte deaktiviert werden.
• Rollenbasierte Verwaltung: Getrennte Lese-, Bediener- und Administratorrollen ohne gemeinsam genutzte Logins für Richtlinienänderungen.
• Nutzbare Protokollierung: Authentifizierungsereignisse, Richtlinienänderungen und Administratoraktionen, die mit klarer Aufbewahrungsfrist in Ihr SIEM exportiert werden.

Praktische Regel: Wenn die Kompromittierung eines einzelnen Standorts oder Integrationskontos einem Angreifer die Kontrolle über andere Mandanten oder die Steuerungsebene verschafft, ist das Design fehlgeschlagen.

Stellen Sie frühzeitig unangenehme Fragen. Wer kann Authentifizierungsprotokolle einsehen, wo werden sie gespeichert und wie ist der administrative Zugriff des Anbieters von Ihrer Datenebene getrennt. Wenn ein Anbieter keine klare Antwort geben kann, ist das bereits eine Aussage.

Bereitstellungsmodelle für Enterprise- und Multi-Tenant-WiFi

Ein Hotel beim Check-in, eine Station mit medizinischen Geräten und ein Einkaufszentrum an einem Samstag teilen sich nicht dasselbe Risikoprofil. Sie können sich jedoch einen Cloud-RADIUS-Server teilen - vorausgesetzt, jede Benutzergruppe erhält ihre eigene Richtlinie und das Netzwerk erzwingt die Trennung nach der Authentifizierung. Der Fehler besteht darin, anzunehmen, dass eine erfolgreiche Anmeldung automatisch ein segmentiertes Netzwerk bedeutet.

Umfragedaten der Regierung zeigen im Cyber Security Breaches Survey 2025 Kapitel über Netzwerksicherheitskontrollen, dass 85 % der großen britischen Unternehmen getrennte WLAN Netzwerke für Mitarbeiter und Besucher unterhielten, verglichen mit 93 % zuvor. Die Trennung ist selbst für große Unternehmen kein gelöstes Problem. Cloud RADIUS muss daher mit dynamischen VLANs oder Richtliniendurchsetzung kombiniert werden, um eine echte Segmentierung zu bieten und nicht nur eine schönere Authentifizierung.

Was verschiedene Standorte tatsächlich benötigen

Im Gastgewerbe authentifizieren sich Gäste bei der Ankunft, Mitarbeitergeräte werden mit dem Verzeichnis abgeglichen und Zahlungsterminals befinden sich in einem eingeschränkten Segment, das für beide nicht sichtbar ist. Im Gesundheitswesen koexistieren medizinisches Personal, Transportdienste, Patienten und medizinische Geräte - und einige dieser Geräte werden niemals Zertifikate unterstützen. Richtlinien müssen diese Realität widerspiegeln, anstatt jedes Gerät in ein einziges Modell zu zwängen.

Filialketten stehen eher vor einer Herausforderung der Skalierung als der Komplexität an den einzelnen Standorten. Die Zentrale wünscht sich einen einheitlichen Mitarbeiterzugang und die Trennung von Gästen in allen Filialen, ohne Server an jeden Standort liefern zu müssen. Verkehrsknotenpunkte erweitern dies um Roaming, da Pendler erwarten, dass die an einer Station registrierte Verbindung auch an der nächsten funktioniert. Ein zentraler Dienst eignet sich für beide Szenarien, da die Richtlinie mit der Identität mitreist.

Mandantenfähige Gebäude benötigen eine isolierte Architektur

Bewohner im Bereich Build-to-Rent oder in Studentenwohnheimen erwarten ein WiFi wie zu Hause, aber die Geräte jedes Haushalts müssen für Nachbarn unsichtbar bleiben. Das erfordert Richtlinien pro Mieter, individuelle Schlüssel für ältere Geräte und einen Mitarbeiterzugriff, der nicht in die Netzwerke der Bewohner übergeht. Ein Multi-Tenant WiFi-Leitfaden für isolierte Bewohnernetzwerke sollte zusammen mit Ihrem RADIUS-Design überprüft werden, da eine Authentifizierung nur hilft, wenn die zugrundeliegende Mandantentrennung solide ist.

Erfassen Sie vor dem Rollout jede Geräteklasse, die Sie besitzen - nicht nur die geordnete Liste im Anlagenregister. Mitarbeiter, Gäste, Auftragnehmer, IoT, Kassen, Scanner und der alte Drucker in der Finanzabteilung benötigen alle einen definierten Pfad. Geräte, die Sie nicht einplanen, werden zur Ausnahme, die die Richtlinie untergräbt.

Bewährte Verfahren für Implementierung und Betrieb

Die meisten Cloud-RADIUS-Probleme sind keine Protokollprobleme. Es sind betriebliche Überraschungen, die niemand getestet hat - wie ein deaktiviertes Konto, das weiterhin funktioniert, ein Standort, der den Internetzugang verliert, oder eine Notfallanmeldung, die keine Überwachungsprotokolle hinterlässt. Planen Sie diese Fälle ein, bevor der erste Standort live geht, und nicht erst während des ersten Ausfalls.

Die Umfrage der britischen Regierung zu Cybersicherheitsverletzungen 2025 ergab, dass 43 % der Unternehmen in den vorangegangenen 12 Monaten einen Verstoß oder Angriff meldeten, jedoch nur 31 % formelle Cyber-Risikobewertungen durchführten, wie in den Ergebnissen der Cyber Security Breaches Survey 2025 bis 2026 berichtet. Diese Lücke ist der Grund, warum Sie eindeutige Antworten für Anbieterausfälle, Ausfallzeiten des Identity Providers und den Verlust der Konnektivität sowie einen geprüften Notfallzugriff benötigen.

Ausfallverhalten pro SSID definieren

Legen Sie schriftlich fest, wo die Authentifizierung fail-closed reagiert und wo ein eng gefasster Fallback akzeptabel ist. Privilegierte Mitarbeiter-SSIDs und sensible Segmente sollten fail-closed reagieren, da ein offener Zugang während eines Ausfalls den Zweck von 802.1X zunichtemacht. Betriebskritische Dienste können einen eng gefassten, zeitlich begrenzten Fallback rechtfertigen, dieser sollte jedoch alarmiert, protokolliert und überprüft werden.

1. Pilotieren Sie einen Standort und eine SSID: Überprüfen Sie Authentifizierung, VLAN-Zuweisung und Protokollierung mit realen Geräten, einschließlich Ihrer ältesten unterstützten Hardware.
2. Provozieren Sie gezielt Fehler: Deaktivieren Sie ein Testkonto, widerrufen Sie ein Zertifikat und simulieren Sie den Ausfall des primären Endpunkts - messen Sie anschließend die Auswirkungen auf die Benutzer.
3. Messen Sie die Widerrufsgeschwindigkeit: Stoppen Sie die Zeit, wie lange ein deaktiviertes Microsoft Entra ID- oder Okta-Konto noch Netzwerkzugriff behält, und halten Sie das Ergebnis im Runbook fest.
4. Testen Sie den Ausstiegspfad: Bestätigen Sie, dass Sie Konfigurationen und Protokolle exportieren und Access Points auf einen anderen Dienst umleiten können, ohne Richtlinien aus dem Gedächtnis neu aufbauen zu müssen.

Betreiben Sie es wie eine kritische Infrastruktur

Überwachen Sie die Erfolgs- und Fehlerraten der Authentifizierung, den Status der Endgeräte sowie ungewöhnliche Spitzen nach Standorten. Überprüfen Sie Protokolle auf wiederholte Fehler von einem einzelnen Gerät, da es sich dabei oft um eine Fehlkonfiguration, ein abgelaufenes Zertifikat oder einen Auskundschaftungsversuch in Ihrem Netzwerk handelt. Vereinbaren Sie Protokollspeicherung, UK GDPR-Datenschutzanforderungen und Support-Reaktionszeiten im Vertrag - nicht in einem Vertriebsgespräch.

Messen Sie den Erfolg nicht daran, ob 802.1X aktiviert ist. Messen Sie, ob die Isolierung funktioniert, der Widerruf schnell erfolgt und ein Standort bei Verbindungsausfall kontrolliert weiterläuft.

Überprüfen Sie das Lieferantenrisiko jährlich, einschließlich Unterauftragnehmern und der Herkunft des Support-Zugriffs. Führen Sie ein kurzes Runbook, dem ein Diensthabender Ingenieur nachts ohne das Projektteam folgen kann. Wenn dieses Runbook nicht existiert, verfügen Sie noch über kein Betriebsmodell.

Wichtige Erkenntnisse und nächste Schritte

Ein Cloud RADIUS Server ist sinnvoll, wenn sich die Identitätsverwaltung bereits in der Cloud befindet, Sie mehrere Standorte betreiben oder Ihr Team ein hochverfügbares On-Premises-Paar nicht nach hohen Standards betreiben kann. Er eliminiert die Serverwartung und zentralisiert die Richtlinien. Er entbindet Sie jedoch nicht von der Verantwortung für Segmentierung, Widerruf, Protokollierung oder Ausfallplanung.

Es ist für sich genommen auch keine Segmentierung. Die Authentifizierung entscheidet, wer ein Gerät zu sein vorgibt. Dynamische VLANs, rollenbasierte Richtlinien und Regeln der minimalen Rechtevergabe entscheiden, was dieses Gerät erreichen kann - und Sie benötigen beides im Zusammenspiel.

Eine kurze Evaluierungs-Checkliste

• Identitätsintegration: Native Anbindung an Ihr Verzeichnis sowie getestetes Verhalten für Eintritt, Rollenwechsel und Austritt von Mitarbeitern.
• Zertifikatsverwaltung: Verwaltete Ausstellung, Erneuerung und Sperrung, die von Ihrer Gerätelandschaft unterstützt werden.
• Fehlerverhalten: Sichere Sperrung ("Fail closed") für sensible SSIDs, mit minimalen, protokollierten und zeitlich begrenzten Fallback-Optionen.
• Nachweisbarkeit: Exportierbare Protokolle, klare Datenspeicherung, rollenbasierte Administration und Mandantentrennung.
• Ausstieg: Konfigurations- und Protokollexport, damit der Anbieterwechsel zu einem steuerbaren Projekt wird statt zu einem kompletten Neuaufbau.

Starten Sie mit einem Pilotprojekt an einem Standort oder einer SSID, messen Sie den Authentifizierungserfolg sowie die Widerrufs-Latenz und testen Sie gezielt den Ausfall der Integration, bevor Benutzer darauf angewiesen sind. Skalieren Sie erst, wenn diese Ergebnisse unspektakulär sind. Unspektakulär ist genau das, wie eine gute Authentifizierung im Betrieb aussehen sollte.

---

Purple bietet RADIUS-as-a-Service für Gäste, Mitarbeiter und Multi-Tenant WiFi und lässt sich in Entra ID, Google Workspace und Okta integrieren, sodass Sie On-Premises RADIUS-Server außer Betrieb nehmen und konsistenten, identitätsbasierten Zugriff an jedem Standort anwenden können. Wenn Sie einen Testbetrieb planen oder ein anfälliges NPS- oder FreeRADIUS-Setup ersetzen möchten, besuchen Sie Purple, um zu erfahren, wie verwaltetes Cloud-RADIUS, Passpoint und die Isolierung pro Mandant mit Ihrer bestehenden Meraki-, Aruba-, Ruckus-, Mist- oder UniFi-Infrastruktur funktionieren.