You inherited a RADIUS server. You were told never to touch it. The one person who understood it left years ago. It’s a problem waiting to happen.
Alan DeKok, CEO and Founder, InkBridge Networks
Every ISP I visit has a RADIUS server sitting in a rack, or a virtual machine nobody has rebooted in three years, running a release that went out of support before half the current team was hired. It authenticates every subscriber who comes online. And the standing instruction, passed from one engineer to the next, is always the same: do not touch it.
When you inherit a system you cannot explain, it feels like the safest thing to do is leave it alone. It would be, if the network stayed exactly as it is (same size, same hardware, same certificates, same staff) for as long as you own it. Since networks do not work that way, leaving it alone gets riskier with time.
The anatomy of inherited RADIUS debt
RADIUS looks simple, and that is the root of the problem. At its heart, it is a database query protocol. A request comes in, the server looks something up, and it returns an answer that tells the network access server (NAS) what to do. The NAS makes the final decision.
You can stand up a basic server with a table of users in an afternoon, and it will work. It will keep working for years. So nobody ever goes back and builds a real understanding of it.
Then something moves, and the cracks become visible.
People find this hard to believe, but the RADIUS standards do not define error codes. The specifications describe what the packets and attributes look like in great detail, but there is no standard way for a server to say “your shared secret is wrong” or “this user does not exist,” or to explain almost any other failure.
Every implementation reports trouble differently, and much of the time it cannot report it at all. So when an inherited server misbehaves, an experienced engineer can stare at it for a day and get nowhere, because the protocol never specified how failures should be explained.
This is not only a problem with servers you inherited. RADIUS is hard to understand on its own terms, so the gaps show up even when the same team has run the same system for years. Keeping a server running is not the same as understanding it.
When an inherited deployment goes wrong, the cause is usually a configuration or session-handling decision made years ago by someone who has since left. But I have also watched capable engineers who built their own system hit behaviour nobody on the team can account for.
RADIUS is powerful enough to do almost anything, which is why it is so easy to get wrong. Whether you inherited the thing or built it yourself, asking someone who works on RADIUS every day is almost always worth it.
Why acquisitions turn one mystery box into several
The worst version of this is the server you inherited from another company. This is a common occurrence, given the rate of consolidation in this industry.
A regional carrier buys a smaller ISP, and along with the subscribers and the fibre, it acquires an authentication stack it has never seen, built on different tooling from its own, with no documentation and nobody left to explain the design choices.
The engineer who built it worked for the acquired company, and that company no longer exists. Sometimes the chain is longer still: the system was set up by one contractor, handed to a managed-service provider, then absorbed in an acquisition, and every handoff stripped away another layer of understanding while the configuration itself kept running, untouched.
Now multiply that by sites. A design that made sense as one server for one location becomes dozens of servers scattered across a complex footprint. Getting the network design for multi-site RADIUS systems right is a discipline in its own right, and not one you can reverse-engineer under pressure after the fact.
Proprietary inheritances carry their own deadline. If the acquired network runs something like Steel-Belted RADIUS, migrating off a product that is reaching end of life is a must, and the clock is already running.
A RADIUS server that nobody understands is an outage waiting for a bad night.
The cost of running on prayer
The RADIUS debt always comes due.
I have seen distributed remote access secured by a single shared username and password, with no record of who logged in or when - an audit finding that sat open for years because the working system was considered too fragile to touch.
I have seen inherited stacks running so far behind on releases that the upgrade path itself had become a research project. These are the scenarios that cause trouble when the network comes under stress.
RADIUS is only ever tested properly under stress. Steady-state traffic is a handful of packets a second. You need to plan for the recovery surge. Power returns to a neighbourhood, 100,000 devices try to reconnect in the same few seconds, and your server has to absorb tens of thousands of requests at once.
A RADIUS system designed for ISP scale stays idle enough to survive that moment by design. A server that was never designed for it will fall over at the most inconvenient time.
There is a subtler cost as well. The part of an inherited stack most likely to fail is the database behind the RADIUS server.
Authentication and Accounting have opposite needs. One wants to be fast and read-only, the other writes constantly. Yet inherited systems almost always jam both into a single database, alongside years of session history. It runs fine until the day it does not, and by then the person who chose that schema is long gone. When an ISP tells me its RADIUS server is slow, the RADIUS server is rarely the thing that is actually slow.
Worth subscribing to.
Worth reading.
Our weekly newsletter covers network authentication tips, how-tos, security vulnerabilities, free resources, standards updates, and industry news. (All stuff you should stay up to date on!)
How to make the case for RADIUS migration internally
If you are the engineer responsible for the RADIUS server, the hardest part is usually convincing the people who control the budget that a system which appears to be working needs money spent on it. Here is how I would frame it.
Start with the trigger you already have.
You almost certainly have one.
A compliance or regulatory deadline that requires tracked logins.
A standing audit finding that leadership has wanted closed for years.
A support contract or a piece of hardware reaching end of life on a fixed date.
A key person leaving.
Any one of these turns “we should look at this eventually” into “we have to deal with this by a date.” Attach your case to that date.
Reframe what you are actually buying.
Expert support is not a call centre, and it is not day-to-day babysitting. Think of it as insurance.
A well-architected RADIUS system is one you rarely have to touch; the support exists for the growth events (a new site, an acquisition, a jump in subscribers) and for the rare night when something breaks and you need the people who wrote the software on the other end of the line.
The best time to build and test a recovery procedure is 10 a.m. with a coffee in your hand, not 2 a.m. with the network down. Paying for that in advance is cheaper than the downtime it prevents, and far cheaper than rebuilding after a bad migration.
Expect two objections.
The first is “Is it safe to run open source in production?”
FreeRADIUS, the open-source server we maintain, underpins a large share of the internet and sits inside many of the commercial products your organisation already trusts.
Paying for expertise on top of free software is not unusual or unfair. It is the economics of open source.
The second objection is “How often will we actually touch it?”, and the answer is: not often. That is the point. You are paying for the system to stay boring, and for someone to pick up the phone on the night it stops being boring.
Need more help?
If your team is wrestling with network configuration, a troubleshooting problem you cannot resolve, or a system that needs to be more resilient, we can help. InkBridge Networks has 25 years of expertise - we wrote the standards, maintain FreeRADIUS, and have seen every failure mode there is. Reach out to request a quote.
Related Articles
RADIUS design for internet service providers (ISPs)
More than almost any other business, internet service providers (ISPs) need to provide their customers with fast, reliable internet connection to their computer network. Any downtime can be catastrophic to their business operations. Slow connection speeds will drive customers away to other providers. This means that ISPs need to ensure that their network has several levels of redundancy in order to provide stable service at all times.
Network design for multi-site RADIUS systems
Some organizations and network operators such as ISPs can use a central RADIUS service for all of their RADIUS needs. This configuration is possible when there are a small number of users, or system load is low. However, when there are a large number of users spread across a wide geographic region, it may be beneficial to use a multi-site approach. As with all solutions, this approach has benefits and costs.