Zum Hauptinhalt springen

The Security Benefits of RADIUS as a Service for Hybrid Workforces

Dieser technische Leitfaden erklärt, wie RADIUS as a Service den Netzwerkzugriff für hybride Belegschaften an verteilten Standorten sichert. Er behandelt die Architektur, die Sicherheitsvorteile und die Bereitstellungsschritte für den Ersatz von On-Premise-RADIUS-Infrastrukturen durch einen cloudbasierten Authentifizierungsdienst. Für IT-Manager und Netzwerkarchitekten in Hotels, Einzelhandelsketten, Stadien und Organisationen des öffentlichen Sektors liefert dieser Leitfaden die notwendigen Argumente, um eine Migration zu Cloud-RADIUS in diesem Quartal zu bewerten und umzusetzen.

📖 9 Min. Lesezeit📝 2,171 Wörter🔧 2 ausgearbeitete Beispiele3 Übungsfragen📚 9 Schlüsseldefinitionen

Diesen Leitfaden anhören

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

header_image.png

Executive Summary

Der Übergang zu hybriden Belegschaften hat eine grundlegende Schwäche der traditionellen Netzwerksicherheit offengelegt: On-Premise-RADIUS-Server wurden für eine Welt entwickelt, in der Mitarbeiter in einem einzigen Gebäude saßen und sich mit einem einzigen Netzwerk verbanden. Diese Welt existiert nicht mehr. Heute authentifizieren sich Ihre Mitarbeiter aus Hotelzimmern, Verkaufsräumen, Homeoffices und Veranstaltungsorten. Ihre Identity Provider befinden sich in der Cloud. Ihre Access Points erstrecken sich über Hunderte von Standorten. Dennoch verlassen sich viele Unternehmen immer noch auf physische RADIUS-Server, die manuell gepatcht werden müssen, sich nicht nativ in Microsoft Entra ID oder Google Workspace integrieren lassen und bei Hardwarefehlern unbemerkt ausfallen.

RADIUS as a Service ersetzt diese Infrastruktur durch eine cloudnative Authentifizierungs-Engine. Sie verweisen mit Ihren Access Points auf Cloud-Endpunkte. Der Anbieter verwaltet die Server, das Patching und die Hochverfügbarkeit. Sie verwalten die Richtlinien. Für IT-Teams in Hotellerie -Gruppen, Einzelhandels -Ketten und öffentlichen Veranstaltungsorten eliminiert dieser Wechsel den Hardware-Overhead, setzt eine identitätsbasierte Netzwerksegmentierung durch und liefert den von PCI DSS und GDPR geforderten Audit-Trail.


Technische Vertiefung

Warum On-Premise-RADIUS an seine Grenzen stößt

RADIUS, definiert in RFC 2865, bietet eine zentrale Authentifizierung, Autorisierung und Protokollierung (Authentication, Authorisation, and Accounting – AAA) für den Netzwerkzugriff. Jedes Unternehmen, das WPA2-Enterprise oder WPA3-Enterprise WiFi nutzt, ist darauf angewiesen. Das Protokoll selbst ist solide. Das Problem ist das Infrastrukturmodell, das sich darum herum entwickelt hat.

FreeRADIUS auf Linux erfordert erhebliches Fachwissen für die Bereitstellung, Härtung und Wartung. Der Microsoft Network Policy Server (NPS) ist eng an das Active Directory gekoppelt und bietet keine native Unterstützung für Microsoft Entra ID, Okta oder Google Workspace. Die Cisco Identity Services Engine (ISE) bietet Richtlinienfunktionen der Enterprise-Klasse, erfordert jedoch dedizierte Hardware, eine komplexe Lizenzierung und ein Spezialistenteam für den Betrieb. Alle drei erfordern, dass Sie die Hochverfügbarkeit manuell aufbauen und verwalten, in der Regel durch den Betrieb von zwei Servern mit Datenbankreplikation und einem vorgeschalteten Load Balancer.

