The Security Benefits of RADIUS as a Service for Hybrid Workforces

Questa guida di riferimento tecnico spiega come RADIUS as a Service protegga l'accesso alla rete per la forza lavoro ibrida in sedi distribuite. Copre l'architettura, i vantaggi in termini di sicurezza e le fasi di implementazione per sostituire l'infrastruttura RADIUS on-premise con un servizio di autenticazione gestito in cloud. Per i responsabili IT e gli architetti di rete di hotel, catene di vendita al dettaglio, stadi e organizzazioni del settore pubblico, questa guida fornisce gli elementi necessari per valutare e avviare la migrazione a un RADIUS in cloud in questo trimestre.

📖 9 minuti di lettura📝 2,171 parole🔧 2 esempi pratici❓ 3 domande di esercitazione📚 9 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast

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.

Punti chiave

✓RADIUS as a Service replaces on-premise servers with a managed cloud platform, eliminating hardware CapEx and maintenance overhead.
✓Cloud RADIUS integrates natively with Microsoft Entra ID, Okta, and Google Workspace, removing the need for complex middleware or parallel Active Directory deployments.
✓Dynamic VLAN assignment ensures users and devices are automatically placed in the correct network segment based on their verified identity, not the SSID they connected to.
✓Transitioning to EAP-TLS (certificate-based authentication) eliminates the risk of password theft and phishing attacks on your network.
✓Centralised cloud management enforces consistent security policies across hundreds of distributed venue locations from a single dashboard.
✓Providers handle security patching and multi-region high availability, ensuring authentication services remain available even during infrastructure updates.
✓Cloud RADIUS supports compliance with PCI DSS v4.0 and GDPR by enforcing strict, identity-based access controls with full centralised audit logging.

Sintesi esecutiva

Il passaggio alla forza lavoro ibrida ha messo in luce una debolezza fondamentale nella sicurezza di rete tradizionale: i server RADIUS on-premise sono stati progettati per un mondo in cui il personale lavorava in un unico edificio e si connetteva a un'unica rete. Quel mondo non esiste più. Oggi, i dipendenti si autenticano da camere d'albergo, punti vendita, uffici remoti e sedi di eventi. I provider di identità risiedono nel cloud. Gli access point coprono centinaia di sedi. Eppure, molte organizzazioni si affidano ancora a server RADIUS fisici che richiedono patch manuali, non possono integrarsi nativamente con Microsoft Entra ID o Google Workspace e smettono di funzionare silenziosamente in caso di guasti hardware.

RADIUS as a Service sostituisce questa infrastruttura con un motore di autenticazione cloud-native. È sufficiente indirizzare gli access point verso gli endpoint cloud. Il provider gestisce i server, le patch e l'alta disponibilità. Voi gestite le policy. Per i team IT dei gruppi del settore Hospitality , delle catene Retail e dei locali pubblici, questo passaggio elimina i costi generali dell'hardware, impone la segmentazione della rete basata sull'identità e fornisce il registro di controllo richiesto da PCI DSS e GDPR.

Approfondimento tecnico

Perché il RADIUS on-premise è in difficoltà

Il protocollo RADIUS, definito nella specifica RFC 2865, fornisce servizi centralizzati di autenticazione, autorizzazione e contabilità (AAA) per l'accesso alla rete. Qualsiasi azienda che utilizzi il WiFi WPA2-Enterprise o WPA3-Enterprise dipende da esso. Il protocollo in sé è solido. Il problema risiede nel modello infrastrutturale che si è sviluppato attorno ad esso.

FreeRADIUS su Linux richiede competenze significative per l'implementazione, il rafforzamento della sicurezza e la manutenzione. Microsoft Network Policy Server (NPS) è strettamente legato ad Active Directory e non offre un supporto nativo per Microsoft Entra ID, Okta o Google Workspace. Cisco Identity Services Engine (ISE) offre funzionalità di policy di livello enterprise, ma richiede hardware dedicato, licenze complesse e un team di specialisti per la gestione. Tutti e tre richiedono la creazione e la manutenzione manuale dell'alta disponibilità, in genere eseguendo due server con replica del database e un bilanciatore di carico a monte.

