Saltar para o conteúdo principal

O que é Cloud RADIUS? Um Guia Abrangente para RADIUS como Serviço

Este guia abrangente explora o Cloud RADIUS (RADIUS as a Service), detalhando a sua arquitetura, métodos EAP e estratégias de implementação. Fornece aos líderes de TI informações acionáveis sobre a migração de servidores no local para um modelo de autenticação baseado na nuvem, escalável, seguro e em conformidade.

📖 5 min de leitura📝 1,077 palavras🔧 2 exemplos práticos3 perguntas de prática📚 8 definições principais

Ouça este guia

Ver transcrição do podcast
What is Cloud RADIUS? A Comprehensive Guide to RADIUS as a Service. Welcome to the Purple WiFi Intelligence Podcast. I'm your host, and today we're doing a deep-dive briefing on Cloud RADIUS — what it is, how it works under the hood, and critically, how to evaluate whether it's the right move for your organisation this quarter. Whether you're running a hotel group, a retail estate, a stadium, or a public-sector network, this one's for you. Let's set the scene. Introduction and Context. If you've ever had to explain to a board why your network authentication server went down at 2am — and why it took three hours to bring back up — you already understand the core problem Cloud RADIUS solves. Traditional on-premises RADIUS infrastructure is powerful, but it carries significant operational overhead. Hardware to procure, patch cycles to manage, redundancy to architect manually, and a single point of failure sitting in your server room. Cloud RADIUS, or RADIUS as a Service, moves that authentication layer into a managed, highly available cloud environment. The protocol itself — Remote Authentication Dial-In User Service — hasn't changed. It's still the backbone of IEEE 802.1X network access control, still the mechanism your access points use to validate who gets onto your network. But the infrastructure running it is now someone else's problem. And in enterprise IT, that's a significant shift. So let's get into the technical detail. Technical Deep-Dive. RADIUS was originally defined in RFC 2865, published back in 2000, and it's remained remarkably durable. The protocol operates on a client-server model. Your network access device — whether that's a WiFi access point, a VPN concentrator, or a wired switch — acts as the RADIUS client, also called the Network Access Server or NAS. When a user attempts to connect, the NAS forwards an Access-Request packet to the RADIUS server, which validates the credentials against a user directory — typically Active Directory, LDAP, or a cloud identity provider — and returns either an Access-Accept or Access-Reject. That's the core exchange. But the real complexity sits in what happens around it: EAP methods, VLAN assignment, policy enforcement, accounting records, and certificate management. In a traditional on-premises deployment, you're running FreeRADIUS or Microsoft NPS on dedicated hardware, managing your own certificates, configuring your own failover, and maintaining your own user database sync. For a single-site deployment with a competent IT team, that's manageable. For a 50-site retail estate or a hotel group with properties across multiple countries, it becomes a significant operational burden. Cloud RADIUS abstracts all of that. The authentication logic, the certificate infrastructure, the redundancy, and the policy engine are all delivered as a managed service. Your access points point to cloud-hosted RADIUS endpoints — typically a primary and secondary IP address — and the service handles everything behind that. Now, let's talk about the authentication methods, because this is where the technical decisions really matter. The most common EAP method in enterprise WiFi is PEAP — Protected EAP — which tunnels MSCHAPv2 inside a TLS session. It's widely supported, works with Active Directory natively, and is the default for most Windows and Android devices. However, PEAP has known vulnerabilities, particularly around certificate validation. If your client devices aren't configured to verify the server certificate, you're exposed to credential harvesting attacks via rogue access points. EAP-TLS is the gold standard. It uses mutual certificate authentication — both the server and the client present certificates — which eliminates the password attack surface entirely. The trade-off is client certificate deployment, which requires a PKI infrastructure and MDM integration. For managed device fleets, this is absolutely the right choice. For BYOD environments, it's more complex. EAP-TTLS and EAP-FAST are also worth knowing. TTLS is particularly common in environments where you need to support a wide range of client devices, including Linux systems. EAP-FAST was developed by Cisco as an alternative to PEAP that avoids the certificate validation dependency, using Protected Access Credentials instead. A well-architected Cloud RADIUS service supports all of these methods and lets you configure per-SSID policy — so your corporate SSID uses EAP-TLS with certificate validation, your staff SSID uses PEAP with Active Directory, and your guest network uses a captive portal or social login flow entirely separate from the RADIUS stack. Speaking of which — RADIUS and guest WiFi are often conflated, but they serve different purposes. RADIUS is your authentication and authorisation layer for known users and devices. Guest WiFi typically uses a captive portal flow, which is a different mechanism entirely. Purple's platform, for instance, handles guest authentication through a separate identity layer, capturing first-party data and enabling marketing automation, while RADIUS handles the corporate and staff network access control. These are complementary, not competing, systems. Now, let's talk about what "cloud-hosted" actually means in practice. A properly architected Cloud RADIUS service runs across multiple availability zones, with automatic failover. Authentication requests are load-balanced across nodes, and the service maintains sub-100-millisecond response times even under peak load. For a stadium handling 40,000 concurrent connections during an event, that latency and throughput profile is critical. A single on-premises server simply cannot match that elasticity. From a compliance perspective, Cloud RADIUS providers operating in the UK and EU need to be GDPR-compliant in how they handle authentication logs and user data. For retail and hospitality environments that also process payment card data, PCI DSS requirements around network segmentation and access control are directly relevant — RADIUS is part of your control environment, and your QSA will want to see evidence of proper configuration and audit logging. WPA3 is also worth addressing. The transition from WPA2 to WPA3 introduces Simultaneous Authentication of Equals — SAE — for personal networks, and WPA3-Enterprise for corporate environments. WPA3-Enterprise mandates 192-bit security mode for the highest classification, which requires specific EAP methods and cipher suites. A Cloud RADIUS service needs to support these configurations to be future-proof. Implementation Recommendations and Pitfalls. Right, let's get practical. If you're evaluating Cloud RADIUS for deployment this quarter, here's what I'd focus on. First, integration with your identity provider. Your Cloud RADIUS service needs to sync with wherever your users actually live — whether that's Microsoft Entra ID, formerly Azure AD, Google Workspace, Okta, or an on-premises Active Directory via LDAP proxy. The quality of this integration determines your operational overhead. Native SAML or SCIM provisioning is far preferable to manual CSV imports. Second, certificate management. If you're deploying EAP-TLS, you need a clear answer on how client certificates are issued, renewed, and revoked. The best Cloud RADIUS services include an integrated PKI or integrate cleanly with your existing certificate authority. Certificate expiry is one of the most common causes of authentication failures in enterprise WiFi — it's entirely avoidable with proper automation. Third, network device compatibility. Your access points need to support RADIUS authentication — virtually all enterprise-grade APs do — but you need to verify the specific EAP methods and RADIUS attributes your chosen service supports against your AP vendor's implementation. Cisco, Aruba, Juniper Mist, and Ruckus all have their own nuances in how they handle RADIUS attributes and CoA — Change of Authorisation — messages. Fourth, redundancy configuration. Always configure both a primary and secondary RADIUS server IP. The failover timeout on your NAS devices matters — if it's set too high, users will experience a 30-second authentication delay when the primary is unreachable. A 3-to-5-second timeout with immediate failover is the right configuration for most environments. Fifth — and this is the one people miss — accounting. RADIUS accounting records are your audit trail. They tell you who connected, from which device, at what time, and for how long. For compliance purposes, particularly in healthcare and public-sector environments, these records need to be retained and accessible. Make sure your Cloud RADIUS provider gives you access to accounting data, not just authentication logs. Common pitfalls: shared secret complexity. Your RADIUS shared secret — the pre-shared key between your NAS and the RADIUS server — needs to be long and random. Short or guessable shared secrets are a real attack vector. Use at least 32 characters, generated randomly, and rotate them on a schedule. Also watch out for IP whitelisting. Many Cloud RADIUS services require you to whitelist the source IPs of your NAS devices. In a dynamic cloud environment where your AP management platform might use NAT, this can cause unexpected authentication failures. Confirm the NAT behaviour of your network before deployment. Rapid-Fire Q&A. Let me run through a few questions I get asked regularly. Can Cloud RADIUS support multi-tenant environments? Yes — most enterprise Cloud RADIUS services support tenant isolation, so a managed service provider can run separate RADIUS policies for multiple clients from a single platform. What's the typical latency for a Cloud RADIUS authentication? Sub-100 milliseconds for a well-architected service. The 802.1X handshake itself adds some overhead, but for most EAP methods, total authentication time should be under 500 milliseconds end-to-end. Does Cloud RADIUS work with OpenRoaming? Yes. OpenRoaming — the Wireless Broadband Alliance's roaming framework — uses RADIUS federation at its core. A Cloud RADIUS service that supports Hotspot 2.0 and OpenRoaming allows your users to authenticate automatically across participating networks globally. Purple supports OpenRoaming under its Connect licence, acting as an identity provider in the federation. Is Cloud RADIUS suitable for high-security environments? For most enterprise environments, yes. For environments with classified data or specific government security classifications, you may need to evaluate whether a managed cloud service meets your specific accreditation requirements. Summary and Next Steps. To bring this together: Cloud RADIUS is a mature, production-ready approach to network access control that removes the operational burden of on-premises RADIUS infrastructure without compromising on security or capability. For multi-site organisations, the ROI case is straightforward — you eliminate hardware capex, reduce IT overhead, gain built-in redundancy, and get a service that scales with your estate. The key decisions are: which EAP method is right for your device fleet, how you integrate with your existing identity provider, and whether your chosen service gives you the compliance and audit capabilities your organisation requires. If you're running a hotel group, a retail chain, or managing public-sector networks, I'd recommend starting with a proof-of-concept on a single site — get your RADIUS configuration right, validate the integration with your identity provider, and measure authentication latency before rolling out across your estate. For more on WiFi analytics, guest network management, and how Purple's platform integrates with RADIUS-based authentication, visit purple.ai. Thanks for listening.