Für ein Unternehmen mit nur einem Standort und einem stabilen Active Directory ist dieses Modell handhabbar. Für eine Hotelgruppe mit 50 Häusern, eine Einzelhandelskette mit 400 Filialen oder eine Universität mit einem verteilten Campus ist es jedoch nicht mehr praktikabel. Entweder zentralisieren Sie die RADIUS-Server und akzeptieren Authentifizierungslatenzen an entfernten Standorten, oder Sie stellen an jedem Standort Server bereit und verwalten diese einzeln. Beide Optionen sind nicht skalierbar.

Die Architektur von RADIUS as a Service

RADIUS as a Service ist ein cloudbasiertes Bereitstellungsmodell für das RADIUS-Protokoll. Das Protokoll selbst bleibt unverändert und folgt RFC 2865 und dessen Erweiterungen. Was sich ändert, ist, wer die Infrastruktur wartet.

Wenn sich ein Gerät mit Ihrem WiFi-Netzwerk verbindet, leitet der Access Point (der RADIUS-Client) die Authentifizierungsanfrage über einen sicheren, verschlüsselten Tunnel an die Cloud-RADIUS-Endpunkte weiter. Der Cloud-Dienst validiert die Anmeldedaten mit Ihrem Identity Provider und gibt eine Access-Accept- oder Access-Reject-Nachricht sowie Richtlinienattribute wie dynamische VLAN-Zuweisungen zurück. Aus Sicht des Access Points ist der Authentifizierungsablauf identisch mit dem von On-Premise-RADIUS.

architecture_overview.png

Der Cloud-Anbieter betreibt die RADIUS-Server in mehreren geografisch verteilten Rechenzentren. Das Failover erfolgt automatisch. Wenn ein Endpunkt nicht mehr verfügbar ist, wird der Datenverkehr ohne Eingreifen Ihres Teams an den nächsten funktionierenden Endpunkt weitergeleitet. Bei Unternehmen mit Standorten in mehreren Regionen erfolgt die Authentifizierung am nächstgelegenen Cloud-Endpunkt, wodurch die Latenz unabhängig von der Geografie niedrig bleibt.

IEEE 802.1X und EAP-Methoden

IEEE 802.1X is der Standard für die portbasierte Netzwerksicherheitskontrolle (Network Access Control – NAC). Es zwingt ein Gerät zur Authentifizierung, bevor ihm eine IP-Adresse zugewiesen und der Datenverkehr zugelassen wird. RADIUS ist der Authentifizierungsserver in einer 802.1X-Bereitstellung.

Das Extensible Authentication Protocol (EAP) definiert, wie Anmeldedaten ausgetauscht werden. Cloud-RADIUS unterstützt die gesamte Palette der EAP-Methoden:

EAP-Methode Authentifizierungstyp Sicherheitsstufe Empfohlene Nutzung
EAP-TLS Gegenseitig zertifikatsbasiert Höchste Unternehmensgeräte mit MDM-verwalteten Zertifikaten
PEAP-MSCHAPv2 Benutzername und Passwort Mittel Ältere Geräte oder BYOD ohne MDM
EAP-TTLS Getunnelte Anmeldedaten Mittel Gemischte Umgebungen
MAC Authentication Bypass Geräte-MAC-Adresse Niedrig IoT-Geräte, die 802.1X nicht unterstützen

EAP-TLS, definiert in RFC 5216, ist der Goldstandard. Sowohl das Client-Gerät als auch der RADIUS-Server weisen sich gegenseitig digitale Zertifikate vor. Diese gegenseitige Authentifizierung eliminiert Passwörter vollständig aus dem Netzwerkzugriffsprozess. Ein Zertifikat ist kryptografisch an das Gerät gebunden und kann nicht wie ein Passwort durch Phishing erlangt, erraten oder gestohlen werden. Für Unternehmen, die von Sicherheitsverletzungen durch gestohlene Anmeldedaten betroffen waren, ist dies die direkteste verfügbare technische Gegenmaßnahme.

Dynamische VLAN-Zuweisung

Über die Authentifizierung hinaus setzt der RADIUS-Server die Autorisierung durch. Wenn er eine Verbindung akzeptiert, gibt er Richtlinienattribute an den Access Point zurück, einschließlich der VLAN-ID, die dem Gerät zugewiesen werden soll. Diese dynamische VLAN-Zuweisung ist der Mechanismus, der identitätsbasierte Netzwerke ermöglicht.