Per un'organizzazione con un'unica sede e un Active Directory stabile, questo modello è gestibile. Per un gruppo alberghiero con 50 strutture, una catena di negozi con 400 punti vendita o un'università con un campus distribuito, diventa impraticabile. Le opzioni sono centralizzare i server RADIUS, accettando la latenza di autenticazione dalle sedi remote, oppure distribuire server in ogni sede e gestirli singolarmente. Nessuna delle due opzioni è scalabile.

L'architettura di RADIUS as a Service

RADIUS as a Service è un modello di distribuzione basato su cloud per il protocollo RADIUS. Il protocollo stesso rimane invariato, seguendo la specifica RFC 2865 e le sue estensioni. Ciò che cambia è chi gestisce l'infrastruttura.

Quando un dispositivo si connette alla rete WiFi, l'access point (il client RADIUS) inoltra la richiesta di autenticazione agli endpoint RADIUS in cloud tramite un tunnel sicuro e crittografato. Il servizio cloud convalida le credenziali rispetto al provider di identità e restituisce un messaggio di Access-Accept o Access-Reject, insieme ad attributi di policy come l'assegnazione dinamica della VLAN. Dal punto di vista dell'access point, il flusso di autenticazione è identico a quello del RADIUS on-premise.

Il cloud provider gestisce i server RADIUS in più data center distribuiti geograficamente. Il failover è automatico. Se un endpoint non è disponibile, il traffico viene instradato verso quello successivo funzionante, senza alcun intervento da parte del vostro team. Per le organizzazioni con sedi in più regioni, l'autenticazione avviene presso l'endpoint cloud più vicino, mantenendo bassa la latenza indipendentemente dalla posizione geografica.

IEEE 802.1X ed EAP metodi

IEEE 802.1X è lo standard per il controllo dell'accesso alla rete basato su porta (NAC). Impone a un dispositivo di autenticarsi prima che gli venga assegnato un indirizzo IP e gli sia consentito il transito del traffico. RADIUS è il server di autenticazione in un'implementazione 802.1X.

L'Extensible Authentication Protocol (EAP) definisce la modalità di scambio delle credenziali. Il RADIUS in cloud supporta l'intera gamma di metodi EAP:

Metodo EAP	Tipo di autenticazione	Livello di sicurezza	Uso consigliato
EAP-TLS	Basata su certificato reciproco	Massimo	Dispositivi aziendali con certificati gestiti da MDM
PEAP-MSCHAPv2	Nome utente e password	Moderato	Dispositivi legacy o BYOD senza MDM
EAP-TTLS	Credenziali in tunnel	Moderato	Ambienti misti
MAC Authentication Bypass	Indirizzo MAC del dispositivo	Basso	Dispositivi IoT che non supportano 802.1X

EAP-TLS, definito nella specifica RFC 5216, rappresenta lo standard di riferimento. Sia il dispositivo client che il server RADIUS si presentano reciprocamente certificati digitali. Questa autenticazione reciproca elimina completamente le password dal processo di accesso alla rete. Un certificato è legato crittograficamente al dispositivo e non può essere oggetto di phishing, indovinato o rubato come una password. Per le organizzazioni che hanno subito violazioni basate sulle credenziali, questa è la mitigazione tecnica più diretta disponibile.

Assegnazione dinamica della VLAN

Oltre all'autenticazione, il server RADIUS applica l'autorizzazione. Quando accetta una connessione, restituisce gli attributi di policy all'access point, incluso l'ID VLAN da assegnare al dispositivo. Questa assegnazione dinamica della VLAN è il meccanismo che abilita le reti basate sull'identità (Identity-Based Networks).

Un addetto alla reception di un hotel si autentica e viene inserito nella VLAN front-of-house con accesso al sistema di gestione della struttura. Un addetto alle pulizie viene inserito in una VLAN limitata con solo accesso a Internet. Un dispositivo ospite viene inserito nella VLAN Guest WiFi, completamente isolato da tutte le risorse aziendali. Un dispositivo IoT, come una telecamera di sicurezza, viene inserito in una VLAN dedicata VLAN IoT. Tutto questo avviene automaticamente, in base all'identità verificata dal server RADIUS, senza alcuna configurazione manuale della VLAN per dispositivo.