header_image.png

Resumo Executivo

Para as redes empresariais modernas, a arquitetura tradicional de RADIUS (Remote Authentication Dial-In User Service) no local representa um significativo gargalo operacional. Gerir servidores físicos, aplicar patches a sistemas operativos, lidar com autoridades de certificação e projetar redundância multi-site consome recursos de TI valiosos. O Cloud RADIUS (ou RADIUS as a Service) aborda esta questão migrando a camada de autenticação IEEE 802.1X para uma infraestrutura de nuvem gerida e altamente disponível. Este guia fornece uma visão técnica abrangente do Cloud RADIUS para gestores de TI, arquitetos de rede e CTOs que avaliam estratégias de implementação. Ao mudar de sistemas com elevado capex e manutenção manual para um modelo elástico e globalmente distribuído, as organizações em Retalho , Hotelaria e Transportes podem aplicar políticas de acesso robustas, alcançar a conformidade (como PCI DSS e GDPR) e integrar-se perfeitamente com fornecedores de identidade modernos como Microsoft Entra ID e Google Workspace.

Análise Técnica Detalhada

A Evolução da Arquitetura RADIUS

O RADIUS, definido inicialmente no RFC 2865, opera num modelo cliente-servidor onde os Network Access Servers (NAS) — como pontos de acesso WiFi ou concentradores VPN — encaminham os pedidos de autenticação para um servidor central. Historicamente, isto significava implementar o FreeRADIUS ou o Microsoft Network Policy Server (NPS) em hardware dedicado. Embora funcional para implementações de um único site, escalar esta arquitetura em ambientes distribuídos introduz desafios significativos de latência e redundância.

