Cloud RADIUS: the complete guide to RADIUS as a service

What is cloud RADIUS?

RADIUS stands for Remote Authentication Dial-In User Service. It is the protocol behind enterprise WiFi login. When a laptop joins a WPA2-Enterprise network, the access point does not decide who gets in. It asks a RADIUS server. The server checks the credential and answers accept or reject. The standard is defined in RFC 2865.

Cloud RADIUS moves that server out of your building. A provider operates it as a service. You stop buying, patching and replicating RADIUS servers. You still decide who may connect and on which terms.

Cloud RADIUS is the authentication engine inside a wider discipline: network access control. It works with the 802.1X standard, which controls access port by port on wired and wireless networks.

A cloud RADIUS service typically includes:

• The RADIUS servers, in more than one region, with failover built in.
• A certificate authority, so you can issue device certificates without running your own PKI.
• Identity connectors to Microsoft Entra ID, Google Workspace, Okta or Active Directory.
• Policy, such as which group lands on which VLAN.
• Logs and accounting, so you can show who connected, from which device and for how long.

Cloud RADIUS, hosted RADIUS server and RADIUS as a service: are they the same?

Not quite. The three terms describe different amounts of work you hand over.

The further down the table you go, the less your team operates. The search term varies, but buyers usually mean the second or third row.

How does cloud RADIUS work?

The flow is the same 802.1X exchange you know. Only the location of the server changes.

• A device asks to join. A laptop, phone or IoT device connects to an enterprise SSID or a switch port.
• The access point relays the request. It acts as the RADIUS client, also called the network access server.
• The request travels to the cloud. Ideally over RadSec on TCP port 2083, encrypted with TLS.
• The service checks the identity. It validates a certificate, a token or a credential against your identity provider.
• The service returns a decision. Accept or reject, plus attributes such as a VLAN or a role.
• The access point applies the decision. The device lands on the right network segment, or stays off it.
• Accounting records the session. Start, stop and duration are logged for audit.

The protocol choice in step three matters most. Classic RADIUS runs over UDP ports 1812 and 1813. It was built for trusted local networks. RadSec, defined in RFC 6614, wraps the same messages in TLS. That protects user names, device addresses and accounting data on the way to the cloud. We explain the difference in detail in RADIUS vs RadSec.

Which authentication methods can you run on cloud RADIUS?

Cloud RADIUS supports the same Extensible Authentication Protocol (EAP) methods as an on-premise server. What changes is which methods fit a cloud identity provider.

EAP-TLS is the strongest option. There is no password to phish or reuse, and TLS 1.3 support is standardized in RFC 9190. The cost is certificate management. A cloud RADIUS service with its own certificate authority removes most of that cost. Read EAP-TLS vs PEAP for the full trade-off.

Is cloud RADIUS secure?

Yes, if four conditions hold. Check each one with any provider before you sign.

The transport is encrypted. RadSec, or classic RADIUS inside a VPN tunnel. Plain RADIUS over the internet is not acceptable. In July 2024 researchers disclosed Blast-RADIUS (CVE-2024-3596). It showed that an attacker in the path can forge RADIUS accept messages over UDP. RadSec closes that path.

Clients validate the server. Every device must check the server certificate and its name. If it does not, an attacker can run a fake access point and collect credentials. Push this setting with your device management tool or the provider’s onboarding portal.

The provider can prove its controls. Ask for a SOC 2 Type II report or an ISO 27001 certificate. Ask which region stores your logs and for how long.

Access ends when employment ends. The service should revoke network access when a user is disabled in your identity provider. Manual offboarding is where most shared-password risk comes from.

NIST SP 800-153 gives a useful baseline for securing enterprise wireless networks.

What happens when a site loses its internet connection?

This is the strongest argument for keeping a local server. It deserves a direct answer.

If the RADIUS server sits in the same building, authentication works even when the internet link fails. With cloud RADIUS, the decision happens off site. Connected devices usually keep their session. New logins fail unless you plan a fallback.

Three fallbacks are common:

• Access point caching. Some vendors cache recent logins, so known devices reconnect during a short outage.
• A backup pre-shared key network. A second SSID used only when RADIUS is unreachable. It keeps people online with weaker security.
• MAC-based access for known devices. Convenient, but MAC addresses are easy to spoof.

Each option trades security for availability. Pick one per site type before go-live, and write it down. A retail store can accept a backup SSID. A clinic may not.

Who uses cloud RADIUS, and for what?

Cloud RADIUS is not only for large enterprises. The pattern is the same in every sector: many sites, few network specialists.

