Overview
- Building is a legitimate answer for a single-protocol estate with predictable growth, engineers who know RADIUS (Remote Authentication Dial-In User Service) properly, and availability targets you set for yourself rather than ones written into someone else’s contract.
- The cost of the build path is not the deployment. It is the recurring engineering time that follows: patching, upgrades, capacity re-proving, on-call, and the documentation nobody schedules.
- Three thresholds move the answer: protocol breadth (Diameter, TACACS+), a hard availability commitment, and compliance obligations that demand evidence rather than assurances.
- Score your own situation on the factor table below. Most operators find some factors point each way, and the useful output is knowing which ones actually bind.
Search for build vs buy guidance on your AAA stack and most of what comes back was written by a vendor, which means most of it reaches the same conclusion. That is unfortunate, because the build option here is real. FreeRADIUS is capable software with a large deployed base, and there are operators running it well today on networks that carry revenue.
So this article is a decision framework rather than an argument. The honest version of the build-vs-buy question for AAA (Authentication, Authorization, and Accounting) infrastructure is not whether open source can do the job. The question is whether maintaining it is the right use of your engineering team, given the scale you run at, the protocols you need, and what you have committed to about availability. Those answers change over time, which is why this decision deserves a review date rather than a single verdict.
The build-vs-buy decision for an AAA stack genuinely favors building, usually on FreeRADIUS, at smaller scale with simple protocol needs and strong in-house RADIUS expertise. Total cost of ownership shifts toward buying a commercial platform as scale, protocol breadth, and reliability requirements grow, because engineering time rather than license cost becomes the dominant expense.
When building your own AAA stack makes sense
Building makes sense when the estate is single-protocol, growth is forecastable, and RADIUS expertise is held by more than one engineer. There is a profile the build option fits well, and it is worth stating plainly before anything else: a single-protocol estate, a subscriber base growing at a pace you can forecast, engineers who already know RADIUS properly rather than approximately, and an availability target you set for yourself rather than one carrying service credits.
FreeRADIUS is not the weak point in that picture. It is an open-source RADIUS server implementing the authentication and accounting behavior defined in RFC 2865 and RFC 2866, it supports a broad range of EAP (Extensible Authentication Protocol) methods, it authenticates against SQL and directory backends, and it has its own policy configuration language. Operators have run it at meaningful subscriber scale for years, and dismissing that is how vendor content loses technical readers in the first paragraph.
What the build path asks for is everything around the software. The policy design, the database schema, the integration into provisioning and billing, the redundancy model, the monitoring, the upgrade procedure, and a team that can carry all of it through staff changes. Where those already exist and work, building is a defensible answer, and the rest of this article is about the conditions that change it.
The real cost of in-house maintenance
The real cost is the recurring engineering time after go-live, not the build itself. Most build decisions misjudge the cost, and they misjudge it in a specific place: not the build, but year three.
The initial deployment is usually the part a capable team estimates accurately. Someone designs the policy logic, stands up the servers, wires in the subscriber database, tests against the BNG (broadband network gateway), BRAS (broadband remote access server), and wireless controller estate, and cuts over. That work is finite and visible, and it generally goes about as well as planned.
What follows is neither finite nor visible. Security patches arrive on someone else’s schedule and have to be tested against your policy configuration before they go near production. Operating system and dependency upgrades force a retest of the whole stack. Capacity has to be re-proven after every material change to the access network. Someone has to be reachable when authentication starts failing at 2 a.m., and that someone has to know the deployment well enough to fix it under pressure rather than read about it.
Then there is the work nobody puts on a sprint board: documentation that keeps up with the configuration, runbooks that match the current architecture, and enough shared knowledge that the deployment survives a resignation. Teams that run open-source AAA well do all of this, and the effort is recurring rather than front-loaded, which is the part a cost model has to capture.
What changes as scale and complexity grow
The build case rarely degrades gradually. It tends to break at three specific thresholds: protocol breadth, a hard availability commitment, and compliance obligations that require evidence.
The first is protocol breadth. A broadband operator can run on RADIUS alone for years, and then an MVNO (Mobile Virtual Network Operator) opportunity arrives that requires integration with a 4G evolved packet core over Diameter interfaces such as S6b and SWx, built on the base protocol in RFC 6733 and specified in 3GPP TS 29.273. A 5G core changes the shape of that work without removing it, since 5G service-based interfaces run over HTTP/2 rather than over Diameter. Or a security audit requires TACACS+ (Terminal Access Controller Access-Control System Plus) for device administration. On the build path each of those is a separate project with its own implementation, testing, and maintenance burden, running alongside the RADIUS stack you already maintain. On a converged platform it is configuration – the distinction we draw out in RADIUS vs Diameter vs TACACS+ in CSP environments.
The second is the availability requirement. Designing for occasional planned downtime is a different engineering problem from designing for continuous service, and the gap between them is wider than it looks from the near side. Active-active operation, session state handling across nodes, geographic redundancy, and a failover path that has been tested under load rather than assumed are each substantial pieces of work, and on the build path all of them are yours to design, prove, and keep working. Our write-up on AAA that scales itself through peak traffic is a fair inventory of what that commitment involves.
The third is compliance. Once an auditor or regulator is asking for authentication records within a defined retention window, or an enterprise customer’s security team wants evidence of your patching cadence, the informal parts of a self-maintained stack turn into findings.
Each of these tends to arrive with a commercial deadline attached, which is the part that hurts. The wholesale deal has a launch date. The enterprise contract has a security review. Building a new capability from scratch against that timeline is where in-house stacks most often come apart.
The buy side carries a version of this too. A commercial platform removes the implementation work, though not the integration: adding a protocol still means design, testing, and a cutover plan on your side of the boundary. What changes is who builds and maintains the protocol stack underneath it.
Total cost of ownership: build vs. buy
A TCO (total cost of ownership) comparison that counts only money will favor the build path every time, because the build path’s largest cost is not denominated in money. It is denominated in engineering time, and an honest model has to convert one into the other.
On the build side, count the effort to design and deploy, then the recurring fraction of one or more engineers’ time spent on patching, upgrades, capacity work, and incident response. Add on-call coverage, the infrastructure the stack runs on, and a test environment that mirrors production closely enough to be useful. Integration into provisioning, billing, and monitoring exists on both paths, but on this one you also own it forever.
On the buy side, count the subscription, the integration effort, and the vendor-management overhead that comes with any supplier relationship. If you are replacing something existing, migration cost sits on both paths and should not be used to argue for either.
There is also a third option that gets left out of a binary comparison. Managed AAA, sometimes sold as RADIUS as a service, moves the operating burden to a vendor without requiring you to run the platform yourself, which is often the shape that fits an operator whose constraint is headcount rather than budget.
The line most models omit is opportunity cost. Engineering time spent keeping an AAA stack current is time not spent on the network build, the new service, or the automation work that was supposed to happen this year. For a small team that is frequently the decisive number, so estimate it explicitly: how many engineer-weeks per year the stack consumes, and what those weeks would otherwise have produced.
Risk considerations beyond cost
Three risks recur on self-maintained stacks: key-person dependency, inconsistent patching cadence, and the absence of an escalation path. Ask who would fix the AAA stack if the engineer who built it resigned next month. On a well-run build deployment there is a real answer. On a lot of them there is a name, and only one.
Key-person dependency, sometimes called the bus factor, is the risk that surfaces most often, and it is structural rather than a sign of a badly run team. A self-maintained stack accumulates decisions that live in one person’s head: why a policy is written the way it is, which module was patched around and why, what the failover does under real load. Documentation helps and rarely keeps pace with the configuration.
Patching cadence is the second risk. A vulnerability is disclosed in a dependency, and the fix has to be tested against your configuration and deployed by a team that also has other commitments. The elapsed time between disclosure and deployment is a number worth measuring on any stack you maintain yourself, because a security reviewer will eventually ask for it and the answer is either reassuring or it is a finding.
The third is the absence of an escalation path. Community support for open-source AAA is real and often excellent, and it is not an SLA (Service Level Agreement) with a named responder and a response-time commitment. During a mass re-authentication event at 3 a.m., a forum thread and a support contract are not the same thing. This is also the risk that most often goes unweighted in an evaluation.
A decision framework for your team
Run your own situation through the factors below rather than through a general argument. Most operators find the result is mixed, with some factors pointing each way, and the useful output is identifying which ones actually bind.
Build vs buy decision factors for AAA infrastructure
| Factor | Favors build | Favors buy |
| Protocol scope | RADIUS only, with no roadmap toward Diameter or TACACS+ | Multi-protocol now or expected: Diameter for evolved packet core integration, TACACS+ for device administration |
| Scale and growth | Subscriber base you can forecast, capacity headroom on current design | Rapid or uneven growth, or scale that requires a horizontal model you would have to build |
| Availability commitment | Targets you set internally, planned maintenance windows acceptable | Contractual SLAs with service credits, or carrier-grade continuous-service expectations |
| In-house RADIUS expertise | Multiple engineers with deep, current protocol knowledge | Expertise concentrated in one person, or being recruited for |
| On-call coverage | Rotation that covers nights and holidays without burning anyone out | Thin coverage, or an escalation path that ends at a forum |
| Compliance and audit obligations | Light, internal, no external evidence requirements | Regulator or enterprise customers requiring logs, retention, and patching evidence |
| Integration surface | Stable, small number of well-understood systems | Broad integration into BSS (Business Support Systems), billing, provisioning, policy control (PCF/PCRF), and subscriber data (HSS/UDM) |
| Opportunity cost of engineering time | Team has capacity to spare | Same engineers are the bottleneck on network or product work |
Here is a worked example – illustrative, not a customer account. A regional fiber ISP (Internet Service Provider) has run FreeRADIUS for six years and runs it well. One engineer knows it thoroughly and a second knows it adequately. The estate is RADIUS only, growth is steady, and availability has never been contractually promised to anyone.
On the factors above that operator sits on the build side of nearly every row, and the decision to keep building is correct. Then they win a wholesale agreement that requires Diameter interfaces into a partner’s core, and the contract carries an availability commitment with service credits attached. Two rows flip at once, and they happen to be two of the rows that bind hardest. The original build decision was not wrong. The network changed underneath it, which is exactly why this belongs on a review cycle.
Making the build vs. buy decision for your AAA stack
There is no universal answer here, and a vendor who offers one is selling rather than advising. Building on open source is a legitimate choice for a single-protocol estate with real in-house expertise and availability targets you own. Buying becomes the better answer as protocol breadth, reliability commitments, and compliance obligations grow, because past a certain point the engineering effort required to keep pace exceeds what the same team could contribute elsewhere.
The Alepo AAA Server is built for the position on the far side of that shift. It terminates RADIUS, Diameter, and TACACS+ on one platform rather than as three parallel projects, and runs active-active with real-time database replication, designed for 99.999% availability. The shift usually shows up as operational load rather than capability. The question is not whether your stack still authenticates, but how many engineering hours a month go into keeping it that way rather than extending it.
For teams coming off an aging commercial platform instead, the same considerations apply to a migration from a legacy or end-of-life AAA system, and the sequencing is covered in our AAA migration checklist.
Whichever way your factors point, write down the answer and the reasoning behind it, and set a date to review both. If you are running a self-maintained stack today and two rows in that table have flipped since you last checked, the decision is already due for another look.
Bring your factor table to a technical evaluation
If your scoring came out on the buy side, the next useful step is a working session rather than a pitch. Bring the rows that flipped, the protocols you need to add, and the availability commitment you are being asked to sign, and we will walk through how the Alepo AAA Server handles each one and what the migration from your current stack would actually involve.
Frequently asked questions
Q1. Should my team build or buy our AAA infrastructure?
It depends on scale, protocol scope, and what you have committed to about availability. Building is reasonable for a RADIUS-only estate with forecastable growth, multiple engineers who know the protocol well, and internally set availability targets. Buying is generally better once you need Diameter or TACACS+, carry contractual SLAs, or face external audit obligations. Score the factor table above against your own situation rather than working from a general rule.
Q2. Is FreeRADIUS a viable alternative to a commercial AAA platform?
Yes, genuinely, within the right envelope. FreeRADIUS is capable software with broad EAP method coverage, flexible backends, and a large deployed base, and plenty of operators run it well. The constraint is rarely the software itself. It is the engineering effort required around it as protocol breadth, availability requirements, and compliance obligations grow.
Q3. What is the real cost of maintaining an in-house AAA stack?
The recurring engineering time, not the license you avoided. Budget for patch testing against your own configuration, operating system and dependency upgrades, capacity re-proving after access network changes, on-call coverage, and the documentation and knowledge transfer that keep the deployment viable through staff changes. The initial build is usually estimated accurately; the years after it are usually not.
Q4. When does building your own AAA stack make sense?
When the estate is single-protocol, growth is predictable, RADIUS expertise is held by more than one engineer, availability targets are set internally rather than contractually, and the team has engineering capacity that is not needed elsewhere. If most of those are true, building is a defensible decision.
Q5. What hidden costs come with open-source AAA at carrier scale?
The costs that scale faster than the subscriber count: building and proving high availability rather than assuming it, adding each new protocol as a separate project, producing audit evidence on demand, and carrying an on-call rotation deep enough that no single person is the failover. None of these appear in an initial build estimate, and together they usually exceed it.
Q6. How do I compare total cost of ownership between build and buy?
Convert engineering time into cost on the build side and include it: design and deployment effort, the recurring fraction of engineers’ time spent on maintenance, on-call, infrastructure, and a realistic test environment. On the buy side, count subscription, integration, and vendor management. Then add opportunity cost, which is the work your engineers are not doing while they maintain the stack. That line decides the comparison more often than any other.
Q7. What risks come with maintaining AAA infrastructure in-house?
Three recur. Key-person dependency, where deployment knowledge lives with one engineer. Inconsistent patching cadence, where the elapsed time between a disclosed vulnerability and a deployed fix depends on competing priorities. And the absence of an escalation path, where community support is good but is not a support contract with a named responder at 3 a.m.
Q8. What team size is needed to maintain an in-house AAA stack?
Enough to cover on-call, patching, and upgrades without a single point of failure, which in practice means more than one engineer with deep protocol knowledge rather than one specialist and a backup who has read the runbook. The honest test is not headcount but whether the deployment would survive your most knowledgeable engineer leaving with four weeks’ notice.
