Cloud RADIUS vs on-premise: a decision guide for IT teams

The question is not cloud versus on-premise. It is who runs the certificate authority.

Most “cloud RADIUS vs on-premise” comparisons argue about hosting. That is the wrong axis.

RADIUS authentication is not hard because a server is hard to host. It is hard because of what sits around the server. An identity source. A certificate authority. A renewal process. A person who understands the config.

Move the server to the cloud and none of that disappears on its own. Some of it transfers. Some of it stays with you. The real decision is which parts you keep and which parts a provider takes over.

So read this as a split-of-responsibility question, not a hosting question. That framing survives contact with production. The hosting framing does not.

What an on-premise RADIUS deployment actually costs

The license is the cheap part. FreeRADIUS is free. Windows NPS ships with the server. The cost is everything that keeps it running.

• The server, and a second one. One RADIUS server is a single point of failure, so you run a high-availability (HA) pair.
• OS patching. Two operating systems on the security-patch treadmill, forever.
• RADIUS software upgrades. FreeRADIUS and NPS both get security fixes. Someone tests and applies them without breaking a working config.
• The certificate authority. If you run EAP-TLS or PEAP, you run a CA. Issuing, signing, and revoking certificates is now your job.
• Certificate renewal. Server certificates expire. An expired one stops authentication. This needs monitoring and an owner.
• Monitoring. You need to know the server is up and accounting is being written — before a user tells you WiFi is down.
• The engineer who knows it. This is the hidden cost. In most organisations one person understands the setup. When they leave, the knowledge leaves with them, and the config becomes a thing nobody dares to touch.

That last line is the real total cost of ownership. Not the hardware. The single point of human failure.

What a cloud RADIUS service takes over — and what it does not

A cloud RADIUS service takes the operational layer. Be precise about the boundary, because this is where expectations break.

It takes over: the RADIUS server itself; the HA model and failover; OS and software patching; scaling as you add sites; certificate infrastructure, when the provider runs the CA.

It does not take over:

• Your identity source. Your users still live in Active Directory, Entra ID, or your identity provider. The service authenticates against it. It does not replace it.
• Your access point configuration. Each AP or controller still points at the service, with the right transport and settings.
• Your supplicant rollout. Client devices still need the trust anchor and server-name validation configured, or pushed by a management tool.

State this plainly. Cloud removes the operational burden. It does not remove the network design. A team that expects “cloud” to mean “nothing to configure” will be surprised at the AP and the client.

The transport question most comparisons omit

There is a dependency hiding inside every cloud RADIUS decision. The transport.

Plain RADIUS was built for a trusted LAN. A cloud service is not on your LAN. The authentication path now crosses the internet. Plain RADIUS on that path exposes usernames, device MAC addresses, and accounting records in cleartext, and exposes the shared secret to offline attack.

The fix is RadSec — RADIUS wrapped in TLS. It is the reason cloud RADIUS is safe to run at all. We cover the mechanics in RADIUS vs RadSec. For this page, one line matters: if a cloud RADIUS comparison does not mention the transport, it is incomplete.

Cloud RADIUS vs on-premise: side by side

The table is the centre of the decision. Two rows tend to settle it: behaviour when the WAN drops, and multi-site scaling. They usually point in opposite directions, which is why the answer is rarely universal.

Latency and the local-failure question

This is the strongest argument for on-premise, and it deserves a fair hearing.

If your RADIUS server is in the same building as your access points, authentication does not depend on the internet. The link to your ISP can drop and users still connect. That is a real advantage for a single site.

A cloud service moves the RADIUS decision off-site. If the WAN link fails, new authentications fail — unless there is a fallback.

• Local caching. Some access points cache recent successful authentications, so known devices reconnect during a short outage. New devices still cannot join.
• A fallback PSK SSID. A second network with a pre-shared key, used only when RADIUS is unreachable. It keeps people online, at a lower security level.
• MAC authentication bypass. Known device MACs are allowed through during an outage. Convenient, and weak — MACs are easily spoofed.

None of these is free. Each trades security for availability. The right question for a cloud provider is not “does it ever fail?” It is “what exactly happens to authentication when my WAN drops, and what is the security cost of the fallback?”

Data residency and compliance

RADIUS accounting data is personal data. It records who connected, from which device, to which access point, and for how long.

With an on-premise server, that data sits where your server sits. You control the location. With a cloud service, confirm three things before you sign: where accounting records are stored (which region, and whether you can choose it); how long they are retained, and whether you can set the period; what the provider can attest to (SOC 2, ISO 27001, and a data processing agreement that names the region and the retention).

Under GDPR, the location and retention of accounting data are your responsibility even when a processor holds it. An auditor will ask where the records live and who can access them. Have the answer before the audit, not during it.

When on-premise is still the right answer

• A single site with an existing team. One building, one server pair, an engineer who owns it. The cloud advantage is smallest here, and the local-failure advantage is largest.
• Strict data-residency rules. If regulation requires authentication data to never leave a specific location, an on-premise server is the simplest way to prove it.
• Air-gapped or OT networks. Operational technology and isolated networks often cannot reach a cloud service by design. RADIUS has to be local.
• A sunk investment with life left. A working HA pair, a team that knows it, years of service left — there may be no case to move yet.

When cloud RADIUS wins

• Multi-site estates. When every new location would otherwise be a new server project, a service that adds a site instead of a server changes the economics.
• No dedicated network security engineer. Moving the operational layer to a provider removes the single point of human failure.
• Mixed access-point vendors. A service that normalises authentication across vendors is simpler than maintaining vendor-specific server configs.
• Federated roaming. OpenRoaming and eduroam run on RadSec and cloud-scale identity.
• Growth. The model that does not turn each new site into a project wins on time-to-live alone.

Cloud4Wi’s Cloud NAC is a cloud RADIUS service of this kind. It provides built-in cloud RADIUS, reached over RadSec where the access point supports it, with a hardened classic-RADIUS path where it does not. Identity, segmentation, and compliance run as a service rather than on a server in your rack.

A decision checklist

Answer these eight questions. More “yes” means cloud.

• Do you run more than three sites, or plan to?
• Is RADIUS owned by someone who also owns many other systems?
• Do you run mixed access-point vendors?
• Would a new site otherwise require building a new server?
• Do you need federated roaming (OpenRoaming, eduroam)?
• Is your identity source already in the cloud (Entra ID, Google)?
• Do you lack a documented certificate-renewal owner today?
• Would losing your one RADIUS engineer put authentication at risk?

Five or more “yes” and a cloud RADIUS service is likely the lower-risk path. Mostly “no”, with a single well-staffed site, and on-premise is still defensible.