Ein Hotelrezeptionist authentifiziert sich und wird dem Front-of-House-VLAN mit Zugriff auf das Hotelmanagementsystem zugewiesen. Ein Mitarbeiter des Housekeepings wird in ein eingeschränktes VLAN mit reinem Internetzugang eingestuft. Ein Gästegerät wird im Guest WiFi-VLAN platziert, vollständig isoliert von allen Unternehmensressourcen. Ein IoT-Gerät, wie beispielsweise eine Sicherheitskamera, wird in einem dedizierten IoT VLAN. All of this happens automatically, based on the identity verified by the RADIUS server, without any manual VLAN configuration per device.

This is the principle of least privilege applied to network access. You are not trusting a device because it connected to a particular SSID. You are granting access based on verified identity and limiting that access to only what that identity requires. For a deeper look at how this fits into a broader network access control strategy, see our guide on network access control systems .

Native cloud identity integration

The most operationally significant advantage of cloud RADIUS is its native integration with modern identity providers. Cloud RADIUS connects directly to Microsoft Entra ID, Okta, and Google Workspace via standard protocols including OIDC, SAML, and LDAP. When you provision a new employee in your identity provider, they can authenticate to the WiFi network immediately. When you offboard an employee, you disable their account in the directory and their WiFi access is revoked instantly, across every access point at every location.

This real-time synchronisation eliminates one of the most persistent security gaps in enterprise WiFi: the former employee who still has the shared PSK, or whose RADIUS account was not manually deleted when they left. With cloud RADIUS and a cloud identity provider, offboarding is a single action with immediate network-wide effect.


Implementation guide

Step 1: Connect your identity provider

Connect the cloud RADIUS service to your identity provider. For Microsoft Entra ID or Google Workspace, this typically involves authorising an enterprise application via OAuth or configuring an LDAP connector. Map your directory groups to specific network policies. Define your role taxonomy before you start: which groups map to which VLANs, and what access rights each VLAN carries. Getting this right at the beginning saves significant rework later.

Step 2: Deploy certificates for corporate devices

For corporate-owned devices, configure your Mobile Device Management (MDM) platform, such as Microsoft Intune or Jamf, to push client certificates to devices. This enables EAP-TLS authentication. Ensure the Root Certificate Authority (CA) that issued the RADIUS server's certificate is trusted by all client devices. A broken trust chain is the most common cause of silent authentication failures.

Step 3: Configure your network hardware

Add the cloud RADIUS IP addresses and shared secrets to your wireless controllers or access points. Always configure both the primary and secondary endpoints to use the provider's built-in redundancy. Ensure UDP ports 1812 (authentication) and 1813 (accounting) are open outbound from your access points to the cloud RADIUS endpoints. Verify this before go-live. Misconfigured firewall rules are the second most common cause of deployment failures.

Cloud RADIUS works with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet. The configuration steps vary by vendor, but the RADIUS protocol is standardised, so the core parameters (server IP, shared secret, authentication port) are consistent.

Step 4: Define VLAN policies

Configure dynamic VLAN assignment in your RADIUS policy engine. Map each user role or device type to a specific VLAN ID. Test each policy before rolling out to production. A simple test matrix - one device per role, one VLAN per role, verify placement - catches most configuration errors before they affect users.


Best practices

Enforce EAP-TLS for all corporate devices. Move away from PEAP-MSCHAPv2 as quickly as your MDM rollout allows. PEAP relies on passwords, which can be compromised. EAP-TLS relies on certificates, which cannot.

Segment everything. Never place staff, guests, and IoT devices on the same subnet. Use RADIUS to enforce strict VLAN boundaries. This is critical for Retail environments handling payment card data under PCI DSS, and for Healthcare environments protecting patient data.

Align with WPA3-Enterprise. WPA3-Enterprise, the current WiFi security standard, requires 802.1X authentication. Ensure your access points support WPA3-Enterprise and configure it as the minimum security standard for staff networks.

