Blog

RADIUS high availability: active-active vs active-passive

By:

February 26, 2026

Last updated: October 9, 2026

SUMMARY.

When RADIUS goes down, nobody can join the network. High availability prevents that. But RADIUS failover is not a server cluster feature. The access point or controller holds an ordered list of servers and moves to the next one after a timeout. Active-passive is simpler but has a failover window. Active-active removes the window but splits session state. Without a shared store, that breaks accounting and Change of Authorization. Neither model is free. Test failover before you trust it.

What actually breaks when RADIUS goes down

When RADIUS is down, nobody can join the network. Not slower. Not degraded. Down.

Already-connected devices may stay on until their session key needs to refresh, and then they drop too. So high availability is not a nice-to-have for RADIUS. It is the difference between a working network and a dark one.

How RADIUS failover actually works

Here is the misconception this page exists to correct.

RADIUS failover is not a server-side cluster feature. It is a client-side behaviour. The access point or wireless controller holds an ordered list of RADIUS servers, each with a timeout and a retry count. It tries the first. If it does not answer in time, after the configured retries, it moves to the next.

So “RADIUS HA” is really a property of the network access server (NAS) configuration, not of the servers talking to each other. The servers usually do not know about each other at all. This matters because it changes where you design the redundancy: on the AP and controller, not only on the servers.

Active-passive

Active-passive is the common model. One server takes all authentication. The second sits idle, ready.

The failover window is the important number, and you can calculate it. It is roughly the per-server timeout multiplied by the retry count, for each server the NAS tries before it reaches a live one. With a 5-second timeout and 3 retries, a NAS can spend 15 seconds on a dead primary before moving to the secondary. During those seconds, new joins fail.

What is lost at failover: in-flight requests, and any session state the primary held that the secondary does not. Accounting for sessions that started on the primary may be incomplete.

The cost is simple and low. You run a second server that does nothing most of the time. In exchange you get a bounded, predictable failover window.

Active-active

Active-active runs both servers live. The NAS load-balances or round-robins across them. Both authenticate all the time.

The advantage is that there is no failover window. If one server dies, the NAS is already using the other, so requests simply keep going to the surviving node.

The disadvantage is shared state. When both servers are live and requests are spread across them, no single server has the full picture of every session. That is a real problem, and it is the next section.

The shared-state problem

This is the real technical content of the page. Authentication is stateless enough to spread across nodes. Everything after authentication is not.

Accounting sessions. A session’s Start can land on node A and its Stop on node B. Unless the nodes share a session store, neither has a complete record, and your accounting data is split.
Change of Authorization (CoA) and Disconnect. CoA (RFC 5176) is a message sent from the RADIUS server to the NAS to change or end a live session — for example, to push a user to a quarantine VLAN. In active-active, the CoA must come from the node that holds the session, or from a shared store. Send it from the wrong node and it references a session that node never saw. The CoA is dropped.

So active-active needs one of two things. Either a shared session database that both nodes read and write, or an accepted risk that CoA and accounting may be incomplete. There is no third option. Any active-active RADIUS design that ignores this is storing a problem for the first time you try to disconnect a user.

Active-active vs active-passive: side by side

Criterion	Active-passive	Active-active
Failover window	Timeout × retries × servers tried	None — both are live
Session state	Held on the active node	Split unless shared store
CoA / disconnect reliability	Simple — one node owns sessions	Needs shared state or accepts drops
Configuration complexity	Lower	Higher
Cost	A second, mostly idle server	Two working servers
Behaviour during maintenance	Fail over, patch the idle node	Drain one node, patch, return
Behaviour during a split	Predictable	Risk of both acting alone

Read the table as a trade. Active-passive is simpler and has a failover window. Active-active removes the window and adds a state problem. Neither is free.

Local authentication fallback

Redundancy protects against one server failing. What protects against all of them being unreachable — a WAN cut, a data-centre outage? Local fallback. Each option keeps people online, and each has a security cost you should state out loud.

