Radius as a Service Guide for Multi-Site Networks
Published
The hotel's guest network works, but the staff SSID has a different shared password at each property, a till has landed on the wrong VLAN, and no one can confirm whether a former contractor's device still has access. The network team can fix each issue locally, but the same work keeps returning across venues, floors, and access-point platforms.
RADIUS as a Service moves authentication decisions to a hosted platform while leaving access points, switches, and controllers to enforce them. That can simplify policy across a distributed estate, but it doesn't make the network independent of the WAN, identity provider, or certificate infrastructure. A sound evaluation starts with a harder question than whether the service has an SLA: what happens to each class of user and device when a dependency fails?
Table of Contents
- Why Centralising Network Decisions Changes Everything
- The Origins and Standards Behind Modern Hosted RADIUS
- How a RADIUS as a Service Architecture Actually Works
- Comparing Hosted RADIUS to On-Premises Deployments
- SLA, Multi-Region Failover and What Actually Breaks
- Security, Compliance and Migrating from Legacy RADIUS
- Choosing and Rolling Out a Hosted RADIUS Service
Why Centralising Network Decisions Changes Everything
A familiar pattern in a hotel chain is a guest SSID that has multiplied over time, staff credentials passed between teams, and switch ports configured according to whoever last worked on that floor. The problem isn't just configuration sprawl. It's that local devices hold pieces of the access policy, so a change at one property may not match the change at another.
RADIUS provides a way to centralise the decision. An access point or network access server sends an authentication request to a shared service, which checks identity and returns an access decision. The network device still enforces that decision, but the operator can manage identity and policy centrally instead of duplicating rules on every controller or switch.
That division is the core idea behind hosted RADIUS. A central service can return attributes that map a staff member, guest, contractor, or device to an appropriate network or VLAN. When someone leaves, a centrally managed identity can be revoked instead of relying on every venue to update local settings. Accounting records can also help operators investigate which identity used a network and when.
The pager still matters
Centralisation reduces some kinds of operational work, but it doesn't remove responsibility for network design. The hosted service can't correct an inaccurate identity record, an incorrectly mapped VLAN, or an access point that can't reach its configured endpoint. Nor does it automatically decide which devices should retain access when a branch loses connectivity.
For the person carrying the pager, the change is from maintaining local authentication servers and policies to managing the dependencies and failure behaviour of a shared service. That includes testing reachability, validating returned attributes, monitoring accounting, and agreeing what should happen during an outage.
Operational rule: Centralise routine policy, but make the failure policy explicit for every user and device group.
A guest's session, a staff laptop, a till, a camera, and a building sensor don't necessarily need the same fallback. Treating them as one generic “Wi-Fi” population can turn an authentication outage into either a business interruption or an avoidable security exception.
The Origins and Standards Behind Modern Hosted RADIUS
RADIUS began in 1991 after Merit Network requested a centralised authentication system for dial-up access to NSFNET. Livingston Enterprises built the first implementation for its PortMaster network access servers. The design decision that still shapes deployments was combining authentication, authorisation, and accounting in one client-server model instead of separate proprietary systems for each function. RADIUS history and protocol background
That split matters for more than compatibility. Because the NAS/authenticator split is fixed in the protocol, a WAN or identity-provider outage changes who can reach the shared server, not the roles themselves, which is why fallback design, not protocol choice, decides what happens at the venue.
The standards record shows how the model became interoperable. The IETF documented RADIUS in January 1997 as RFC 2058 for authentication and RFC 2059 for accounting. RFC 2138 and RFC 2139 superseded them later that year, followed by RFC 2865 and RFC 2866 in 2000. RFC 2865 refined the protocol after early deployments exposed problems at larger scale, a useful reminder that this specification was hardened by operational failure rather than drawn up clean. IETF RADIUS working-group documents
Why old standards still matter
For a hotel group or venue operator, the separation between access device and authentication server stays useful. A wireless controller from one manufacturer and switches from another can send requests to a common policy service, provided they implement compatible RADIUS behaviour. Centralised identity and access decisions become possible without buying one vendor's full access-control stack.
Port assignments show standards work affecting daily operations. Early implementations commonly used UDP port 1645, while UDP port 1812 became the formal assignment for authentication under RFC 2865. Equipment that still defaults to 1645 will fail against a hosted endpoint expecting 1812, so check what each device supports before configuring firewalls, regional endpoints, and migration plans.
Transport security is a current concern. RFC 6614 defines RADIUS over TLS, or RadSec, with TCP port 2083 as the default destination and integrity protection requirements. It also warns that TLS connection state and processing can create higher load than traditional UDP, so a secure design needs connection reuse, bounded retries, and capacity planning, not merely a new port. Treat that load warning as a failure-mode question: an endpoint that buckles when hundreds of access points reconnect at once after a WAN blip is worse than one that degrades gradually. RFC 6614 on RADIUS over TLS
The IETF's 2025 RFC 9813 documents operational considerations for TLS pre-shared keys and migration from RADIUS/UDP to RADIUS/TLS. That work is relevant when evaluating how a provider handles certificate or key management, proxy boundaries, and staged migration. IETF RADIUS standards and related work
How a RADIUS as a Service Architecture Actually Works
A hosted RADIUS design is easier to assess when you separate its three functions from its three planes. The functions are authentication, authorisation, and accounting. The planes are identity, transport, and reporting. A vendor pitch may package them together, but operators still need to know which component validates identity, which carries the request, and where session evidence ends up.
From connection request to network policy
When a user or device tries to connect, an access point or controller acts as the Network Access Server. It sends the request to RADIUS. The service checks the submitted identity or device credentials, often using a connected identity provider or a certificate trust arrangement, then returns an accept or reject decision.
An accepted request can carry authorisation attributes, such as VLAN assignment or other network parameters. The access point or controller applies those instructions. In a hotel analogy, the access point is the door attendant, the hosted RADIUS service is the identity directory, and the returned attributes are the wristband that determines which areas the person can enter.
The hosted service connects the identity plane to systems such as Entra ID, Okta, Google Workspace, a mobile-device-management platform, or a property-management system. The exact integration depends on the service and the access method. Do not assume a connector means every policy can be evaluated in the way your site requires. Test identity and device cases, including leavers, shared devices, and third-party tenants.
Accounting is not an optional extra
Accounting records session events and usage information independently of the initial authentication decision. Those records can support audits, capacity planning, chargeback, and investigations, including when another system performs part of the identity check. For multi-site operations, agree how to handle delayed updates, retransmissions, missing stop records, and regional endpoint failover.
The transport plane carries requests between the network device and RADIUS. Traditional RADIUS commonly uses UDP; RadSec uses TCP and TLS. The reporting plane collects authentication and accounting evidence so operators can review decisions rather than infer access from wireless-association logs alone.
When comparing services, map each component and data flow before signing. A useful companion is this guide to network access control solutions, particularly if RADIUS is one part of a broader policy and enforcement design.
Comparing Hosted RADIUS to On-Premises Deployments
Hosted and on-premises RADIUS speak the same protocol. Access devices remain Network Access Servers either way; what changes is who runs the shared authentication server and what sits between it and your venues. Operate it yourself and availability is an engineering problem in your server room. Buy it hosted and the same problem relocates to your WAN paths, identity chain, and certificate trust, none of which the provider owns on your behalf.
| Criterion | Hosted RADIUS | On-Premises RADIUS |
|---|---|---|
| Infrastructure work | Provider operates the hosted platform; your team still manages client configuration, policy, and integration. | Your team operates the server, software, operating system, monitoring, and recovery arrangements. |
| Multi-site policy | Central policy can serve equipment across locations, subject to connectivity and compatible implementations. | A central server or site-by-site deployment can work, but you own the replication and consistency model. |
| Network-device compatibility | Depends on supported RADIUS attributes, transport options, and the access devices you deploy. | You control the server configuration, but still need to validate behaviour across switches, controllers, and access points. |
| Transport security | RadSec support can protect the transport, with certificate management and TLS capacity to engineer. | RadSec can also be deployed locally, but your team manages certificates, connections, and scaling. |
| Failure ownership | Provider handles platform operations; your team must test WAN, identity, endpoint, and local fallback behaviour. | Your team controls local availability, but must design and maintain redundancy and recovery. |
| Cost shape | Often delivered as a service subscription; assess the contract and included operational scope. | May use existing infrastructure, but staff time, maintenance, and replacement remain your responsibility. |
Decide by failure mode, not by slogan
RFC 2865 codifies the separation between access device and shared authentication server (RFC 2865); hosted delivery changes where that server runs, not what role your switches, controllers, and access points play. So the useful question is identical for both models: when authentication becomes unreachable, what still works at the venue?
Use hosted when you can accept that a WAN path failure at a hotel or arena is your problem to solve locally, through survivable SSIDs, cached or fallback policies, and AP behaviour you have tested. Use on-premises when you can staff round-the-clock server operations and will own certificate rotation, patching, and redundancy. A locally managed server is not more resilient by default. I have audited plenty of single on-premises boxes running expired certificates and no failover, holding a network together through habit rather than design.
The deployment model decides less than the failure design around it.
Security posture follows implementation rather than location. Ask where shared secrets and certificates are stored, who can read accounting data, how requests are protected in transit, and how the service proxies requests it cannot answer itself. Tills, guest Wi-Fi, cameras, and IoT devices typically share one authentication path, so a weak point in either model tends to surface everywhere at once. If you are weighing a hosted platform against customer-operated infrastructure, a self-hosted RADIUS comparison helps frame which operating responsibilities you would retain.
SLA, Multi-Region Failover and What Actually Breaks
A provider's platform uptime, its RADIUS service commitment, and authentication availability at a particular venue are related but not interchangeable. A hosted platform can be healthy while one hotel cannot reach it because of a WAN or DNS failure. A venue can also reach RADIUS while its identity provider or certificate chain prevents successful authentication.
Grade the failure response by user and device
- WAN outage: New cloud authentications may fail. Existing sessions may continue, depending on local network behaviour and session policy. Ask whether local survivability has been tested on your access-point estate.
- DNS failure: Devices may not resolve service endpoints if their configuration depends on DNS. Confirm how endpoints are provisioned and what the access equipment does when resolution fails.
- Identity-provider outage: The RADIUS service may be reachable but unable to validate a new identity. Cached credentials can help, but they may also preserve access after a user's status changes.
- Certificate expiry or CA disruption: Certificate-based authentication can fail when a required certificate is invalid, expired, or untrusted. Certificate lifecycle monitoring must include the devices and trust chain involved, not just the RADIUS server.
- Management-plane outage: Operators may lose the ability to change policy or revoke access even if authentication continues. Establish how emergency changes are made and recorded.
A shared-password emergency SSID, MAC-based access, and cached credentials are not equivalent forms of resilience. Each trades immediate availability against security: shared keys are hard to target for revocation, MAC identifiers can be spoofed, and cached decisions can outlive the identity state they were meant to reflect.
Ask for a user-by-user failure policy: Should staff, guests, tills, cameras, residents, and IoT devices fail closed, use a limited local fallback, or continue on a previously authorised session?
Multi-region is a design input, not proof
Multi-region RADIUS endpoints can reduce dependence on a single service region, but the access devices need a workable way to reach and fail over between them. Verify whether the deployed access points and controllers retry automatically, how they choose an alternate endpoint, and whether a region loss requires manual intervention. Also test what accounting looks like during retransmission and recovery.
Before procurement, ask how long cached authentication remains valid, who can revoke emergency access, how often failover is exercised, and what evidence the provider can show from tests. For hotels and large venues, run the test with representative devices and services, not only a staff laptop. A useful outcome is a written failure matrix that names the affected population, expected behaviour, owner, and recovery action.
Security, Compliance and Migrating from Legacy RADIUS
Treat migration as a security project, not a change to a server address. A “secure RADIUS” claim can refer to several different things: protecting transport, authenticating network devices, validating user or device identity, or returning the correct authorisation. Those controls solve different problems.
RadSec uses TLS to protect RADIUS transport, and mutual certificate authentication can help ensure the server and the client device are trusted. But encryption alone doesn't guarantee the right user receives the right VLAN, or that a leaver's access is revoked promptly. Operators should also confirm how the service handles Message-Authenticator, replay and spoofing protections, proxy inspection, and accounting integrity when packets are retried or endpoints change.
Ask for evidence, not just assurances
When evaluating a provider, ask direct questions:
- Certificate management: Are certificates managed per customer, tenant, site, or network device? How are expiry and rotation monitored?
- Transport boundaries: Where does TLS terminate? Can intermediate proxies inspect or forward requests, and what protection remains end to end?
- Audit evidence: Can you review authentication decisions, policy changes, administrative access, and accounting records?
- Security posture: Which certifications does the provider hold, and what scope do they cover? If you require ISO 27001 or Cyber Essentials Plus, verify the current evidence and applicability rather than relying on a logo.
- Migration and rollback: Can the provider support a staged UDP-to-TLS transition, and what is the tested rollback path if an access-device model behaves differently?
A migration sequence should start with an inventory of RADIUS clients, identity sources, authentication methods, VLAN rules, shared secrets, certificates, and accounting consumers. Next, document the target policy and test it with representative identities and devices. Pilot a site, compare the returned decisions with the intended outcomes, then cut over service by service. Keep a rollback path until accounting and access behaviour are understood in production.
Compliance needs to follow the traffic and records your environment handles. For a practical network-control perspective, see this guidance on PCI compliance and Wi-Fi. The useful question is not whether a product claims compliance, but whether your deployment produces evidence for the controls your organisation must demonstrate.
A further risk sits between the protocol specification and the installed network. Security guidance can require checks that some access devices or proxies don't implement consistently. Ask vendors which controls they enforce, which ones depend on client firmware, and how they validate behaviour across your equipment.
Choosing and Rolling Out a Hosted RADIUS Service
Choose a provider by the failure behaviour and operating evidence you can verify, not by the cloud label alone. Confirm regional coverage, identity-provider support, per-tenant key management where needed, audit access, RadSec and certificate processes, and what happens when the contract ends.
Roll out in a controlled order: inventory current AAA and device dependencies; define identity-to-network policy; pilot representative sites and device types; cut over in stages; then validate access decisions and accounting against identity or property-management records. Track failed authentications, revocation handling, accounting reconciliation, and guest-network performance as operational signals, not as proof of resilience by themselves.
Purple Access offers hosted Cloud RADIUS alongside open, secure, and xPSK network options, with identity-driven access across existing access points. Evaluate it against the same failure tests, policy requirements, and evidence you'd request from any provider.
If you're planning a multi-site RADIUS rollout, map your WAN, identity, certificate, and local fallback dependencies before changing the authentication path. Visit Purple Access to review its Cloud RADIUS and network-access options for guest, staff, and device networks.