O Cloud RADIUS abstrai a infraestrutura subjacente. Os pedidos de autenticação são encaminhados para endpoints de nuvem distribuídos globalmente, garantindo tempos de resposta inferiores a 100ms mesmo sob cargas de pico. Esta elasticidade é crucial para ambientes de alta densidade como estádios ou centros de conferências.

architecture_overview.png

Métodos EAP e Postura de Segurança

A escolha do método Extensible Authentication Protocol (EAP) dita fundamentalmente a sua postura de segurança:

  • PEAP (Protected EAP): Tunela MSCHAPv2 dentro de uma sessão TLS. Embora amplamente suportado e fácil de integrar com o Active Directory, o PEAP é vulnerável à recolha de credenciais através de pontos de acesso não autorizados se os dispositivos cliente não estiverem estritamente configurados para validar o certificado do servidor.
  • EAP-TLS: O padrão ouro empresarial. Requer autenticação mútua de certificados — tanto o servidor quanto o cliente devem apresentar certificados válidos. Isto elimina completamente os ataques baseados em palavra-passe, mas necessita de uma robusta Infraestrutura de Chave Pública (PKI) e integração de Gestão de Dispositivos Móveis (MDM) para a implementação de certificados.
  • EAP-TTLS e EAP-FAST: Fornecem alternativas onde é necessária uma ampla compatibilidade de cliente (incluindo sistemas legados ou Linux), ou onde as dependências de validação de certificados precisam de ser contornadas usando Credenciais de Acesso Protegido (PACs).