Cached credentials. The access point lets recently authenticated devices reconnect during an outage. New devices cannot join. Low risk, limited coverage.
A fallback PSK SSID. A separate network with a pre-shared key, enabled only when RADIUS is unreachable. It keeps people online at a lower security level, and the key becomes a shared secret you now have to manage.
MAC authentication bypass. Known device MACs are allowed through with no authentication. Convenient during an outage, and weak — MAC addresses are trivially spoofed.

Choose the fallback deliberately, and document what security you are trading for availability. Do not let it be a default nobody decided.

How a cloud RADIUS service handles this

With a cloud RADIUS service, the HA model becomes the provider’s problem. You do not build the pair, calculate the failover window, or run the shared session store.

That is an advantage, but only if you verify it. Ask the provider to prove three things: the redundancy model and the measured failover behaviour — not the diagram, the number; how CoA and disconnect are handled across their nodes, so policy changes and quarantine still work; what happens to your sites when the WAN drops, and what local fallback they support.

We compare the wider trade-off in cloud RADIUS vs on-premise. Cloud4Wi’s Cloud NAC runs the redundancy as a service, so a new site is not a new HA project.

Testing your failover — a procedure

You do not have HA until you have tested failover. A diagram is not a test. Run this.

Baseline a successful authentication. Confirm a known device authenticates normally, through the primary.
Capture the timings. Note the configured timeout and retry count on the NAS, and calculate the theoretical worst-case failover window.
Kill the primary. Stop the primary RADIUS server, or block it at the firewall.
Measure the actual failover window. Time how long a new authentication takes to succeed via the secondary. Compare it to your theoretical number. They should be close; if they are not, your timers are wrong.
Verify accounting continuity. Confirm that session records for the failed-over sessions are complete, or understand exactly what was lost.
Verify CoA. Trigger a Change of Authorization during the failover state and confirm it reaches the session. This is where active-active designs fail quietly.
Restore and re-verify. Bring the primary back. Confirm the NAS returns to it as configured, and that no sessions were orphaned.

Run this before production, and again after any change to the server list or timers.

Recommendation by estate size

Single site. Active-passive. One live server, one standby, a bounded failover window. Add a local fallback for a total outage. Do not add active-active complexity you do not need.
2–20 sites. Active-passive per region, or a cloud RADIUS service. At this size the operational cost of running and testing HA across sites starts to outweigh the control.
20+ sites. A cloud RADIUS service in most cases. Building, testing, and maintaining HA and shared state across twenty-plus sites is a full-time job. Make it the provider’s job, and verify it with the test procedure above.

Frequently asked questions

By the access point or controller. The network access server holds an ordered list of RADIUS servers with a timeout and retry count, and moves to the next server when one stops answering. The RADIUS servers usually do not coordinate with each other. So failover is a client-side behaviour you configure on the NAS, not a cluster feature of the servers.

Multiply the per-server timeout by the retry count, for each dead server the NAS tries before reaching a live one. A 5-second timeout with 3 retries is 15 seconds per dead server. During that window, new authentications fail. Lower the timeout and retries to shrink the window, but not so far that a slow-but-alive server is wrongly marked dead.

They can run, but accounting and CoA will be unreliable. A session can start on one node and stop on the other, splitting the record, and a Change of Authorization sent from the wrong node references a session it never saw. Without a shared session store, you accept incomplete accounting and dropped CoA. For correct behaviour, active-active needs shared state.

Usually nothing immediately — an established session keeps running on the access point. The problem appears at the next event that needs RADIUS: a key refresh, a roam to another access point, or a reconnect. At that point the client re-authenticates, and if no server answers, it drops. This is why failover must be fast enough to cover normal roaming.

It is a reasonable safety net, with a cost. A fallback pre-shared-key SSID keeps people online during a total RADIUS outage, but it authenticates everyone with one shared key, at a lower security level. Enable it only as a fallback, document who can use it, and make sure it cannot become the everyday network. Weigh the availability gain against the weaker security.