Questo è il principio del privilegio minimo applicato all'accesso alla rete. Non si considera attendibile un dispositivo solo perché si è connesso a un particolare SSID. L'accesso viene concesso in base all'identità verificata, limitandolo esclusivamente a ciò che tale identità richiede. Per un approfondimento su come questo si inserisca in una strategia di controllo dell'accesso alla rete più ampia, consulta la nostra guida sui sistemi di controllo dell'accesso alla rete .

Integrazione nativa dell'identità cloud

Il vantaggio più significativo a livello operativo di cloud RADIUS è la sua integrazione nativa con i moderni provider di identità. Cloud RADIUS si connette direttamente a Microsoft Entra ID, Okta e Google Workspace tramite protocolli standard, tra cui OIDC, SAML e LDAP. Quando abiliti un nuovo dipendente nel tuo provider di identità, questo può autenticarsi immediatamente alla rete WiFi. Quando disabiliti un dipendente, disattivi il suo account nella directory e il suo accesso WiFi viene revocato istantaneamente, in ogni access point e in qualsiasi sede.

Questa sincronizzazione in tempo reale elimina una delle falle di sicurezza più persistenti nel WiFi aziendale: l'ex dipendente che possiede ancora la PSK condivisa o il cui account RADIUS non è stato eliminato manualmente al momento delle dimissioni. Con cloud RADIUS e un provider di identità cloud, il deprovisioning è un'unica azione con effetto immediato su tutta la rete.

Guida all'implementazione

Passaggio 1: Connetti il tuo provider di identità

Connetti il servizio cloud RADIUS al tuo provider di identità. Per Microsoft Entra ID o Google Workspace, questo comporta in genere l'autorizzazione di un'applicazione aziendale tramite OAuth o la configurazione di un connettore LDAP. Mappa i gruppi della tua directory su policy di rete specifiche. Definisci la tassonomia dei ruoli prima di iniziare: quali gruppi corrispondono a quali VLAN e quali diritti di accesso comporta ciascuna VLAN. Impostare correttamente questo aspetto all'inizio evita significativi sforzi di rielaborazione successivi.

Passaggio 2: Distribuisci i certificati per i dispositivi aziendali

Per i dispositivi di proprietà dell'azienda, configura la tua piattaforma di Mobile Device Management (MDM), come Microsoft Intune o Jamf, per inviare i certificati client ai dispositivi. Questo abilita l'autenticazione EAP-TLS. Assicurati che la Root Certificate Authority (CA) che ha emesso il certificato del server RADIUS sia considerata attendibile da tutti i dispositivi client. Una catena di attendibilità interrotta è la causa più comune di errori di autenticazione silenziosi.

Passaggio 3: Configura l'hardware di rete

Aggiungi gli indirizzi IP di cloud RADIUS e le chiavi segrete condivise (shared secrets) ai tuoi controller wireless o access point. Configura sempre sia l'endpoint primario che quello secondario per utilizzare la ridondanza integrata del provider. Assicurati che le porte UDP 1812 (autenticazione) e 1813 (accounting) siano aperte in uscita dai tuoi access point verso gli endpoint cloud RADIUS. Verifica questo aspetto prima della messa in servizio. Le regole del firewall configurate in modo errato sono la seconda causa più comune di fallimento dell'implementazione.

Cloud RADIUS funziona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. I passaggi di configurazione variano a seconda del fornitore, ma il protocollo RADIUS è standardizzato, quindi i parametri principali (IP del server, chiave segreta condivisa, porta di autenticazione) sono coerenti.

Passaggio 4: Definisci le policy VLAN

Configura l'assegnazione dinamica della VLAN nel motore delle policy RADIUS. Mappa ogni ruolo utente o tipo di dispositivo su un ID VLAN specifico. Testa ogni policy prima del rilascio in produzione. Una semplice matrice di test (un dispositivo per ruolo, una VLAN per ruolo, verifica del posizionamento) rileva la maggior parte degli errori di configurazione prima che abbiano un impatto sugli utenti.