WPA3 e Integração OpenRoaming

As implementações modernas devem ter em conta o WPA3-Enterprise, que exige o modo de segurança de 192 bits para as classificações mais elevadas, requerendo suites de cifra específicas. Além disso, o Cloud RADIUS facilita a participação em frameworks de federação como o OpenRoaming. A Purple, por exemplo, atua como um fornecedor de identidade gratuito para o OpenRoaming sob a sua licença Connect, permitindo uma autenticação segura e sem interrupções em redes globais participantes.

Guia de Implementação

A implementação do Cloud RADIUS requer uma abordagem sistemática para garantir zero tempo de inatividade durante a transição.

Passo 1: Integração do Fornecedor de Identidade (IdP)

A sua instância de Cloud RADIUS deve sincronizar com o seu diretório de utilizadores autoritativo. O aprovisionamento nativo SAML ou SCIM com Microsoft Entra ID, Google Workspace ou Okta é altamente recomendado em vez de proxies LDAP manuais ou importações CSV. Isto garante que, quando um funcionário é desvinculado no sistema de RH, o seu acesso à rede é revogado instantaneamente.

Passo 2: Estratégia de Gestão de Certificados

Se estiver a implementar EAP-TLS, defina o seu ciclo de vida de certificados. Selecione um fornecedor de Cloud RADIUS que inclua uma PKI integrada ou que se integre perfeitamente com a sua Autoridade de Certificação (CA) existente. Automatize a emissão e revogação de certificados através da sua plataforma MDM (por exemplo, Intune ou Jamf) para evitar falhas de autenticação devido a certificados expirados.

Passo 3: Configuração de Dispositivos de Rede

Configure os seus dispositivos NAS (pontos de acesso, switches) para apontar para os endereços IP primário e secundário do Cloud RADIUS. Certifique-se de que o segredo partilhado é criptograficamente complexo (mínimo de 32 caracteres aleatórios). Ajuste as configurações de tempo limite de failover; um tempo limite de 3 a 5 segundos é ideal para evitar atrasos prolongados na autenticação se o nó primário estiver inacessível.

Passo 4: Definição de Políticas

Estabeleça políticas por SSID. Por exemplo, exija EAP-TLS para a rede corporativa, PEAP para dispositivos IoT legados e isole o acesso de convidados. Note que o RADIUS lida com utilizadores conhecidos; para visitantes, implemente uma solução dedicada de Guest WiFi com um captive portal para capturar dados primários, integrando com uma plataforma de WiFi Analytics . Para mais informações sobre o envolvimento de convidados, consulte Como Melhorar a Satisfação do Convidado: O Guia Definitivo .

comparison_chart.png

Melhores Práticas

  • Implementar Certificados de Servidor RigorososValidação de Certificados: Para implementações PEAP, aplique políticas de grupo ou perfis MDM que forcem os clientes a validar o certificado do servidor RADIUS e restrinjam a confiança a CAs Raiz específicas.
  • Segmentar Tráfego de Contabilidade e Autenticação: Garanta que os dados de contabilidade RADIUS sejam ativamente monitorizados e retidos. Este registo de auditoria é crítico para relatórios de conformidade (p.g., PCI DSS, HIPAA).
  • Monitorizar Latência de Autenticação: Alta latência frequentemente indica roteamento subótimo ou problemas de sincronização IdP. Utilize ferramentas de monitorização para rastrear o tempo decorrido desde o Access-Request até ao pacote Access-Accept.
  • Otimizar Planeamento de Sinal e Canal: A autenticação fiável depende de uma camada física estável. Consulte guias como Understanding RSSI and Signal Strength for Optimal Channel Planning para garantir que o seu ambiente de RF suporta roaming 802.1X contínuo.

Resolução de Problemas e Mitigação de Riscos

