The engineer who handled your RADIUS server management has moved on. The system is still running. But did anyone document why it was built the way it was?
Alan DeKok, CEO and Founder, InkBridge Networks
Most RADIUS systems work. That is not the same as saying most RADIUS systems are well managed.
Authentication infrastructure tends to stay invisible until the moment it does not. When something fails, users cannot get online, and suddenly everyone wants to know everything about what the system does and why it was configured the way it is. In most cases, no one can answer that question with any confidence.
This is the retained knowledge problem in RADIUS server management.
What I hear in early conversations
When I am talking with a prospective customer, I can usually tell within a few minutes whether a retained knowledge problem is part of what they are dealing with.
The people who know they have a problem tend to be able to describe it clearly. They will say something like: we have a FreeRADIUS instance that is five years old, it does standard things, the engineer who built it has left, and we need help getting back on top of it. That kind of clarity means there is a real starting point.
The harder conversations are the ones where teams don’t know what they don’t know. The requirements are vague. The description of the current system is vague. When I ask what a particular policy is supposed to do, the answer is vague. Someone did some research, found that RADIUS servers support a certain feature, added it to the requirements list, and cannot now explain what they would actually do with it.
That vagueness is almost always a signal: the system was built by someone who is no longer around, and what remains is the configuration they left behind, plus however many undocumented changes have been layered on top since.
What your configuration tells us
When we begin a support engagement, our team does a configuration review to assess whether the system is set up correctly. A RADIUS configuration is a record of every decision, workaround, and intention of the engineers who built it.
Reading a RADIUS configuration is less like reviewing a document and more like reading a diary.
After doing this for a long time, I have found that systems fall into roughly three types.
1. The surgical configuration
The software was installed, minimal changes were made, and whoever set it up moved on. These organisations tend to have a pragmatic approach to IT: make the change that needs to be made, confirm it works, and leave everything else alone. Support relationships with these customers are usually productive. The surface area is small, and when something goes wrong it is generally findable.
2. The stripped-down configuration
Every module that is not needed has been removed. The policies do exactly what they need to do and nothing else. Teams that run these systems have usually done proper security documentation and have a clear set of requirements. They ask more questions during support, but the questions are good ones. They want to understand the problem, not just get past it.
3. The accumulated configuration
Here you’ll see layers of changes on top of changes, some overlapping, some conflicting, policies written in Perl or Python because someone did not want to learn unlang, logic that branches in ways the current team cannot follow. Reading these is closer to spelunking than reviewing: every room has ten dark tunnels leading off it, and you cannot tell which ones go anywhere useful until you follow each one.
This third type happens when a system grows faster than its documentation, when multiple teams have contributed changes over several years, or simply when the original engineer had particular habits that made sense to them at the time.
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!)
What happens when the original engineer leaves
Three things typically follow when the person who built a RADIUS system moves on.
The most common is paralysis. The system is working, no one is entirely sure why, and the incoming team is understandably cautious about touching anything. This is not a bad instinct. The risk is that caution becomes permanent. Deferred maintenance accumulates, the system drifts further from any documented state, and a forced change eventually creates a crisis that has to be resolved under pressure.
The second is improvisation. Someone starts making changes without a clear picture of the existing design, the business logic embedded in the policies, or why certain decisions were made originally. In RADIUS, those decisions are consequential. A policy that looks arbitrary often encodes a requirement from a specific vendor, a workaround for a particular piece of equipment, or an agreement that predates the current team entirely. Change it without understanding it, and you discover why it existed the moment your users cannot authenticate.
The third, and rarest, is the methodical approach: bringing in people who will do a proper deep dive, understand the existing system, and document what they find. This option is rare because it is hard to justify when nothing appears to be broken. The system is running. What is the problem? The problem is that working and well-managed are not the same thing, which only becomes visible under pressure.
We have written separately about what happens when organisations reach for per-incident support in those moments, and why the break-fix model tends to fail precisely when the knowledge gap is widest.
How InkBridge Networks retains knowledge across years
One of the less obvious advantages of a long-term support relationship is that the knowledge does not live only in the customer’s team. It lives in ours as well.
When InkBridge takes on a configuration review at the start of an engagement, we are learning the RADIUS platform while we audit it for errors. Every subsequent support interaction builds on that understanding. We know what the policies were designed to do, which decisions were pragmatic workarounds, and where the architecture has room to improve.
This matters particularly when a customer’s own team changes. We have relationships with organisations that span more than a decade. In that time, their internal network teams have turned over, sometimes more than once. The engineers involved in the original deployment are long gone. But the context does not leave with them, because we have it too.
The reason InkBridge can sustain this is straightforward: our own team does not turn over quickly. I have been working on FreeRADIUS for 27 years. Other engineers here have been with us for 15. Some of them had 20 years of FreeRADIUS experience before they joined InkBridge.
Our hiring process looks for that kind of depth deliberately, including watching how people engage technically on the FreeRADIUS mailing list for years before we approach them.
The accumulated understanding that comes with long tenure applies just as much to network infrastructure design as it does to the protocol itself. We have written about how architecture decisions age over time and why choices made at deployment tend to have consequences well beyond their original context.
What good RADIUS server management looks like
If you are running a RADIUS server that someone else built and you do not have a clear picture of what it does, don’t wait for something to break.
Rather, start by documenting the current behaviour before you need to change it.
Write test cases for your RADIUS infrastructure. These do not need to be exhaustive. Their purpose is to establish a baseline: what requests the system is handling, what the expected responses are, and where the edge cases live. If you later make a change and a test fails, you know the behaviour shifted and you can make a deliberate decision about whether that was intended.
From there, make sure everything that can fail independently is being monitored. A RADIUS server that cannot reach its database looks identical from the outside to a server that is down entirely. Monitoring should be specific enough to distinguish between the two.
If your team does not have the depth to do this work confidently, a configuration review from engineers who know the system well is a reasonable starting point. It creates the documentation that makes all subsequent support (including long-term managed support) more productive for everyone involved.
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
Don’t "set it and forget it"
So you decided that whatever you were using for network security wasn’t getting the job done… either it didn’t scale with the growth in your user base, devices, or network design, or it was hindering your organization’s productivity. Or maybe you suffered a security breach. Whatever the case, you decided to make the jump to RADIUS authentication, and you’ve implemented a RADIUS server.
Network security architecture lessons from a ten-year breach
When forensic investigators at Sygnia
began piecing together an intrusion for a recent incident response
engagement, the earliest artefacts they found dated to 2016. The
attackers had been inside the network for nearly a decade, undetected and in complete control of the authentication stack.