When you compare the best AAA platforms for ISPs — or are scoping a RADIUS server replacement — the spec sheet is the least reliable thing in the room. Stated capacity, protocol checkboxes, and licence price tell you almost nothing about whether a system survives a Friday-night authentication storm or a botched migration. The eight criteria below are the ones that decide whether your subscriber authentication platform holds up in production: peak-load behavior, real uptime, protocol roadmap, migration safety, integration depth, true total cost of ownership, AI-readiness, and vendor viability. A 99.999% SLA, for context, is roughly five minutes of downtime a year, and most evaluations never test what actually happens during those five minutes. This is a “help me build my criteria” guide, not a vendor pitch. Use it to walk into your RFP knowing what to ask and what to distrust.
What is an AAA platform, and why does it matter for ISPs?
AAA stands for Authentication, Authorization, and Accounting: the system that decides whether a subscriber is who they claim to be, what they’re allowed to do, and how their usage is recorded for billing and policy. For an ISP, the AAA platform sits on the critical path of every session. When a customer’s router comes online, the AAA either lets them on the network or doesn’t.
That single dependency is why this decision carries more operational weight than its budget line suggests. A billing bug is an invoice problem; an AAA failure is an “every subscriber in the region is offline” problem. Whether you call it an AAA platform for ISP use, ISP authentication software, network authentication software for ISPs, or a subscriber authentication platform — the products you’ll compare are all sold on similar feature lists. The differences that matter only show up under load, during migration, and three years into the contract.
Here are the eight AAA server evaluation criteria worth scoring vendors against.
Criterion 1: Can it handle your real-world peak load?
Every vendor will quote a peak transactions-per-second number. Treat it as marketing until you’ve reproduced it under your traffic shape. Stated capacity is measured in a clean lab with synthetic, evenly distributed requests — your network does not behave that way.
Residential broadband traffic is bursty and clustered. Authentication and accounting load spikes hard in the early evening when households come online at once, and again after any regional outage, when every CPE in the affected area tries to re-authenticate within the same few minutes. In our deployments supporting multi-million-subscriber broadband networks, we’ve repeatedly seen authentication request volume hit 8–12x baseline during these bursts. A platform that comfortably handles steady-state load can fall over at the burst, because the failure mode is queue backpressure and session-table contention, not raw throughput.
Deployment observation: The single most under-tested scenario in vendor evaluations is the post-outage re-authentication storm. The systems that degrade gracefully — shedding load predictably and recovering without manual intervention — are a different class from the ones that hit a cliff. When scoping any evaluation, validate behavior at 8–12x average load with a cold session cache, not just at sustained steady-state throughput.
Criterion 2: What does “99.999% uptime” actually mean in production?
“Five nines” is the most quoted and least examined number in AAA sales. Decode it: 99.999% availability is about 5 minutes of downtime per year. By contrast, 99.9% — which sounds almost as good — is nearly nine hours. The gap between those two SLAs is the gap between a non-event and a customer-churning incident.
But the SLA number is only a promise about aggregate availability. The real questions are architectural. How is failover handled: active-active or active-passive? In active-passive, what is the actual failover time, and do in-flight sessions survive it or get dropped? Is redundancy geographic, so a single data-centre failure doesn’t take authentication down for a whole region?
Deployment observation: An ISP that has lived through an AAA outage never needs this criterion explained. New subscribers can’t get online, existing sessions may re-authenticate and fail, and the support queue floods within minutes. Push the vendor past the SLA percentage: ask for the failover mechanism, the measured failover time, and whether their reference customers run active-active across sites.
The right answer isn’t a high number on a slide. It’s an architecture where no single component failure becomes a subscriber-facing outage.
Criterion 3: Does it support RADIUS, Diameter, and what’s coming for 5G?
Protocol support looks like a checkbox exercise — it isn’t. The real question is whether the platform can evolve across protocol generations without a forklift replacement three years from now.
RADIUS (RFC 2865) remains the workhorse for fixed broadband and Wi-Fi authentication. Diameter is the equivalent for 4G/LTE and carries the Gx/Gy interfaces to policy and charging. If you operate or plan to operate mobile or converged services, you need both on one platform, not bolted together.
For 5G, the architecture shifts. The 5G core introduces service-based authentication functions — the AUSF, UDM, and ARPF defined in 3GPP TS 33.501 — using 5G-AKA and EAP-AKA′ over HTTP/2-based interfaces rather than classic RADIUS/Diameter. Notably, the same spec defines how an external AAA server performs primary authentication for standalone non-public (private 5G) networks, an increasingly common ISP and enterprise-services play. Non-3GPP and Wi-Fi interworking, by contrast, authenticate over Diameter S6b and SWx — the EPC-era interfaces that remain in service for operators running mixed 4G/5G footprints.
So the question to a vendor isn’t “do you support 5G?” It’s this: show me your published 5G roadmap, which functions you implement today, and how a RADIUS/Diameter deployment migrates onto it incrementally. A claims page is not a roadmap. For the practical sequencing of all this, our breakdown of RADIUS, Diameter, and TACACS+ differences is a useful primer.
Criterion 4: How painful is the migration from your current system?
Almost no ISP runs a RADIUS server replacement from a standing start. You’re migrating from something — a FreeRADIUS estate that’s become painful to maintain at scale, an aging commercial RADIUS from a vendor that stopped investing, or, very commonly right now, Cisco Prime Access Registrar (CPAR). Cisco took its last CPAR release end-of-sale in late 2023 with no successor product, which is why Cisco CPAR end-of-life planning is one of the most active conversations in the AAA market today.
Migration is where good evaluations get won — because it’s where bad projects create outages. Three questions separate a structured vendor from a risky one:
Dual-stack / parallel-run support. Can the new platform run alongside the old one, with subscribers cut over in controlled batches rather than a single big-bang switch?
Data migration tooling. Is there real tooling to move subscriber profiles, credentials, and policy — or is it a services project with a spreadsheet?
Rollback. If batch three goes wrong at 2 a.m., can you roll those subscribers back without affecting the ones already migrated?
A vendor without a documented migration methodology will, in practice, manufacture an outage window. Structured migrations typically run 3–9 months depending on subscriber base and the number of integrated systems. A vendor quoting two weeks either hasn’t done one at your scale or is leaving the risk on your side of the table.
Replacing CPAR or a legacy RADIUS estate? Alepo’s CPAR end-of-life migration approach is built around dual-stack cutover and rollback specifically to avoid that outage window. Talk to an Alepo AAA specialist for a free assessment of your current setup.
Criterion 5: How does it integrate with your BSS and policy engine?
AAA never operates alone. It authenticates against subscriber data that lives in your BSS, it enforces plans defined in your policy/PCRF layer, and it feeds usage records back for billing. An AAA platform that’s excellent in isolation but integrates poorly becomes the bottleneck for every plan change and every new service launch.
Ask which BSS and PCRF/PCF systems the platform integrates with natively — meaning in production at a reference customer, not “supported in principle.” Ask about the interface standards on offer: Diameter Gx/Gy for policy and charging, plus modern REST APIs for provisioning and orchestration, and whether legacy SOAP is still required anywhere in the path.
A strong signal of integration maturity is alignment with the TM Forum Open APIs. Vendors who’ve done the work to conform to those standards tend to integrate into a mixed BSS/OSS estate in weeks rather than quarters, because you’re not paying for a bespoke connector every time. Where you see only proprietary interfaces, budget for the integration tax.
Criterion 6: What is the true total cost of ownership?
Licence or subscription cost is the number everyone compares, and it’s typically only 30–40% of the real total cost of ownership. The rest is where the surprises live. A fully loaded AAA TCO model should include:
- Implementation and migration. Often a significant one-time cost, especially with legacy data.
- Ongoing engineering time. The internal headcount needed to operate, patch, and tune the system. This is the line that quietly dominates over a five-year horizon.
- Support quality, not just support existence. Ask for contractual response-time SLAs by severity. “24/7 support” with a four-hour P1 response is not the same product as one-hour.
- Infrastructure. Hardware or cloud, plus the redundancy you costed in Criterion 2.
This is exactly where FreeRADIUS deserves an honest, line-by-line look. It is genuinely free to license, and for smaller or stable deployments it’s a reasonable choice. But “free” is a licensing fact, not a TCO fact: at ISP scale, the cost reappears as senior engineering time spent on configuration management, custom module maintenance, scaling work, and carrying the on-call risk yourself. A fair evaluation prices that in — rather than comparing a licence fee against zero.
Criterion 7: Is it AI-ready for agentic network operations?
This is a two-to-three-year-horizon criterion, which is exactly why it belongs in the evaluation now. AAA platforms have long lifecycles, and a system you can’t automate against will become a replacement candidate before its contract is up.
Forward-looking ISPs are starting to put AI agents to work in network operations: automated anomaly and fraud detection on authentication patterns, dynamic policy adjustment, and session analytics that surface problems before the NOC sees them. None of that is possible if the AAA is a black box. The practical test: does the platform expose clean, well-documented APIs and stream the telemetry — per-session events, auth outcomes, latency, accounting data — that an automation or AI layer needs to act on?
This is the direction the market is heading, toward AI agents for network operations that read AAA telemetry and act on it in near real time. You don’t need that capability switched on at signing. You do need to confirm the data and APIs are there, so the door stays open without another forklift upgrade.
Criterion 8: How do you assess vendor viability?
Your AAA platform is critical infrastructure with a multi-year horizon. A vendor that gets acquired and sunset, or simply stops investing, hands you a second migration you didn’t budget for. That’s the precise situation now pushing CPAR and abandoned-commercial-RADIUS customers to evaluate again. Viability is a technical risk — not just a procurement nicety.
Score vendors on concrete signals rather than vibes:
- Track record at your scale. Customer count and, critically, reference-ability: will they put you on a call with an operator of similar size and architecture?
- Release cadence. Is the product actively developed, with a visible roadmap and regular releases? A product that hasn’t shipped meaningful features in two years is in maintenance mode — whatever the sales team says.
- Longevity and stability. Years in the AAA market, and whether telecom is a core business or a side line that could be divested.
- Support model. Is support staffed by people who understand carrier networks, or a generic tier-one queue?
A useful shortcut: ask how many AAA migrations the vendor has run in the last 18 months. Recent, repeated delivery at scale is the hardest signal to fake.
How to use these criteria: building your scoring matrix
Turn the eight criteria into a weighted scoring matrix so the decision is defensible rather than impressionistic. Assign each criterion a weight reflecting your situation, score every vendor 1–5 against it, then multiply and total.
A sensible default weighting for a growing broadband ISP:
| Criterion | Suggested weight |
|---|---|
| Peak load behavior | 20% |
| Real uptime / failover | 18% |
| Protocol & 5G roadmap | 12% |
| Migration safety | 15% |
| BSS / policy integration | 12% |
| True TCO | 13% |
| AI-readiness | 5% |
| Vendor viability | 5% |
Shift the weights to your reality. Mid-migration off CPAR? Push Criterion 4 up. Running converged fixed-mobile? Raise Criterion 3. The discipline of agreeing weights before the vendor demonstrations is what stops a polished pitch from overriding your actual priorities.
FAQs
What is the difference between AAA and RADIUS?
AAA is the function: authentication, authorization, and accounting. RADIUS is one of the protocols used to deliver it (Diameter and TACACS+ are others). An AAA platform implements the function; RADIUS is one of the languages it speaks. Saying “we use RADIUS” describes a protocol, not a complete authentication system.
How many concurrent sessions should an ISP AAA platform support?
It must comfortably exceed your subscriber count at peak, with headroom for re-authentication storms. A broadband ISP with 500K–2M subscribers should validate the platform at 8–12x average authentication load, not just at the subscriber number — post-outage bursts are where capacity actually gets tested.
Is FreeRADIUS sufficient for a growing ISP?
It can be, for smaller or stable deployments with strong in-house engineering. The risk appears at scale: the licensing is free, but operating, customising, and scaling it consumes senior engineering time and shifts all the reliability risk onto your team. Price that fully loaded cost before assuming “free” means cheap.
How long does an AAA migration typically take?
Structured migrations generally run 3–9 months depending on subscriber base size and the number of integrated BSS/OSS systems. A credible vendor uses dual-stack cutover with rollback to avoid a single high-risk switchover — be sceptical of anyone quoting a timeline that ignores your integrations.
Choosing among the best AAA platforms for ISPs
The vendors will compete on feature lists. You should compete back on production reality: peak-load behavior, real failover, a credible protocol roadmap, safe migration, deep integration, honest TCO, room for automation, and a vendor that will still be investing in five years. Score them on those eight, weight them to your situation, and the spec-sheet noise falls away.
If you’re building this evaluation while planning a move off FreeRADIUS, CPAR, or a stagnant commercial system, talk to an Alepo AAA specialist and get a free technical assessment of your current authentication setup. Alepo has deployed AAA for 35+ operators worldwide, from regional broadband ISPs to Tier-1 carriers.
Also see how Zain Jordan doubled network capacity and subscriber base with Alepo AAA.