Best practice

Imponi l'uso di EAP-TLS per tutti i dispositivi aziendali. Abbandona PEAP-MSCHAPv2 non appena la distribuzione del tuo MDM lo consente. PEAP si basa su password, che possono essere compromesse. EAP-TLS si basa su certificati, che non possono esserlo.

Segmenta tutto. Non inserire mai personale, ospiti e dispositivi IoT nella stessa sottorete. Utilizza RADIUS per imporre limiti VLAN rigorosi. Questo è fondamentale per gli ambienti del settore Retail che gestiscono i dati delle carte di pagamento secondo lo standard PCI DSS e per gli ambienti del settore Healthcare che proteggono i dati dei pazienti.

Allineati a WPA3-Enterprise. WPA3-Enterprise, l'attuale standard di sicurezza WiFi, richiede l'autenticazione 802.1X. Assicurati che i tuoi access point supportino WPA3-Enterprise e configuralo come standard di sicurezza minimo per le reti del personale.

Controlla regolarmente i log di RADIUS. Cloud RADIUS fornisce log di controllo centralizzati. Esamina gli errori di autenticazione settimanalmente. Un picco di errori da un dispositivo o da una sede specifica è un indicatore precoce di una configurazione errata o di un potenziale attacco.

Testa il failover. Almeno una volta a trimestre, simula un guasto dell'endpoint RADIUS primario e verifica che l'autenticazione continui tramite l'endpoint secondario. Documenta il risultato. Si tratta di un test semplice che la maggior parte dei team non esegue mai finché non ne ha effettivo bisogno.

Per le strutture che distribuiscono il WiFi in ambienti complessi, comprese località marittime o remote, consulta la nostra guida su come configurare un Captive Portal su Starlink per considerazioni sulla dipendenza dalla rete WAN.

Risoluzione dei problemi e mitigazione dei rischi

Timeout di autenticazione

Se i dispositivi non riescono ad autenticarsi, verifica innanzitutto la connettività tra i tuoi access point e gli endpoint cloud RADIUS. Verifica che le porte UDP 1812 e 1813 siano aperte in uscita. L'ispezione approfondita dei pacchetti (Deep packet inspection) sui firewall moderni può ritardare o scartare i pacchetti RADIUS. Se riscontri dei timeout, controlla le regole della tua policy firewall che potrebbero ispezionare o limitare la velocità del traffico UDP verso gli endpoint RADIUS.

Errori della catena di attendibilità del certificato

Se utilizzi EAP-TLS, assicurati che i dispositivi client considerino attendibile la Root CA che ha emesso il certificato del server RADIUS. Se la catena di attendibilità è interrotta, il dispositivo rifiuterà silenziosamente la connessione per prevenire un attacco man-in-the-middle. Questo si presenta come un errore di connessione senza alcun messaggio di errore evidente. Controlla i log del server RADIUS per Errori di handshake EAP-TLS. Distribuisci il certificato Root CA a tutti i dispositivi gestiti tramite MDM.

Dipendenza dalla WAN

Cloud RADIUS richiede una connessione internet attiva. Se il collegamento WAN si interrompe, le richieste di autenticazione non possono raggiungere il server. Per le risorse locali mission-critical, valuta access point che supportino la sopravvivenza locale o il caching dell'autenticazione. Per la maggior parte delle distribuzioni, la dipendenza dalla WAN è accettabile poiché un sito senza internet non può comunque accedere alle applicazioni cloud.

Mancata corrispondenza dei segreti condivisi

Ogni access point o controller wireless deve essere configurato come client RADIUS con il segreto condiviso corretto. Una mancata corrispondenza causa lo scarto silenzioso di tutte le richieste di autenticazione provenienti da quel dispositivo. Se un access point specifico non funziona mentre altri hanno successo, verifica la configurazione del segreto condiviso su quel dispositivo.

ROI e impatto aziendale

Il business case per il RADIUS as a Service si basa su tre pilastri: riduzione delle spese in conto capitale, minori costi operativi e un migliore livello di sicurezza.