Audit your RADIUS logs regularly. Cloud RADIUS provides centralised audit logs. Review authentication failures weekly. A spike in failures from a specific device or location is an early indicator of a misconfiguration or a potential attack.

Test failover. At least once per quarter, simulate a primary RADIUS endpoint failure and verify that authentication continues via the secondary endpoint. Document the result. This is a straightforward test that most teams never run until they need it.

For venues deploying WiFi across complex environments including maritime or remote locations, see our guide on setting up a captive portal on Starlink for considerations around WAN dependency.


Troubleshooting and risk mitigation

Authentication timeouts

If devices fail to authenticate, check connectivity between your access points and the cloud RADIUS endpoints first. Verify that UDP ports 1812 and 1813 are open outbound. Deep packet inspection on modern firewalls can delay or drop RADIUS packets. If you see timeouts, check your firewall policy for rules that might be inspecting or rate-limiting UDP traffic to the RADIUS endpoints.

Certificate trust chain failures

If using EAP-TLS, ensure client devices trust the Root CA that issued the RADIUS server certificate. If the trust chain is broken, the device will silently reject the connection to prevent a man-in-the-middle attack. This presents as a connection failure with no obvious error message. Check the RADIUS server logs for EAP-TLS-Handshake-Fehler. Stellen Sie das Root-CA-Zertifikat über MDM auf allen verwalteten Geräten bereit.

WAN-Abhängigkeit

Cloud-RADIUS erfordert eine aktive Internetverbindung. Wenn die WAN-Verbindung ausfällt, können Authentifizierungsanfragen den Server nicht erreichen. Evaluieren Sie für geschäftskritische lokale Ressourcen Access Points, die lokale Ausfallsicherheit (Local Survivability) oder Authentifizierungscaching unterstützen. Für die meisten Bereitstellungen ist die WAN-Abhängigkeit akzeptabel, da ein Standort ohne Internet ohnehin nicht auf Cloud-Anwendungen zugreifen kann.

Abweichende Shared Secrets

Jeder Access Point oder Wireless-Controller muss als RADIUS-Client mit dem korrekten Shared Secret konfiguriert sein. Eine Abweichung führt dazu, dass alle Authentifizierungsanfragen von diesem Gerät stillschweigend verworfen werden. Wenn ein bestimmter Access Point ausfällt, während andere erfolgreich sind, überprüfen Sie die Konfiguration des Shared Secrets auf diesem Gerät.


ROI und geschäftliche Auswirkungen

comparison_chart.png

Der Business Case für RADIUS as a Service ruht auf drei Säulen: geringere Investitionsausgaben, reduzierter Betriebsaufwand und ein verbessertes Sicherheitsniveau.

Bei den Investitionsausgaben entfallen die Kosten für Anschaffung, Lizenzierung und Erneuerung physischer Server. Eine minimale On-Premise-RADIUS-Bereitstellung erfordert zwei Server für Hochverfügbarkeit, Betriebssystemlizenzen und eine Hardware-Erneuerung alle drei bis fünf Jahre. Für eine Hotelgruppe mit 50 Standorten bedeutet dies erhebliche Hardware-Investitionen im gesamten Portfolio.

Beim Betriebsaufwand spart Ihr Engineering-Team Zeit, da das Patchen von Windows Servern, die Fehlerbehebung bei FreeRADIUS-Konfigurationen oder die Verwaltung von Zertifikatsverlängerungen auf physischer Infrastruktur entfallen. Diese Zeit kann stattdessen in die Arbeit an Sicherheitsrichtlinien fließen, die Ihr Sicherheitsniveau direkt verbessern.

Beim Sicherheitsniveau reduziert der Wechsel zu EAP-TLS und dynamischer VLAN-Zuweisung die Angriffsfläche erheblich. Der Diebstahl von Anmeldedaten ist die Hauptursache für Netzwerkverletzungen. Die Eliminierung von Passwörtern aus dem Netzwerk-Authentifizierungsprozess adressiert dieses Risiko direkt. Die zentralisierte Audit-Protokollierung unterstützt die Compliance mit PCI DSS v4.0 und GDPR, was die Kosten und die Komplexität von Compliance-Audits reduziert.

