Migrating from On-Premises RADIUS (NPS) to RADIUS-as-a-Service

PODCAST SCRIPT: Migrating from On-Premises RADIUS (NPS) to RADIUS as a Service Duration: ~10 minutes | Voice: US English, Male, Senior Consultant tone --- SEGMENT 1: INTRODUCTION AND CONTEXT Welcome to the Purple WiFi technical briefing series. Today we're tackling a migration that's sitting on the roadmap of a significant number of enterprise IT teams right now: moving away from on-premises RADIUS - specifically Microsoft's Network Policy Server - to a cloud-hosted RADIUS as a Service model. If you're managing WiFi authentication across a hotel group, a retail estate, a stadium, or a public-sector campus, this is directly relevant to you. The on-premises NPS model has served us well for the better part of two decades, but the operational overhead, the single-point-of-failure risk, and the scaling limitations are becoming increasingly hard to justify - particularly when cloud-native alternatives now offer enterprise-grade reliability at a fraction of the total cost of ownership. Over the next ten minutes, we'll cover the technical architecture of both approaches, walk through a structured migration methodology, look at two real-world implementation scenarios, and finish with the key decision frameworks you need to make this call confidently. Let's get into it. --- SEGMENT 2: TECHNICAL DEEP-DIVE First, let's make sure we're aligned on what RADIUS actually does in your network stack. RADIUS - Remote Authentication Dial-In User Service - is the protocol defined in RFC 2865 that handles authentication, authorization, and accounting for network access. In a WiFi context, it's the backbone of IEEE 802.1X port-based access control. When a device connects to a WPA2-Enterprise or WPA3-Enterprise SSID, the access point acts as a RADIUS client - what we call a Network Access Server - and forwards the authentication request to the RADIUS server. The server validates the credentials, typically against Active Directory or an LDAP directory, and returns an Access-Accept or Access-Reject response. That's the fundamental flow. Now, in the on-premises NPS model - Network Policy Server is Microsoft's RADIUS implementation bundled with Windows Server - you're running that authentication logic on hardware you own, in a data center or server room you maintain. The NPS server holds your network policies, your certificate infrastructure for EAP-TLS or PEAP-MSCHAPv2, and your connection request policies. It works. It's mature. But it comes with a set of operational realities that compound over time. The first is hardware dependency. Your NPS server is a physical or virtual machine that requires patching, capacity planning, and eventual hardware refresh. In a multi-site deployment - say, a hotel group with properties across the US - you're either running a centralized NPS with WAN dependency, or you're deploying NPS instances at each site and managing them individually. Neither is elegant. The second is availability. A single NPS instance is a single point of failure for your entire authentication infrastructure. Yes, you can deploy NPS in a failover pair, but that doubles your hardware and licensing overhead, and it still doesn't give you the geographic redundancy that a cloud service provides natively. The third is scalability. NPS was designed for corporate LAN environments. When you're handling thousands of concurrent authentication requests during a stadium event or a convention center peak, the throughput limitations of a single NPS instance become very apparent. Authentication latency spikes, and users experience connection failures at exactly the moment you can least afford it. RADIUS-as-a-Service addresses all three of these constraints architecturally. The cloud RADIUS provider runs a distributed, geo-redundant cluster of RADIUS servers. Your access points point to cloud-hosted RADIUS endpoints rather than an on-premises server. Authentication requests are load-balanced across the cluster, and failover is automatic and transparent. The provider handles patching, capacity scaling, and certificate management. From your perspective as the network operator, RADIUS becomes a consumed service rather than a managed component. The authentication protocols themselves don't change. You're still running IEEE 802.1X with EAP-TLS, PEAP-MSCHAPv2, or EAP-TTLS depending on your client device mix. The difference is where the RADIUS server lives and who is responsible for its operational continuity. There's an important security consideration here that I want to address directly, because it comes up in almost every client conversation. Moving RADIUS to the cloud means your authentication traffic is traversing the public internet to reach the cloud RADIUS endpoint. This is mitigated through two mechanisms. First, RADIUS traffic between the Network Access Server and the RADIUS server is protected using a shared secret and MD5-based message authentication. Second, and more importantly for modern deployments, you should be running RadSec - RADIUS over TLS, defined in RFC 6614 - which wraps the entire RADIUS conversation in a TLS tunnel. This gives you transport-layer encryption equivalent to HTTPS, eliminating the MD5 vulnerability and providing mutual authentication between the NAS and the RADIUS server. Any cloud RADIUS provider worth considering should support RadSec as standard. On the identity integration side, cloud RADIUS services typically support LDAP and LDAPS connections back to your on-premises Active Directory, or native integration with Azure Active Directory and Entra ID via SAML or SCIM. This means you don't need to migrate your user directory - the cloud RADIUS service queries your existing identity store, maintaining your existing user lifecycle management processes. For compliance-conscious organizations - and that includes anyone handling payment card data under PCI DSS, or personal data under CCPA/CPRA - cloud RADIUS providers that are SOC 2 Type II certified and ISO 27001 accredited provide a stronger compliance posture than most organizations can achieve with self-managed NPS infrastructure. --- SEGMENT 3: IMPLEMENTATION RECOMMENDATIONS AND PITFALLS Right, let's talk about how you actually execute this migration without taking your authentication infrastructure offline. The methodology I recommend is a five-phase approach. Phase one is audit and inventory. Document every RADIUS client - every access point, every switch, every VPN concentrator - along with its current shared secret, the EAP method it's using, and any vendor-specific attributes in your NPS policies. This is the unglamorous work, but skipping it is the number one cause of migration failures. Phase two is pilot deployment. Stand up your cloud RADIUS instance and point a non-production SSID or a single test site at it. Validate that your EAP method works end-to-end, that your identity integration is functioning, and that your accounting data is flowing correctly. Phase three is parallel running. This is the critical risk mitigation step. Configure your access points with both the on-premises NPS server and the cloud RADIUS server as authentication targets, with the cloud service as primary and NPS as fallback. Run in this configuration for a minimum of two weeks across a full business cycle. Monitor authentication success rates, latency, and any policy discrepancies. Phase four is cutover. Remove the NPS fallback configuration and commit to cloud RADIUS as your sole authentication infrastructure. Do this during a planned maintenance window, and have a rollback procedure documented and tested. Phase five is decommission. Once you've validated stable operation for thirty days post-cutover, decommission the NPS servers and reclaim the hardware or virtual machine resources. The pitfalls I see most frequently are: certificate trust chain issues - specifically, client devices that don't trust the cloud RADIUS server's certificate because the CA isn't in their trusted store. Resolve this through your MDM or Group Policy before cutover. The second common pitfall is firewall rules. Cloud RADIUS requires outbound UDP 1812 and 1813 from your access points to the cloud endpoints, or TCP 2083 for RadSec. Ensure your network perimeter allows this traffic. Third: shared secret complexity. If your existing NPS shared secrets are weak, use the migration as an opportunity to rotate to cryptographically strong secrets, or better yet, move to RadSec and eliminate shared secrets entirely. --- SEGMENT 4: RAPID-FIRE Q&A Let me run through the questions I get most often on this topic. Can we keep Active Directory on-premises? Yes, absolutely. Cloud RADIUS connects to your on-premises AD via LDAPS. Your directory stays where it is. What happens if our internet connection goes down? This is the key dependency shift. With cloud RADIUS, internet connectivity becomes a dependency for authentication. Mitigate this with redundant WAN links or a local RADIUS proxy that caches authentication for known devices during outages. Does this affect our PCI-DSS compliance? Moving to a certified cloud RADIUS provider typically improves your compliance posture. Ensure your provider can supply SOC 2 Type II reports and is included in your annual QSA assessment scope. How long does a full migration take? For a single site, two to four weeks. For a multi-site estate of fifty or more locations, plan for three to six months with a phased rollout. - SEGMENT 5: SUMMARY AND NEXT STEPS To wrap up: the case for migrating from on-premises NPS to RADIUS-as-a-Service is compelling on operational, financial, and compliance grounds. The migration itself is low-risk when executed with a structured parallel-running phase. The key technical decisions are your EAP method selection, your identity integration approach, and whether to implement RadSec for transport security - which I'd strongly recommend for any new deployment. Your immediate next steps: conduct the audit of your current RADIUS clients and policies, engage your cloud RADIUS provider for a pilot environment, and review your firewall rules and certificate trust chains before you start. For organizations running Purple WiFi's guest access platform, the RADIUS-as-a-Service capability integrates directly with the guest WiFi authentication flow, giving you a single control plane for both corporate 802.1X authentication and guest network access management - with the analytics and compliance reporting built in. Thanks for listening. The full technical reference guide is available on the Purple website, and our solutions team is available for a scoping conversation if you're ready to move forward. - END OF SCRIPT