Implementierung der 802.1X-Authentifizierung mit Cloud RADIUS

How to Implement 802.1X Authentication with Cloud RADIUS A Purple WiFi Intelligence Briefing --- INTRODUCTION AND CONTEXT (approx. 1 minute) --- Welcome to the Purple WiFi Intelligence Briefing. I'm your host, and today we're getting into the detail on 802.1X authentication with Cloud RADIUS — what it is, why it matters right now, and how to actually deploy it across a multi-site estate. If you're managing WiFi infrastructure for a hotel group, a retail chain, a stadium, or a public-sector organisation, this is one of those topics that keeps coming up — and for good reason. The threat landscape has shifted. Shared PSK networks are increasingly seen as a compliance liability, not just a security inconvenience. Regulators, auditors, and cyber insurers are all asking harder questions about network access control. And the good news is that cloud-delivered RADIUS has made 802.1X genuinely deployable at scale, without the on-premises infrastructure overhead that used to make it impractical for distributed estates. So let's get into it. --- TECHNICAL DEEP-DIVE (approx. 5 minutes) --- First, let's make sure we're all working from the same definition. IEEE 802.1X is a port-based network access control standard. It defines an authentication framework that sits at Layer 2 of the OSI model — so it operates before a device is granted any IP connectivity whatsoever. That's the key distinction from application-layer authentication. With 802.1X, a device cannot get onto the network until it has been positively authenticated. The protocol has three components. The supplicant — that's the end device, whether it's a laptop, a smartphone, or a point-of-sale terminal. The authenticator — typically your WiFi access point or your managed switch. And the authentication server — which in modern deployments is your cloud RADIUS service. The flow works like this. A device attempts to associate with an access point. The access point doesn't grant full network access immediately. Instead, it opens a controlled port and initiates an EAP exchange — that's the Extensible Authentication Protocol — with the device. The device presents its credentials, which could be a username and password, a digital certificate, or a SIM-based identity. The access point relays that exchange to the RADIUS server using the RADIUS protocol over UDP, typically on port 1812 for authentication and 1813 for accounting. The RADIUS server validates the credentials against an identity store — Active Directory, Azure AD, or an LDAP directory — and returns either an Access-Accept or an Access-Reject message. If accepted, the access point opens the port and the device gets network access. If rejected, it stays blocked. Simple in principle, but the implementation details matter enormously. Now, EAP method selection is where a lot of deployments go wrong. There are several EAP methods in common use, and they have very different security profiles and operational requirements. EAP-TLS is the gold standard. It requires mutual certificate authentication — both the server and the client present a certificate. This eliminates credential theft risk entirely, because there are no passwords to steal. But it requires a PKI infrastructure and a mechanism to push client certificates to devices, which typically means an MDM solution. For corporate BYOD environments and high-security deployments, this is the right answer. PEAP with MSCHAPv2 is the most widely deployed method in enterprise environments. It only requires a server-side certificate, and it tunnels the credential exchange inside TLS. It's compatible with Active Directory natively, which makes it operationally straightforward. The risk is that it's vulnerable to credential harvesting if users connect to a rogue access point with a self-signed certificate — so certificate validation on the client side is non-negotiable. EAP-TTLS is similar to PEAP but more flexible in the inner authentication method. It's particularly useful in mixed-device environments where you have a combination of Windows, macOS, iOS, and Android devices with varying supplicant capabilities. For legacy device support — think older point-of-sale hardware or IoT sensors — EAP-FAST can be a pragmatic choice, as it doesn't require certificates and uses a Protected Access Credential instead. Now, the cloud RADIUS piece. Traditionally, RADIUS was an on-premises service — FreeRADIUS on a Linux server, or Microsoft NPS on Windows Server. That model works, but it has real operational costs: hardware maintenance, high availability configuration, patching, and the need for local infrastructure at every site that needs low-latency authentication. Cloud RADIUS changes that calculus significantly. A cloud RADIUS service is hosted and managed by the provider. Your access points send RADIUS requests over the internet to the cloud service, which handles authentication against your identity provider. The latency concern is real but manageable — modern cloud RADIUS services are globally distributed, and authentication round-trips typically complete in under 100 milliseconds, which is imperceptible to end users. The integration with identity providers is the critical dependency. Most cloud RADIUS platforms support LDAP, LDAPS, SAML 2.0, and direct Azure AD or Okta integration. For organisations already running Microsoft 365, Azure AD integration is the natural path — you get single sign-on, conditional access policies, and MFA enforcement all feeding into your network access control layer. For venues deploying guest WiFi alongside staff networks, the architecture typically separates these into distinct SSIDs with different authentication policies. Staff networks use 802.1X with corporate credentials. Guest networks use a captive portal or social login flow. Purple's platform supports both models, and the WiFi analytics layer sits across both, giving you visibility into device behaviour, dwell time, and network utilisation without compromising the security segmentation. --- IMPLEMENTATION RECOMMENDATIONS AND PITFALLS (approx. 2 minutes) --- Let me give you the practical deployment sequence, and flag the failure modes I see most often. Start with your identity provider integration. Before you touch a single access point, confirm that your cloud RADIUS service can authenticate against your directory. Test with a service account, validate the LDAP bind, and confirm that group membership attributes are being returned correctly — because you'll need those for VLAN assignment policies. Second, plan your certificate strategy. If you're going with EAP-TLS, you need a CA, you need to decide whether you're using a public CA or an internal one, and you need an MDM rollout plan for client certificates. If you're going with PEAP, you need a server certificate from a trusted CA — not self-signed — and you need to push the CA certificate to all client devices so that certificate validation works correctly. This is the step that gets skipped and causes security incidents. Third, configure your RADIUS clients — that's your access points and controllers — with the correct shared secret and server IP or hostname. Use a strong, randomly generated shared secret, not a dictionary word. And if your cloud RADIUS provider supports RADIUS over TLS — RadSec — use it. It encrypts the RADIUS traffic in transit, which is particularly important when that traffic is traversing the public internet. Fourth, test with a pilot group before full rollout. Authentication failures at scale are disruptive and hard to diagnose under pressure. Run a pilot with ten to twenty devices, validate the authentication logs, confirm VLAN assignment is working, and check that accounting records are being written correctly. The failure modes I see most often: certificate validation disabled on clients, leading to man-in-the-middle vulnerability. Shared secrets that are too short or reused across sites. RADIUS server IP allowlisting not configured, so authentication requests from new sites get dropped silently. And MDM profiles not being updated when certificates expire, causing mass authentication failures on renewal day. --- RAPID-FIRE Q&A (approx. 1 minute) --- A few questions I get asked regularly. Can I run 802.1X on a network that also has IoT devices that don't support EAP? Yes — use MAC Authentication Bypass as a fallback for devices that can't run a supplicant, but put those devices on a restricted VLAN with tight firewall rules. Does 802.1X replace WPA2 or WPA3 encryption? No — 802.1X handles authentication. WPA2-Enterprise or WPA3-Enterprise handles the encryption. You need both. WPA3-Enterprise with 802.1X is the current best practice for new deployments. What's the latency impact on authentication? With a well-configured cloud RADIUS service, expect 50 to 150 milliseconds per authentication. For roaming scenarios, 802.11r fast BSS transition can reduce re-authentication overhead significantly. Is this PCI DSS compliant? 802.1X with EAP-TLS or PEAP on a properly segmented network satisfies PCI DSS Requirement 1 and Requirement 8 for network access control. Get your QSA involved early. --- SUMMARY AND NEXT STEPS (approx. 1 minute) --- To pull this together: 802.1X with cloud RADIUS is the right answer for any organisation that needs to demonstrate network access control to auditors, reduce the blast radius of a credential compromise, or manage authentication centrally across a distributed estate. The deployment is not trivial, but it is absolutely manageable with the right preparation. Get your identity provider integration right first. Choose your EAP method based on your device estate and your operational capability to manage certificates. Use RadSec if your infrastructure supports it. And test before you roll out at scale. If you're running a mixed guest and staff network — which most hospitality and retail operators are — platforms like Purple give you the ability to manage both authentication models from a single pane of glass, with the analytics layer sitting across the whole estate. For your next steps: audit your current network access control posture, identify which sites are still running shared PSK, and build a phased migration plan. Start with your highest-risk sites — those in scope for PCI DSS or those handling sensitive data — and work outward. Thanks for listening. More technical briefings are available at purple.ai.