Mesmo com serviços geridos, configurações incorretas podem causar falhas de acesso. Os modos de falha comuns incluem:

  • Expiração de Certificado: A principal causa de falhas EAP-TLS. Mitigação: Implemente alertas automatizados 30 dias antes da expiração do certificado CA ou do servidor.
  • Incompatibilidade de Segredo Partilhado: Ocorre frequentemente ao adicionar novos pontos de acesso. Mitigação: Padronize os modelos de configuração no seu sistema de gestão de rede.
  • Problemas de NAT e Whitelisting de IP: Os fornecedores de Cloud RADIUS geralmente exigem o whitelisting de IP do NAS. Se os seus escritórios de filial utilizam IPs dinâmicos ou configurações NAT complexas, os pedidos de autenticação podem ser descartados. Mitigação: Utilize IPs de saída estáticos ou implemente um proxy RADIUS local, se necessário.
  • Falhas de Sincronização IdP: Se o diretório na cloud falhar ao sincronizar com o AD no local, novos utilizadores não conseguirão autenticar. Mitigação: Monitorize ativamente o estado do conector SCIM/LDAP.

ROI e Impacto no Negócio

A transição para Cloud RADIUS oferece valor de negócio mensurável:

  1. Redução do Capex de Infraestrutura: Elimina a necessidade de adquirir, instalar e alimentar servidores RADIUS físicos em cada local principal.
  2. Menor Sobrecarga Operacional: As equipas de TI deixam de gastar horas a aplicar patches a vulnerabilidades do SO ou a gerir manualmente o failover do servidor. As atualizações geridas pelo fornecedor garantem conformidade contínua.
  3. Postura de Segurança Reforçada: A transição para EAP-TLS via PKI na cloud mitiga o risco de roubo de credenciais, reduzindo diretamente o custo potencial de uma violação de dados.
  4. Agilidade e Escalabilidade: Ao abrir uma nova filial de retalho ou hotel, a autenticação de rede pode ser provisionada em minutos, em vez de semanas. Para estratégias de implementação práticas, consulte Setting Up WiFi for Business: A 2026 Playbook .

Ao centralizar o controlo de acesso, as organizações não só protegem os seus perímetros, mas também libertam talentos de engenharia sénior para se concentrarem em iniciativas estratégicas, em vez de manterem infraestruturas legadas.

Definições Principais

Cloud RADIUS

A managed service that hosts the Remote Authentication Dial-In User Service protocol in a highly available cloud environment, eliminating the need for on-premises authentication servers.

Evaluated by IT teams seeking to reduce hardware capex and operational overhead while maintaining secure 802.1X network access.

EAP-TLS (Extensible Authentication Protocol-Transport Layer Security)

A highly secure authentication method requiring both the client and the server to present digital certificates to prove their identity.

The recommended standard for enterprise networks to prevent password-based attacks, requiring PKI and MDM for deployment.

NAS (Network Access Server)

The device—such as a WiFi access point, switch, or VPN concentrator—that acts as the RADIUS client, forwarding user credentials to the RADIUS server.

Network engineers must configure the NAS with the correct RADIUS server IPs and shared secrets to enable 802.1X authentication.

Shared Secret

A cryptographic text string known only to the NAS and the RADIUS server, used to encrypt RADIUS packets and verify the sender's authenticity.

A weak shared secret is a major security vulnerability; enterprise deployments should use long, randomly generated strings.

SCIM (System for Cross-domain Identity Management)

An open standard that automates the exchange of user identity information between IT systems or cloud applications.

Used to automatically provision and de-provision users in the Cloud RADIUS directory when changes are made in the primary HR or IT identity system.

OpenRoaming

A federation framework developed by the Wireless Broadband Alliance that allows users to automatically and securely connect to participating WiFi networks globally.

Cloud RADIUS providers that support OpenRoaming (like Purple) allow venues to offer seamless, secure connectivity to visitors without captive portals.

Accounting Logs

Records generated by the RADIUS server detailing user connection events, including start time, end time, data transferred, and IP address assigned.

Critical for security audits, troubleshooting, and demonstrating compliance with frameworks like PCI DSS and GDPR.

Change of Authorization (CoA)

A RADIUS feature that allows the server to dynamically modify a user's active session, such as changing their VLAN or disconnecting them, without requiring a reconnection.

