5 Business cases
- Where the sprawl comes from: historical broadband/mobile/Wi-Fi silos, an acquisition whose AAA estate was never integrated, or point products bought one service at a time. Which one you are on decides who sponsors the fix.
- What it costs: every platform is separately patched, monitored, staffed and integrated; fixed, mobile and Wi-Fi identities behave as separate subscribers; and every system is its own audit evidence path.
- What consolidation changes: one data layer, one management plane, and native multi-protocol support. Those are three separate changes, and each retires a different cost.
- How to argue it: compare two total costs – current estate versus consolidated platform, rather than claiming a savings percentage, and sequence the retirements so each one releases its own cost.
- The catch worth naming first: consolidation replaces many failure domains with one, so the target platform’s availability architecture stops being a preference and becomes a precondition.
Nobody designs a network with four AAA systems in it. They arrive one at a time, each for a defensible reason, over a decade. A broadband RADIUS deployment that predates the mobile business. A Diameter stack that came with the packet core. A Wi-Fi authentication server the Wi-Fi team bought because procurement was faster than integration. A fourth that arrived with an acquisition, still on the acquired operator’s hardware because nobody has had a quarter free to move it.
The business case for consolidating multiple AAA systems onto one platform rests on three cost and risk categories: reduced operational overhead from running fewer systems, a consistent subscriber experience across network types, and a simplified audit and compliance surface. A single converged, multi-protocol platform addresses all three at once.
Each decision made sense on the day. The accumulated result rarely does. AAA (Authentication, Authorization, and Accounting) sprawl is the condition of running several separate authentication platforms – RADIUS (Remote Authentication Dial-In User Service), Diameter, TACACS+ (Terminal Access Controller Access-Control System Plus) – across access types that increasingly serve the same subscribers, and it carries a cost that never appears as a line item because no single budget carries it.
This article sets out where that cost actually sits, what a converged platform changes, and how to build the numbers for your own estate. It is written for network and operations leaders who already suspect they have the problem and need to make the argument internally.
How operators end up with multiple AAA systems
Three paths account for almost every case of AAA sprawl, and knowing which one you are on shapes the consolidation argument.
The first is historical silos. Fixed broadband, mobile, and Wi-Fi were built by different teams, on different timelines, against different protocol requirements – RADIUS at the BNG (broadband network gateway), Diameter in the packet core, another RADIUS instance behind the Wi-Fi controller. Nothing was wrong with any of those choices at the time. What changed is that the subscriber is now the same person on all three networks.
The second is mergers and acquisitions. An acquired operator brings a complete AAA estate with it: its own servers, its own realm structure, its own policy model, and its own vendor relationship. Integration plans usually put AAA behind billing and network consolidation in the sequence, so the acquired platform keeps running. Sometimes for years, occasionally past the point where anyone remembers how it was configured.
The third is opportunistic procurement. A new service needed authentication faster than the incumbent platform could be extended, so a point product was bought for that service. Repeat two or three times and the estate has a system per use case, not a platform per network.
The distinction matters for the business case. Silo sprawl is a design-debt argument. M&A sprawl is an integration-completion argument with a board-level sponsor already in place. Procurement sprawl is a governance argument. Frame the case for the audience that owns the cause.
The operational overhead of running multiple systems
Start with the least controversial cost category, because it is the one your operations team can confirm from memory.
Every AAA platform in the estate is a separate thing to patch, monitor, capacity-plan, back up, test for failover, and staff for. Each carries its own vendor support relationship, its own upgrade cycle, its own maintenance window, and its own set of people who genuinely understand it- a group that, for the oldest system in the estate, is often one or two people.
The staffing concentration is the risk worth naming explicitly in the business case. Sprawl produces specialists, not a team: the engineer who knows the acquired operator’s RADIUS configuration, the engineer who owns the Diameter stack. Holiday cover is thin, handover is slow, and a resignation can strand a system that authenticates live subscribers.
Integration effort multiplies the same way. Every AAA system that touches billing, provisioning, the SDM (subscriber data management) layer, or a SIEM (security information and event management) tool needs its own interface, its own data mapping, and its own regression test whenever anything on either side changes. Four systems do not mean four integrations; they mean four integrations per downstream system.
Reducing AAA system sprawl removes that multiplication. It is also the category most likely to be underestimated, because the effort is spread across many people’s weeks instead of concentrated in one budget line.
Inconsistent subscriber experience across silos
Here is the failure that reaches customers, and it is the one executives respond to fastest.
When a subscriber’s fixed, mobile, and Wi-Fi identities live in separate authentication systems, they are separate subscribers as far as the network is concerned. Policy applied on one access type does not follow them to another. A quota, a service class, or a restriction enforced on broadband has no equivalent on Wi-Fi unless someone built and maintained a synchronization path between the two, and synchronization paths drift.
The operational symptom is a support queue that cannot answer simple questions. “Why did my connection drop when I moved to Wi-Fi?” requires correlating session records from two systems with different record formats, different timestamps, and different retention policies. Second-line engineers end up reconstructing a single subscriber’s evening from several exports.
It also closes off convergent products. A converged fixed-mobile bundle with shared policy requires shared authentication state, and building that on top of siloed AAA means building a synchronization layer no one wants to own. Operators pursuing FMC (fixed-mobile convergence) usually discover the AAA layer is the constraint well after the commercial launch has been announced.
Multiplied audit and compliance complexity
Each AAA system is its own compliance surface. That sentence is the whole section, and the consequences are the part that gets left out of consolidation business cases.
An audit or regulatory evidence request does not scale with the number of systems you run; the work of answering it does. Access reviews, log retention proof, encryption-in-transit evidence, and administrator accountability all have to be demonstrated separately for every platform, against whatever that platform’s own logging and reporting can produce. Where the platforms differ in retention period or log format, the operator absorbs the reconciliation.
Security posture drifts the same way. Modern transport protections such as RadSec for RADIUS (RFC 6614, Experimental status) and TACACS+ over TLS 1.3 (RFC 9887, a 2025 Proposed Standard that updates RFC 8907) are implemented on whichever platform’s upgrade fell due first. Credential policy, administrator authorization granularity, and identity-lifecycle practices such as those in NIST SP 800-63B-4 end up applied unevenly. The estate’s real security posture is that of its weakest system, which is usually the one nobody wants to touch.
Incident response inherits the same problem. When authentication failures spike, the first question is whether the cause is one system or the network, and answering it means correlating across platforms that were never designed to be read together.
Also Read: How Operators Prove AAA Reliability to Regulators and Enterprise Customers
What a converged platform actually changes
A converged AAA platform terminates every protocol the estate needs on one stack, against one subscriber and administrator data layer, under one management plane. Those are separate changes, and each retires a different cost.
One data layer means a subscriber is one profile carrying several access identities: a line identifier on broadband, a SIM identity on mobile, a device or username identity on Wi-Fi. That is a stronger position than one record per access type, because entitlement and policy can then be defined once against the subscriber and applied consistently wherever the access network supports the attribute.
One management plane means one place to define policy, one place to read session records, and one audit trail. Accounting records (RFC 2866) are the artifact auditors ask for most often, and consolidation puts them in a single format under a single retention policy.
Native multi-protocol support means adding an access type becomes a configuration exercise rather than a procurement cycle. The same argument extends forward: a 5G SA (standalone) core authenticates over service-based interfaces rather than Diameter, so an operator adding 5G to an already-sprawling estate is choosing between another silo and a platform that spans the boundary.
AAA consolidation: cost and risk categories, before and after
| Cost / risk category | Impact when siloed | What consolidation changes |
| Operational overhead | Separate patching, monitoring, capacity planning, failover testing, support contracts, and specialist staffing per system; integrations multiply across every downstream system | One upgrade cycle, one monitoring surface, one on-call rotation, and one integration per downstream system – the HSS (home subscriber server), the PCRF (policy and charging rules function), the OCS (online charging system), BSS (business support systems), SDM, and SIEM |
| Subscriber experience | Fixed, mobile, and Wi-Fi identities behave as separate subscribers; policy does not follow the user across access types; troubleshooting requires correlating records across systems | One subscriber profile carrying every access identity, so entitlement and policy are defined once; one session and accounting view for support and second-line engineering |
| Audit and compliance | Every system is a separate compliance surface with its own logs, retention, and evidence path; security posture is set by the weakest platform | One audit trail and one retention policy across RADIUS, Diameter, and TACACS+; transport security and credential policy applied uniformly |
One caution belongs here, and it is the strongest argument against doing this carelessly. Consolidation replaces many failure domains with one, which raises the bar on the target platform’s availability architecture. Active-active geo-redundancy, tested failover, and horizontal scaling stop being desirable and become preconditions, because the consolidated platform now carries the combined authentication load of everything it replaced. This is the thing to press vendors on hardest. For reference, Alepo’s AAA Server runs in active-active geo-redundant pairs designed for 99.999% availability, measured at 36,000+ sustained transactions per second in containerized deployment (Alepo production figures, not industry averages).
Calculating ROI for consolidation
Build the case as a comparison between two total costs, current estate versus consolidated platform, instead of as a savings percentage. Percentages invite argument; itemized costs your own finance team can verify do not.
On the current-state side, inventory five things across every AAA system in the estate.
- Licensing and vendor support: One contract per platform, including the ones that renew without anyone reviewing them.
- Infrastructure: Compute and storage, including the hardware carrying the oldest platforms.
- Engineering and operations effort: FTE (full-time equivalent) time actually spent on run, patch, and integration work, rather than the time the org chart implies.
- Integration and interface maintenance: Every connection to billing, provisioning, the SDM layer, and security tooling, multiplied by the number of systems holding it.
- Compliance and audit effort: Counted in engineering days per cycle, because it almost never appears as a line item.
Then add the risk items you cannot cost precisely but should still name: key-person dependency, unsupported or end-of-life platforms, and the exposure of an uneven security posture.
On the target-state side, cost the converged platform, the migration itself, and the run model that follows. Migration is a funded project with a number of its own, not a rounding error, and for an estate of any size it is multi-phase and multi-quarter. Sequence it the way migrations off legacy platforms are actually run: build the target alongside the live estate, shadow live traffic against it, cut over in tranches by realm (the authentication domain a request belongs to) or NAS (network access server) group, and move accounting last.
Two habits make the arithmetic defensible. Order the phases so each retirement releases its own cost, which lets the case show savings landing progressively instead of all at the end. And use the operator’s own figures throughout, because your operations manager’s estimate of hours spent on the acquired platform last quarter carries more weight in a board paper than any industry benchmark.
Take a fixed-line operator that acquired a regional ISP (internet service provider). It runs its own broadband RADIUS, the acquired operator’s RADIUS, a Diameter stack from a mobile venture, and a device-administration server for engineer logins. Four platforms, four support contracts, four evidence paths at audit, and one subscriber base that no longer maps cleanly to any of them. The consolidation case there is not a technology preference; it is finishing an integration that was deferred, and the end-of-life date on the oldest platform has already set the deadline.
Building your business case for consolidating multiple AAA systems
The case is strongest when it is written in the language of the cause design debt, an unfinished integration, or a governance gap because that is what decides who sponsors it.
Whichever applies, the structure is the same: inventory the estate honestly, cost the three categories above from your own data, cost the migration as a real project, and sequence the retirements so value arrives in stages. A forcing function, whether an end-of-life notice, a merger integration milestone, or an audit finding, is what usually converts a good case into a funded one, so look for the one you already have.
The platform you consolidate onto has to carry the whole estate. Alepo’s AAA Server terminates RADIUS with Dynamic Authorization (RFC 2865, with Change-of-Authorization per RFC 5176), the Diameter interfaces the EPC (Evolved Packet Core) boundary needs – S6a, S6b, SWx, SWm, Gx, and Gy, carried over the Diameter base protocol (RFC 6733) and TACACS+ with per-command authorization (RFC 8907) on a single stack, with the full EAP (Extensible Authentication Protocol) family from EAP-SIM through EAP-PEAP. It deploys on Kubernetes, VMs, bare metal, private cloud, on premises, or as a managed service from one codebase. That footprint reflects carrier AAA work with Tier-1 and Tier-2 operators across broadband, mobile, and Wi-Fi networks, much of it consolidation and migration work off platforms that reached end of life. Our carrier-grade AAA server comparison, our cloud-native AAA architecture guide, and our business case for AAA server modernization set out the evaluation criteria in more depth, and our guide to migration off an end-of-life platform covers the cutover method.
Start with the inventory. Most operators find the estate is larger than the org chart suggests, and that finding alone tends to move the conversation.
Bring us your estate, not just your requirements
Book a working session and we will walk your team through what consolidating your specific mix of RADIUS, Diameter, and TACACS+ systems would involve: protocol coverage, migration sequence, and the phases where cost actually comes out.
Still scoping? Download the AAA Server datasheet and put the architecture in front of your network and finance teams first.
Frequently asked questions
Q1. What’s the business case for consolidating multiple AAA systems?
It rests on three cost and risk categories: reduced operational overhead from running fewer systems to patch, monitor, staff, and integrate; a consistent subscriber experience, because one subscriber profile means policy is defined once and applied across access types; and a simplified audit and compliance surface, because one platform produces one evidence path instead of one per system.
Q2. Why do operators end up with multiple AAA systems?
Three paths account for most cases. Historical silos, where fixed, mobile, and Wi-Fi were built by different teams on different timelines. Mergers and acquisitions, where the acquired operator brings a complete AAA estate that integration plans defer. And opportunistic procurement, where a point product was bought because it was faster than extending the incumbent platform.
Q3. What cost savings come from AAA consolidation?
Savings come from fewer vendor support and licensing relationships, less infrastructure, a single upgrade and patching cycle instead of several, one integration per downstream system rather than one per system pair, and less compliance effort per audit cycle. Cost these from your own operations data instead of from a benchmark percentage, because the internal figures are what a finance review will accept.
Q4. How does AAA consolidation reduce operational complexity?
One management plane replaces several: one place to define policy, one place to read session and accounting records, one monitoring surface, and one on-call rotation. It also removes the key-person dependency that sprawl creates, where a single engineer is the only person who fully understands the oldest system in the estate.
Q5. What risks come from running multiple siloed AAA systems?
Policy enforcement is inconsistent across access types, because each system holds its own view of the subscriber. The compliance surface multiplies, since every platform needs its own evidence path. And the estate’s real security posture is set by its weakest platform, which is usually the one running on the oldest hardware with the fewest people who know it.
Q6. How does M&A lead to AAA system sprawl?
An acquired operator arrives with its own AAA servers, realm structure, policy model, and vendor contract. AAA typically sits behind billing and network consolidation in the integration sequence, so the acquired platform keeps running, often past the point where the original configuration is well understood. The unfinished integration is usually the strongest framing for the consolidation case, because it already has an executive sponsor.
Q7. How do I calculate ROI for an AAA consolidation project?
Compare two total costs instead of claiming a savings percentage. Current state: licensing and support, infrastructure, engineering and operations FTE time, integration maintenance, and compliance effort across every system. Target state: the converged platform, the migration project, and the run model that follows. Order the phased retirements so each one releases its own cost, and use your own operational figures throughout.
Q8. How long does an AAA consolidation project typically take?
For an estate of any size, plan for a multi-phase, multi-quarter project scoped like a major migration, with the target platform built and traffic-shadowed alongside the live estate before any cutover begins. The duration depends on the number of systems, the number of downstream integrations, and how well the oldest platform’s configuration is documented. That last factor is the one most often underestimated.
