If you’re an ISP network engineer questioning whether your current RADIUS setup, FreeRADIUS, Cisco CPAR, or another commercial system, is adequate for where your network is going, this self-assessment gives you a structured, vendor-neutral answer. Score 7 diagnostic signs using Yes (2 pts), Maybe (1 pt), No (0 pts), then total your score. If you score 4 or below, RADIUS server replacement for ISPs is not your immediate priority; if you score 10 or above, a migration plan is overdue and delay is compounding the risk.
Why 2026 Is the Year ISPs Need to Answer This Question
Two forces are narrowing the window for “we’ll deal with it later.”
FreeRADIUS configurations that worked at lower network complexity have become progressively harder to maintain as fixed-wireless, FTTH, and 5G fixed-wireless access add protocol requirements that older setups weren’t designed for. Separately, Cisco CPAR has reached end of life across all active versions with TAC support ending October 31, 2025 — placing ISPs that relied on it into a migration that is no longer optional. Together, these make 2026 the year to assess, not defer.
How to Use This Self-Assessment
Seven diagnostic signs. Score each one:
- Yes = 2 points
- Maybe / Not Sure = 1 point
- No = 0 points
Add up your score when you’re done. The interpretation table after Sign 7 tells you what your total means and the specific next step for your situation.
Sign 1 — Your RADIUS Is Struggling to Scale with Subscriber Growth
What to look for: authentication request queue depth during peak hours, session setup latency that has grown noticeably over the past 12 months, or any capacity incident where RADIUS was the bottleneck or the prime suspect.
FreeRADIUS is technically capable at high transaction volumes when properly tuned, but tuning at scale is non-trivial. The problems tend to arrive incrementally: authentication latency climbing during evening peaks, occasional BRAS timeouts, a periodic service restart after a memory growth event. None of these constitutes a disaster individually. Together, they signal a system being operated close to its ceiling.
From the field: When we talk to ISP network engineers who are evaluating a RADIUS server replacement, the warning sign they most commonly describe is not a single catastrophic failure it’s the accumulation of small incidents over 12–18 months that make the team reluctant to touch the configuration. The system works until it doesn’t, and diagnosing where the bottleneck sits under live production load with limited visibility tooling — is extremely difficult.
Score this sign:
| Response | Score |
|---|---|
| Yes — you’ve had a capacity-related incident, or authentication latency spikes consistently during peak periods | 2 pts |
| Maybe — you’ve noticed performance degradation but haven’t had a hard incident yet | 1 pt |
| No — your RADIUS has never come close to a scaling limit | 0 pts |
Sign 2 — Maintaining Your RADIUS Has Become a Specialist Dependency
FreeRADIUS is powerful, configurable, and genuinely difficult to operate at scale without someone who has invested years learning how the configuration hangs together. The RADIUS dictionary, the unlang policy engine, the realm routing logic — none of it is intuitive to inherit. When the engineer who built your configuration leaves, what happens?
This sign is not about feature gaps. It’s about operational resilience. ISPs running FreeRADIUS at high subscriber volumes often find that only one or two engineers understand the configuration at a level where they can safely modify it or diagnose a novel failure under pressure. That fragility doesn’t show up in uptime metrics — until it does.
Refer to the FreeRADIUS documentation for a sense of the expertise required to operate the platform at production scale.
From the field: When we talk to ISP engineering teams considering a RADIUS replacement, one of the most common triggers for the conversation is an impending departure or a team restructuring. An engineer who has maintained the FreeRADIUS setup for several years announces they’re leaving and suddenly the team realizes the institutional knowledge leaves with them. The remaining staff can keep the system running under normal conditions but have limited ability to safely extend the configuration or diagnose edge cases they haven’t encountered before.
Score this sign:
| Response | Score |
|---|---|
| Yes — only 1–2 people deeply understand your RADIUS configuration, or that person has already left | 2 pts |
| Maybe — your team can operate it day-to-day, but new use cases require significant research and caution | 1 pt |
| No — RADIUS expertise is distributed across your team with solid documentation | 0 pts |
Sign 3 — You’re Running Cisco CPAR (or Were Until Recently)
This sign scores differently from the others. If Cisco CPAR is your current AAA platform or if you’ve been running CPAR-adjacent equipment and haven’t resolved what comes next the migration is not optional. Only the timeline is negotiable.
Cisco’s EOL timeline for Prime Access Registrar 9.0 (the most widely deployed version) is unambiguous: end-of-sale was October 29, 2023; software maintenance releases ended October 28, 2024; and Cisco TAC support ended entirely on October 31, 2025. As of the publish date of this article, ISPs still running CPAR are operating on infrastructure with no vendor support, no security patches, and no escalation path. See Cisco’s official EOL notice for CPAR 9.0 for the complete milestone table.
Regulatory and compliance frameworks increasingly require active vendor support for infrastructure components. Running fully unsupported AAA creates an audit exposure that most ISPs cannot accept and that will not get easier to explain as time passes.
If you’re on CPAR, the question is not whether to migrate, it’s to what, and by when. Alepo’s CPAR migration page covers the practical transition path.
Score this sign:
| Response | Score |
|---|---|
| Yes — CPAR is currently running in production | 2 pts |
| Maybe — CPAR runs in a secondary or backup role, or you’ve started migration but haven’t completed it | 1 pt |
| No — you’ve never run CPAR, or you’ve already completed a full migration away from it | 0 pts |
Sign 4 — You’ve Had Authentication-Related Outages in the Last 12 Months
An outage is the clearest signal. But don’t limit your count to full outages.
Also count: degraded authentication performance during storm events or maintenance windows, subscriber-facing login failures that generated a support ticket wave, or any planned maintenance window that ran significantly over because of unexpected RADIUS behavior.
The 12-month review window matters because authentication incidents fade from institutional memory quickly. An 80-minute authentication degradation that was resolved and closed in a post-incident report still belongs in your score. RADIUS problems that are solvable are still a warning sign about the operational fragility of the current setup. In residential broadband markets, subscriber tolerance for authentication failures is low — and the subscriber-minutes of disruption that accumulate during an authentication event represent a real cost, whether or not they appear in a loss report.
Score this sign:
| Response | Score |
|---|---|
| Yes — one or more authentication-related outages or near-misses in the last 12 months | 2 pts |
| Maybe — subscriber-facing performance degradation, but nothing that escalated to a formal incident report | 1 pt |
| No — zero authentication incidents in the last 12 months | 0 pts |
Sign 5 — Your RADIUS Can’t Support the Protocols Your Network Is Moving To
RADIUS — standardized in IETF RFC 2865 and published in 2000, was designed for a network environment that predates 4G, 5G, and current Wi-Fi offload architectures. The protocol has been extended substantially over the years, but there are real limits to how far extensions take you.
If your network roadmap includes any of the following in the next 24 months, your current RADIUS setup needs scrutiny:
- 5G Standalone core: 5G SA authenticates data sessions over Diameter — specifically the S6b and SWx interfaces for Wi-Fi interworking. Native RADIUS does not address this requirement.
- EAP-TLS or EAP-TTLS for enterprise Wi-Fi security: Certificate-based EAP methods require full EAP support. FreeRADIUS supports them, but correct implementation and ongoing maintenance demand deep expertise.
- Wi-Fi calling and offload: Requires EAP-SIM or EAP-AKA, which adds meaningful configuration complexity to any FreeRADIUS deployment at scale.
- Dynamic policy enforcement via CoA: Change-of-Authorization for mid-session subscriber profile modification is supported in FreeRADIUS, but policy complexity grows the maintenance burden considerably.
The honest question: what does your AAA architecture look like on the other side of a fixed-wireless expansion, an MVNO launch, or a 5G SA trial? Protocol gaps that require workarounds today tend to require a forklift upgrade later. For a deeper comparison of these protocols and when they apply: RADIUS vs. Diameter vs. TACACS+ — Key Differences in CSP Environments.
Score this sign:
| Response | Score |
|---|---|
| Yes — your network roadmap includes protocols or use cases your current RADIUS cannot natively support | 2 pts |
| Maybe — you haven’t finalised your protocol roadmap, but significant expansion is planned | 1 pt |
| No — your network is stable and protocol-complete for current use cases, with no major expansion planned | 0 pts |
Sign 6 — Your Team Spends More Time Maintaining RADIUS Than Improving the Network
This is the opportunity cost question, and the one most teams undercount because maintenance hours don’t appear on a project board.
Look at the last 90 days: how many senior engineering hours went into RADIUS maintenance configuration updates, certificate renewals, troubleshooting authentication failures, patching, writing documentation for the next person? Now compare that to hours spent on network improvement: capacity expansion, new service enablement, monitoring tooling.
If the ratio feels wrong, quantify it. The threshold that tends to prompt a serious conversation is when RADIUS maintenance consistently consumes more than 15–20 hours per month of senior engineering time without delivering visible service improvement. At that point, the team is paying for stability, not capability and the gap compounds as the network grows.
FreeRADIUS maintenance at high subscriber volumes is genuinely time-intensive. This is not a criticism of the software it is an accurate description of what it costs to operate a highly configurable, complex system in a production environment where every change requires careful testing and a proven rollback plan.
Score this sign:
| Response | Score |
|---|---|
| Yes — RADIUS maintenance is consuming senior engineering time at a rate that is displacing higher-value work | 2 pts |
| Maybe — maintenance is manageable but growing; it takes noticeably more time now than 18 months ago | 1 pt |
| No — RADIUS maintenance is a small, predictable, bounded operational task | 0 pts |
Sign 7 — You Have No Clear RADIUS Roadmap for the Next 3 Years
The most strategic sign on the list, and the one most commonly skipped in the daily operational grind.
If you cannot answer this question clearly, score this sign as Yes: What does your authentication infrastructure look like in 2028, and how does it support the network services you plan to offer?
A defensible AAA roadmap covers: protocol requirements for each planned network expansion, a redundancy and availability architecture for the subscriber base you expect to be serving, a staffing plan for the operational expertise required, and a succession plan if a key team member leaves.
ISPs with aggressive growth plans — fixed-wireless buildout, MVNO launch, public Wi-Fi deployment are most exposed when this roadmap is absent. Infrastructure decisions are considerably more manageable when made before a network project begins than during the scramble to get services live on deadline.
Score this sign:
| Response | Score |
|---|---|
| Yes — no documented RADIUS roadmap; the 3-year picture has not been thought through | 2 pts |
| Maybe — rough plans exist but nothing formalised or reviewed | 1 pt |
| No — you have a documented AAA roadmap reviewed in the last 12 months | 0 pts |
How to Interpret Your Score
| Score | Status | What It Means | What to Do Next |
|---|---|---|---|
| 0–4 | Monitor | Your RADIUS setup is likely adequate for your current operational context. | Document your current configuration and its coverage. Schedule a reassessment for Q1 2027 — or revisit sooner if your network expansion plans change. |
| 5–9 | Plan | You have genuine warning signs. Your current setup may serve you for 12–18 months, but don’t wait for an incident to force the decision. | Start building your evaluation framework now. How to Evaluate an AAA Platform for Your ISP gives you an objective set of criteria before any vendor conversation starts. |
| 10–14 | Act | You are already experiencing the pain, or your network trajectory will surface it within months. Under structured conditions, ISP AAA migrations take 3–9 months from kick-off to live cutover. Starting now means being operational on a replacement before the next major incident — not after it. | Begin shortlisting vendors this quarter. Use the evaluation framework above. Then schedule a technical assessment of your specific setup. |
If your score is 10–14: the right next step is a technical conversation about your specific setup — not a vendor presentation.
Get a RADIUS health assessment from Alepo
Our engineering team reviews your current AAA architecture and tells you honestly what your options are, including whether migration makes sense for your situation and what a realistic timeline looks like.
If Your Score Says It’s Time to Replace — What Are Your Options?
The replacement landscape is worth understanding clearly before you start shortlisting vendors.
FreeRADIUS remains a viable option for ISPs with strong in-house Linux engineering capability and a stable, well-understood protocol footprint. If you’re currently on a commercial RADIUS — including CPAR — and considering a move to FreeRADIUS, be clear-eyed about the trade-off: you’re exchanging a commercial support relationship for engineering time. That’s a reasonable decision if your team has the depth for it. Many ISPs in that position find, on honest reflection, that they don’t particularly once they account for the full operational cost of running a complex FreeRADIUS deployment over three to five years.
Open source alternatives to FreeRADIUS exist but most are less mature for broadband ISP use cases. FreeRADIUS remains the dominant open source option in this segment.
Commercial AAA platforms — including Alepo, Enea, Krontech, and Radiator Software offer vendor-managed support, more structured migration paths, and typically broader protocol coverage. The trade-off is cost. The honest evaluation question is: how does the commercial licence cost compare to the full engineering cost of operating FreeRADIUS at your subscriber scale and network complexity? For ISPs in active network expansion, this comparison often shifts toward commercial but the right answer depends on your specific team, setup, and trajectory.
Frequently Asked Questions
1: What is the difference between RADIUS and AAA?
AAA stands for Authentication, Authorization, and Accounting, the three functions that govern who can access your network (authentication), what they’re permitted to do once connected (authorization), and how their usage is recorded for billing and compliance (accounting). RADIUS is one protocol for implementing AAA, and the most widely used for broadband ISP subscriber authentication. It is, however, one piece of a broader AAA architecture. Modern commercial platforms handle RADIUS alongside Diameter and TACACS+ on a single stack — which matters when your network needs to support multiple access types simultaneously without running separate AAA systems for each.
2: Is FreeRADIUS suitable for a large ISP?
FreeRADIUS is technically capable at large transaction volumes, but technical capability is not the same as operational suitability. ISPs running FreeRADIUS at high subscriber volumes consistently find that engineering overhead grows faster than subscriber growth. The question is not whether FreeRADIUS can handle the authentication load in isolation — it can, when correctly tuned — but whether your team can maintain, safely extend, and debug the configuration without deep specialist expertise. For ISPs with strong Linux engineering capability and a stable protocol footprint, FreeRADIUS can work. For ISPs in active network expansion, the operational burden tends to become a material constraint.
3: How long does a RADIUS server migration take?
Under structured conditions — a phased parallel-run approach, solid documentation of the existing configuration, and a vendor with migration tooling, most ISP AAA migrations complete in 3–9 months from kick-off to live cutover. The range reflects ISP-specific variables: the complexity of your realm configuration, the number of access types in scope, the availability of a test environment, and whether you’re migrating a subscriber profile store or integrating with an existing HSS or UDM. The worst migrations happen when ISPs start under pressure — after an incident or against a hard deadline — without parallel infrastructure. Starting early is the single most controllable variable in the outcome.
4: What are the alternatives to Cisco CPAR after end of life?
The primary options evaluated by CPAR operators are commercial AAA platforms (including Alepo, Enea, Krontech, and Radiator Software) and open source options (primarily FreeRADIUS). CPAR operators typically have broadband BRAS/BNG and enterprise TACACS+ use cases — confirm that any candidate replacement covers both. Not all commercial AAA platforms support TACACS+ natively; make this an explicit evaluation criterion. Alepo’s CPAR migration page covers the practical transition path in detail.
5: Can I migrate from FreeRADIUS without a subscriber outage?
Yes, with the right architecture and sufficient planning lead time. The standard approach is a parallel-run phase: the new AAA platform runs alongside FreeRADIUS with traffic progressively shifted starting with test subscribers, then a portion of live traffic, then full cutover. This requires your BRAS or BNG to route authentication requests to multiple AAA targets simultaneously, which most modern edge platforms support. The risk window is the final cutover, which should be scheduled during a low-traffic period with a tested rollback plan in place. A zero-subscriber-impact migration is achievable — it requires planning time, not heroics.
Ready to Talk About Your Specific Setup?
If your score came back at 10–14, or if you’re on Cisco CPAR without a clear migration path, the right next step is a technical conversation.
Alepo’s engineering team reviews your current AAA architecture and gives you an honest picture of your options — including whether migration makes sense for your situation and what a realistic timeline looks like.
