Most Authentication, Authorization, and Accounting (AAA) procurement goes wrong the same way: the evaluation tests what each vendor supports today against the traffic the network carries today. Both numbers are about to change. Subscriber counts grow, a fiber footprint expands into a second region, a deal with a Mobile Virtual Network Operator (MVNO) adds Diameter to a RADIUS-only estate and the platform that cleared last year’s bar becomes this year’s migration project.
AAA server vendors provide the authentication, authorization, and accounting infrastructure that controls who can access a network and what they can do on it. When selecting one for long-term growth, the differentiators are protocol support (RADIUS, Diameter, and TACACS+), transaction throughput at scale, high-availability architecture, and integration with existing billing and provisioning systems.
This guide turns that sentence into an evaluation framework: seven criteria, the questions to put in a request for proposal (RFP), and the warning signs that a vendor will not scale with you. It is written for network architects and engineering leaders at broadband, mobile, and Wi-Fi operators and MVNOs who already have a shortlist.
Why AAA server selection is a growth decision, not just procurement
AAA sits in the connection path of every subscriber session. That position makes it uniquely expensive to replace: swapping an AAA platform means re-pointing every network access server (NAS), broadband network gateway (BNG), and wireless controller, re-validating every Extensible Authentication Protocol (EAP) method, and reconciling accounting against billing while both systems run in parallel.
Operators who have migrated off end-of-life platforms know the sequence: parallel build, traffic shadowing, phased cutover by realm or NAS group, accounting last. Done carefully, it is routine. Done under duress, because the incumbent platform hit a ceiling mid-growth, it is a rescue operation.
That is the case for evaluating vendors against tomorrow’s network. The cost of choosing wrong is not the license fee; it is an unplanned migration at the worst possible time. End-of-life announcements make the point on their own schedule: when a widely deployed platform reaches end of support, a stable estate becomes a vendor decision the operator did not put in the budget.
So the organizing question for the whole evaluation is not “does this vendor meet our requirements?” It is: as subscriber count, protocol mix, or geographic footprint grows, what breaks first?
7 criteria to evaluate in an AAA server vendor
Each criterion below names the thing that breaks when it is missing. Score your shortlist against all seven; the gaps tell you where the next forced migration would come from.
| Sr nos. | Criterion | What breaks without it |
| 1 | Protocol breadth: RADIUS, Diameter, and TACACS+ on one platform, with the full EAP family | Adding mobile or Wi-Fi offload to a fixed-line estate means buying and integrating a second AAA |
| 2 | Throughput and scaling model: horizontal scaling, benchmarked under authentication storms as well as steady state | Peak events (mass reconnects after an outage, reauthentication storms) outrun a vertically scaled box |
| 3 | High availability and geo-redundancy: active-active across sites, with tested failover | A site failure takes authentication down with it, and every subscriber feels it at once |
| 4 | Integration surface: Home Subscriber Server (HSS) / Unified Data Management (UDM), Policy and Charging Rules Function (PCRF) / Policy Control Function (PCF), Online Charging System (OCS), and Business Support Systems (BSS) / billing via standard interfaces and APIs | Accounting that cannot reach billing cleanly becomes revenue leakage and manual reconciliation |
| 5 | Deployment flexibility: Kubernetes, virtual machine, bare metal, private cloud, on-premises, or managed service, from one codebase | A cloud mandate, a data-residency rule, or a latency-critical site forces a platform change |
| 6 | Vendor support and roadmap: carrier references, named service level agreements (SLAs), and visible investment in the product | An acquisition or quiet deprecation puts you back in an RFP you did not schedule |
| 7 | Migration path: a repeatable, field-proven method for moving off your current platform | A strong platform on paper stalls in a cutover the vendor has never actually performed |
Two of these deserve a closer look, because they are where vendors differ most and where evaluations most often stop short.
- Protocol breadth is a growth hedge, not a feature list: A broadband operator can run for years on RADIUS alone. Then a 4G/5G MVNO opportunity arrives and requires Diameter interfaces (SWx, S6b, Gx, Gy), or a security audit requires TACACS+ for device administration. Vendors that terminate all three protocols natively as the Alepo AAA Server does, alongside the full EAP family from EAP-SIM through EAP-PEAP, let that growth happen on the platform you already run. Point products make each new access type a new procurement.
- Throughput claims need a scaling model behind them: Any vendor can quote a transactions-per-second figure from a lab. The useful questions are architectural: does capacity grow by adding nodes or by forklift upgrade, what happens to in-flight sessions when a node joins or leaves, and has the vendor run this architecture at carrier scale in production? Ask for the reference, not the benchmark.
Open source vs. commercial AAA servers
The build-or-buy fork deserves honest treatment, because FreeRADIUS is genuinely capable software and plenty of operators run it well.
| Factor | Open source (FreeRADIUS and similar) | Commercial carrier-grade platform |
| Up-front cost | None for software; engineering time is the true cost | Subscription-based |
| Protocol coverage | RADIUS is the mature, widely deployed core. Extending one estate to Diameter and TACACS+ means additional components, integration, and test coverage you own | RADIUS, Diameter, and TACACS+ on one stack |
| Scaling and high availability | Yours to design, build, and test | Delivered and field-tested, with SLAs |
| Support at 2 a.m. | Your team and community forums | Named vendor SLA, escalation path |
| Risk profile | Key-person risk, the deployment is as durable as the engineers who built it | Vendor risk, mitigated by references and roadmap |
The pattern we see in practice: open source fits operators with strong in-house engineering and a stable, single-protocol estate. The equation shifts when growth adds protocols, sites, or compliance obligations, the point where the “free” platform starts consuming the engineering time you needed for the growth itself. If your team is spending more hours keeping the AAA running than extending it, that is the signal to re-evaluate, whichever direction you land.
Questions to ask before you sign
Copy these into your AAA server RFP as written. Vague answers to any of them are findings, not filler.
- Which protocols does the platform terminate natively (RADIUS, Diameter, TACACS+), and which EAP methods are in production use at your reference customers?
- Describe your horizontal scaling model. What is the operational procedure, and the impact on live sessions, when capacity is added?
- Describe a real failover event at a customer site: detection time, switchover behavior, and what subscribers experienced.
- Which BSS, billing, PCRF/PCF, and HSS/UDM systems have you integrated with in production, and over which interfaces?
- Which deployment models does one codebase support (Kubernetes, virtual machine, bare metal, private cloud, on-premises, managed service), and can they be mixed in one estate?
- Provide two references from migrations off the platform we currently run, and describe your cutover method, including rollback.
- What are your support tiers and their response and resolution SLAs? Is a named technical account manager available?
- What is on the product roadmap for the next 24 months, and how do customers influence it?
A vendor comfortable at carrier scale answers these with specifics and offers the reference call before you ask for it.
Signs a vendor won’t scale with you
Some warning signs are visible before contract signature, in how the vendor sells. Benchmarks quoted only at steady state, never under storm conditions. Scaling stories that end in “a bigger appliance.” References that are all enterprises when your network is an operator’s, or all one access type when yours is converging. Roadmaps that mention your must-have protocol “on request.” A migration method described in a slide rather than a runbook.
Others show up later, in production: capacity upgrades that require maintenance windows and forklift hardware, integration work that lands on your team because the vendor’s API surface stops at the spec sheet, and support queues that treat an authentication outage as a ticket rather than an incident. If you are seeing those today, the evaluation framework above doubles as an exit checklist.
This is the standard we build the Alepo AAA Server platform against: RADIUS, Diameter, and TACACS+ with the full EAP family on a single stack; active-active geo-redundancy designed for 99.999% availability; and one codebase that deploys to Kubernetes, virtual machines, bare metal, private cloud, on-premises, or a fully managed service. Alepo deployed 35+ operators globally, including networks serving millions of subscribers, and holds ISO 9001:2015 certification. A large share of that work has been migration off end-of-life platforms. We publish the criteria because we are comfortable being scored against them.
Frequently asked questions
Q1. What’s the difference between an open-source and a commercial AAA server?
Open-source servers such as FreeRADIUS are free to license and highly flexible, but scaling, high availability, multi-protocol coverage, and support are your engineering responsibility. Commercial carrier-grade platforms deliver those as product, with SLAs and references. The honest trade is engineering time against subscription cost, and it shifts toward commercial as the estate grows.
Q2. How many transactions per second should a carrier-grade AAA server support?
There is no single correct number. The event that actually sizes the platform is the reauthentication storm after a regional outage, when much of your subscriber base reconnects at once. Size against peak storm traffic with headroom for growth, and ask vendors for production references at your target scale rather than lab benchmarks.
Q3. What happens if my AAA server vendor can’t scale with subscriber growth?
Authentication latency rises first, then peak-event failures: subscribers unable to reconnect after outages, accounting gaps that surface in billing. The remedy is an unplanned migration, re-pointing every NAS and BNG, re-validating EAP methods, reconciling accounting in parallel. That is why scale ceilings belong in the original evaluation.
Q4. Can one AAA server support RADIUS, Diameter, and TACACS+ at the same time?
Yes. Multi-protocol platforms terminate all three natively on one stack, with one policy model and one data layer. The Alepo AAA Server is built this way. The alternative, separate point products per protocol, multiplies licensing, integration, and operational overhead as the network converges.
Q5. How long does it take to migrate to a new AAA server vendor?
It depends on estate size and protocol mix, but the method matters more than the calendar: parallel build, traffic shadowing, phased cutover by realm or NAS group, accounting migrated last and reconciled against the legacy system. Vendors who have performed these migrations will describe that sequence unprompted and put timelines against your specific estate.
Q6. What questions should be in an AAA server RFP?
Cover seven areas: native protocol and EAP coverage, the horizontal scaling model, tested failover behavior, production BSS and billing integrations, supported deployment models, migration method with references, and support SLAs plus roadmap. The eight questions above are written to be pasted in directly.
Q7. Is a cloud-hosted AAA server as reliable as on-premises?
It can be, if the architecture is right: reliability comes from active-active redundancy across failure domains, wherever those domains happen to run. What cloud changes is the latency calculation, authentication sits in the connection path, so placement near the access network still matters. Well-designed platforms support both, and mixed estates are a legitimate end state.
The checklist works best on a live platform. Book a demo, to see how AAA server works