Für Organisationen, die Transport-Knotenpunkte oder hochfrequentierte Veranstaltungsorte verwalten, ist die Möglichkeit, konsistente Sicherheitsrichtlinien über alle Standorte hinweg von einem einzigen Dashboard aus durchzusetzen, eine messbare betriebliche Verbesserung. Purple ist in über 80.000 Live-Standorten aktiv und hat im Jahr 2024 440 Millionen Logins verarbeitet (interne Daten von Purple, 2024). Die Infrastruktur, die diese Skalierung unterstützt, ist von Grund auf cloud-native.

Für einen umfassenderen Überblick darüber, wie WiFi-Analysen und Netzwerk-Intelligenz mit Geschäftsergebnissen zusammenhängen, besuchen Sie unsere WiFi-Analyseplattform .


Referenzen

[1] IEEE Standard for Local and metropolitan area networks - Port-Based Network Access Control. IEEE Std 802.1X-2020. [2] IETF. Remote Authentication Dial In User Service (RADIUS). RFC 2865. 1997. [3] IETF. The EAP-TLS Authentication Protocol. RFC 5216. 2008. [4] IronWiFi. Benefits of a Cloud RADIUS Server: Why Enterprises Are Moving Authentication Online. Februar 2026. [5] SecureW2. Cloud vs. On-Site RADIUS: Which is Better? Mai 2026. [6] Portnox. RADIUS as a Service. 2026. [7] PCI Security Standards Council. PCI DSS v4.0. März 2022. [8] Purple. Interne Plattformdaten: 440 Millionen Logins, über 80.000 Standorte. 2024.

Schlüsseldefinitionen

RADIUS

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

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

802.1X

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

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

EAP-TLS

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

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

PEAP

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

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

Dynamic VLAN assignment

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

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

AAA

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

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

WPA3-Enterprise

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

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

Network Access Control (NAC)

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

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

Captive portal

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

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

Ausgearbeitete Beispiele

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

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

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

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

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

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

Übungsfragen

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

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

Musterlösung anzeigen

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

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

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

Musterlösung anzeigen

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

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

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

Musterlösung anzeigen

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

Weiterlesen in dieser Reihe

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

Dieses technische Referenzhandbuch beschreibt detailliert, wie RADIUS as a Service in Cloud-Verzeichnisse – Microsoft Entra ID und Google Workspace – für die WiFi-Authentifizierung in Unternehmen integriert wird. Es behandelt den architektonischen Wandel von On-Premise-NPS zu Cloud-nativem RADIUS, die Bereitstellung der zertifikatsbasierten EAP-TLS-Authentifizierung sowie die bewährten Betriebspraktiken zur Absicherung des drahtlosen Zugangs in den Bereichen Hotellerie, Einzelhandel und im öffentlichen Sektor. Für IT-Manager und Netzwerkarchitekten, die bereits in Cloud-Identitäten investiert haben, schließt dieser Leitfaden die Lücke zwischen Verzeichnisverwaltung und physischer Netzwerksicherheit.

Leitfaden lesen →

How to Implement 802.1X Authentication with Cloud RADIUS

Dieser technische Leitfaden bietet einen umfassenden Rahmen für die Implementierung der 802.1X-Authentifizierung mit Cloud RADIUS in verteilten Unternehmensumgebungen. Er beschreibt die Architektur, die Auswahl der EAP-Methode, die Bereitstellungssequenzierung und die Strategien zur Risikominderung, die erforderlich sind, um den Netzwerkzugriff zu sichern und gleichzeitig den operativen Aufwand der lokalen Infrastruktur zu eliminieren.

Leitfaden lesen →

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

Dieser umfassende Leitfaden beleuchtet Cloud RADIUS (RADIUS as a Service) und beschreibt dessen Architektur, EAP-Methoden und Implementierungsstrategien. Er bietet IT-Führungskräften umsetzbare Einblicke in die Migration von lokalen Servern zu einem skalierbaren, sicheren und konformen Cloud-basierten Authentifizierungsmodell.

Leitfaden lesen →