Used by network administrators to instantly quarantine a compromised device or apply new policy restrictions mid-session.

Exemplos Práticos

A 200-room hotel currently uses on-premises Microsoft NPS for staff WiFi authentication via PEAP. They are experiencing authentication timeouts during peak check-in hours and want to migrate to Cloud RADIUS with EAP-TLS for better security and reliability. How should the IT Director architect this migration?

  1. Deploy a Cloud RADIUS tenant and integrate it with the hotel's Microsoft Entra ID via SCIM for automated user lifecycle management. 2. Configure the Cloud RADIUS integrated PKI to issue client certificates. 3. Use the existing MDM (e.g., Intune) to push the Root CA, client certificates, and a new WiFi profile configured for EAP-TLS to all staff devices. 4. Configure the hotel's access points to point to the primary and secondary Cloud RADIUS IPs, using a new, complex 32-character shared secret. 5. Run both the old NPS and new Cloud RADIUS in parallel on different SSIDs for a two-week transition period before decommissioning the on-premise servers.
Comentário do Examinador: This approach minimizes risk by running parallel SSIDs during the transition. Moving to EAP-TLS eliminates the credential harvesting risks associated with PEAP, and leveraging MDM for certificate deployment ensures zero friction for the end users. The SCIM integration guarantees that when staff leave, their access is instantly revoked.

A national retail chain with 500 locations needs to ensure PCI DSS compliance for its point-of-sale (POS) terminals, which connect via WiFi. They are moving to Cloud RADIUS. What specific configurations are required to meet compliance?

  1. Implement strict network segmentation: POS terminals must authenticate to a dedicated, hidden SSID mapped to an isolated VLAN. 2. Enforce EAP-TLS authentication for all POS devices to ensure mutual authentication and prevent rogue devices from joining the POS network. 3. Configure the Cloud RADIUS service to retain all accounting logs (Access-Accept, Access-Reject, connection duration) for a minimum of one year, as mandated by PCI DSS. 4. Ensure the RADIUS shared secrets between the branch APs and the Cloud RADIUS service are rotated every 90 days using an automated script.
Comentário do Examinador: This solution directly addresses PCI DSS requirements for logical segmentation, strong access control, and auditability. Relying on MAC address filtering is insufficient for compliance; EAP-TLS provides the necessary cryptographic proof of device identity. Retaining accounting logs in the cloud simplifies the audit process for the QSA.

Perguntas de Prática

Q1. Your organisation is migrating from an on-premises Active Directory to Google Workspace. You currently use PEAP-MSCHAPv2 for WiFi authentication. Why is this a problem, and what is the recommended solution?

Dica: Consider how PEAP validates credentials against the directory protocol.

Ver resposta modelo

PEAP-MSCHAPv2 relies on the NT hash of a user's password, which Google Workspace does not store or expose natively. The recommended solution is to migrate to EAP-TLS using a Cloud RADIUS provider that features an integrated PKI. The Cloud RADIUS service can sync user identities from Google Workspace via SAML/SCIM, and authenticate devices using client certificates rather than passwords.

Q2. A branch office reports that users are experiencing 30-second delays when connecting to the WiFi network, followed by a successful connection. The primary Cloud RADIUS IP in that region is currently undergoing maintenance. What configuration error is causing this delay?

Dica: Look at the communication between the NAS and the RADIUS servers.

Ver resposta modelo

The NAS (Access Point or Switch) has the RADIUS server timeout configured too high (e.g., 30 seconds). It is waiting for the primary server to respond before failing over to the secondary server. The timeout should be reduced to 3-5 seconds to ensure rapid failover without impacting the user experience.

Q3. You are deploying Cloud RADIUS for a hospital. The security team mandates that only corporate-owned devices can connect to the internal network, even if an employee knows a valid username and password. How do you enforce this?

Dica: Which EAP method verifies the device's identity, not just the user's knowledge?

Ver resposta modelo

Deploy EAP-TLS. Configure the hospital's MDM solution to push a unique client certificate only to enrolled, corporate-owned devices. Configure the Cloud RADIUS policy to reject any authentication request that does not present a valid certificate signed by the trusted internal PKI, effectively blocking BYOD or rogue devices regardless of password knowledge.