In termini di spese in conto capitale, elimini i costi di acquisto, licenza e aggiornamento dei server fisici. Una distribuzione RADIUS on-premise minima richiede due server per l'alta affidabilità, licenze del sistema operativo e l'aggiornamento dell'hardware ogni tre-cinque anni. Per un gruppo alberghiero con 50 strutture, ciò rappresenta un investimento hardware significativo su tutto il patrimonio immobiliare.

In termini di costi operativi, il tuo team di ingegneria non deve più dedicare tempo all'applicazione di patch su Windows Server, alla risoluzione dei problemi delle configurazioni FreeRADIUS o alla gestione dei rinnovi dei certificati sull'infrastruttura fisica. Quel tempo viene reindirizzato ad attività sulle policy di sicurezza che migliorano direttamente il tuo livello di protezione.

In termini di sicurezza, il passaggio a EAP-TLS e all'assegnazione dinamica delle VLAN riduce significativamente la superficie di attacco. Il furto di credenziali è la causa principale delle violazioni di rete. L'eliminazione delle password dal processo di autenticazione di rete affronta direttamente questo rischio. La registrazione centralizzata dei log di controllo supporta la conformità a PCI DSS v4.0 e GDPR, riducendo i costi e la complessità degli audit di conformità.

Per le organizzazioni che gestiscono hub di Trasporto o sedi ad alta affluenza, la capacità di applicare policy di sicurezza coerenti in tutte le sedi da un'unica dashboard rappresenta un miglioramento operativo misurabile. Purple opera in oltre 80.000 sedi attive e ha elaborato 440 milioni di accessi nel 2024 (dati interni Purple, 2024). L'infrastruttura che supporta tale scala è cloud-native per progettazione.

Per una panoramica più ampia di come l'analisi WiFi e la network intelligence si collegano ai risultati aziendali, consulta la nostra piattaforma di WiFi Analytics .

Riferimenti

[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. Febbraio 2026. [5] SecureW2. Cloud vs. On-Site RADIUS: Which is Better? Maggio 2026. [6] Portnox. RADIUS as a Service. 2026. [7] PCI Security Standards Council. PCI DSS v4.0. Marzo 2022. [8] Purple. Dati interni della piattaforma: 440 milioni di accessi, oltre 80.000 sedi. 2024.

Definizioni chiave

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.

Esempi pratici

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.

Commento dell'esaminatore: 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.

Commento dell'esaminatore: 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.

Domande di esercitazione

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?

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

Visualizza risposta modello

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?

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

Visualizza risposta modello

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?

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

Visualizza risposta modello

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.

Continua a leggere questa serie

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

Questa guida di riferimento tecnico descrive in dettaglio come integrare RADIUS as a Service con le directory cloud (Microsoft Entra ID e Google Workspace) per l'autenticazione WiFi aziendale. Copre il passaggio architetturale da NPS on-premise a RADIUS cloud-native, l'implementazione dell'autenticazione EAP-TLS basata su certificati e le migliori pratiche operative per proteggere l'accesso wireless nei settori dell'ospitalità, del retail e pubblico. Per i responsabili IT e gli architetti di rete che hanno già investito nell'identità cloud, questa guida colma il divario tra la gestione delle directory e la sicurezza della rete fisica.

How to Implement 802.1X Authentication with Cloud RADIUS

Questa guida di riferimento tecnica fornisce un quadro completo per l'implementazione dell'autenticazione 802.1X con Cloud RADIUS in ambienti aziendali distribuiti. Descrive in dettaglio l'architettura, la selezione del metodo EAP, la sequenza di implementazione e le strategie di mitigazione del rischio necessarie per proteggere l'accesso alla rete, eliminando al contempo il sovraccarico operativo dell'infrastruttura on-premises.

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

Questa guida completa esplora Cloud RADIUS (RADIUS as a Service), dettagliandone l'architettura, i metodi EAP e le strategie di implementazione. Fornisce ai leader IT approfondimenti pratici sulla migrazione da server on-premises a un modello di autenticazione basato su cloud scalabile, sicuro e conforme.