• Multi-site companies. Offices, branches and warehouses share one policy. A new site is a configuration change, not a server project.
• Retail and hospitality. Staff WiFi, point-of-sale devices and guest WiFi run on the same access points. Cloud RADIUS keeps staff and devices on separate segments from guests.
• Multifamily and student housing. Each resident gets a private key and a private network on shared infrastructure. Access starts at move-in and ends at move-out. See MDU WiFi.
• Education. Universities use RADIUS for eduroam, which lets students and staff roam between campuses with one identity.
• Coworking and flexible offices. Members join and leave every month. Access has to follow the membership, not a printed password.
• Managed service providers. One cloud service covers many customer networks, each with its own policy and logs.

In every case the driver is the same. The team wants enterprise-grade login without owning enterprise-grade infrastructure.

Cloud RADIUS or cloud NAC: which one do you need?

Most comparisons stop at the server. That is the wrong place to stop. A RADIUS server answers one question: can this device connect? Real access control needs answers to four more.

At Cloud4Wi we use a five-layer model to scope projects. It shows what each product category actually covers.

Layers one and two are table stakes. Layers three to five decide your daily workload. They cover contractor access that expires on its own. They cover a new laptop that onboards without an IT ticket. And they cover a leaver who loses WiFi at every site the moment HR disables the account.

If your problem is only “replace the Windows NPS server”, RADIUS as a service is enough. If your problem is “we still share one WiFi password”, you need all five layers. That is a cloud NAC problem.

When should you choose cloud RADIUS over an on-premise server?

Choose cloud RADIUS when you run several sites, mixed access point vendors or a small IT team. Keep a local server for a single well-staffed site, strict data residency rules or air-gapped networks.

The full decision guide, with cost, latency and data residency, is in cloud RADIUS vs on-premise. If you stay on premise, plan RADIUS high availability from day one.

How do you evaluate a cloud RADIUS provider?

Ask these ten questions. Vague answers are a warning sign.

• Which transports do you support: RadSec, RADIUS over a VPN, or plain RADIUS?
• How do you protect classic RADIUS against Blast-RADIUS?
• In which regions do you run servers, and how does failover work?
• Do you run the certificate authority, and who handles renewals?
• Which identity providers do you connect to, and how fast does a disabled user lose access?
• Which EAP methods do you support, and do you offer onboarding for unmanaged devices?
• Can policy assign VLANs or roles per group and per site?
• Which access point vendors have you tested, and do you need extra hardware?
• Where are logs stored, for how long, and which attestations can you share?
• Is pricing published, and what is the unit: user, device or site?

How does Cloud4Wi deliver cloud RADIUS?

Cloud4Wi includes cloud RADIUS in its platform. It covers the five layers of the model above. For credentials, onboarding is Passpoint-based today, with a clear path to certificate-based (EAP-TLS) authentication on the roadmap.

• Built-in cloud RADIUS for 802.1X. There is no external RADIUS server to deploy or maintain. Traffic uses RadSec where the access point supports it, and a hardened classic RADIUS path where it does not.
• No MDM enrollment. Employees sign in once with Microsoft Entra ID or Google Workspace and install a Passpoint profile. Every later connection is automatic, at every site.
• Policy by identity group. Each group lands on the right VLAN, everywhere.
• Contractor and visitor access. Sponsored, time-limited and fully logged.
• Automatic offboarding. When a status changes in your identity provider, access is revoked at every location.
• Your existing hardware. Aruba, Cisco, Extreme, Fortinet, Meraki, Mist, Ruckus and UniFi.
• Proof for auditors. SOC 2 Type II certification and a per-session audit trail.

The same platform runs guest WiFi and resident WiFi in more than 70,000 locations. Pricing is published, with plans from $200 a month and a 30-day trial that needs no credit card.

Cloud4Wi is not the right fit for every case. If you need deep endpoint posture checks on wired switch ports, a full enterprise NAC such as Cisco ISE may fit better. Our comparison pages show where other vendors are stronger.

How do you move to cloud RADIUS?

Most teams move in five steps. Run the new network next to the old one until the pilot is clean.

• Inventory. List access points, controllers, firmware and whether each supports RadSec.
• Connect identity. Link the service to your identity provider and map groups to VLANs.
• Pick methods. EAP-TLS or Passpoint for managed devices, PPSK or MAB for devices that cannot do 802.1X.
• Pilot one site. Create a new enterprise SSID pointed at the service. Test onboarding, roaming and the outage fallback.
• Roll out and retire. Push profiles to everyone, watch the logs, then switch off the old server and the shared password.

Our step-by-step guide to setting up a RADIUS server for WiFi authentication covers the access point side in more detail.