Your authentication system goes down because the licensing server is unreachable. This happens more than you'd think.
By Alan DeKok, CEO, InkBridge Networks
Your authentication server goes down during a holiday weekend. You’re the only one on call. Now you’re checking: is it a hardware failure? A configuration error? Nope. It’s because the license expired, the licensing server is unreachable, and the vendor isn't responding to queries.
Your entire network is inaccessible. This happens more than you'd think.
Paying for features you'll never use
Commercial servers come with marketing checklists: 10,000 features, 10,000 pages of documentation, endless configuration options.
And you need specific functionality for your network. So the vendor sells you everything they've built for everyone else too. You're subsidizing features that other customers requested. Your license fee pays for the development of features that you don't need.
“Why am I paying for features I don’t use?” Let that question get under your collar.
Here’s an alternative that many customers prefer: get the product, pay an expert for the exact configuration that works for their requirements, know what work was done and what the output is, get only what they want and only what they pay for. No perception of overpaying for bloat.
Think about it differently: why pay for a vendor's entire product catalogue when you only need the parts that solve your specific problem?
When the vendor decides your requirements
We’ve seen a company selling RADIUS servers who realised they could make more money by marking their product as end-of-life every two years. No support unless you upgrade. New version license: $500,000. Migration consulting: $200,000. Repeat this cycle every two years.
After a couple rounds of this, customers switched to FreeRADIUS. The reasons are pretty obvious. You have the source code. It never gets end-of-life'd. You could run it for the next thousand years, presuming the hardware still works. No one takes it away from you.
The licensing model shift makes this worse. One-time licenses became cloud-enabled monthly subscriptions. That’s good for the vendor's recurring revenue, but nearly all customers hate it. Licenses disappear at critical times. You're forced to upgrade, or the system stops working.
This isn't theoretical. I've watched it happen repeatedly. We've helped organisations evaluate Cisco ISE alternatives specifically because of these upgrade cycles and escalating licensing costs.
The screwdriver and duct tape principle
The senior, cynical engineer who's spent 20 years getting burned by bad products has learned to value simplicity: "I can either work with complex closed systems, or I can look at text files. With text files, I can always cobble together tools with screwdrivers and duct tape and get the system back up and running. With a complex system, I’m left at the mercy of the vendor."
They can log into the system using 1980s technology. Edit text files using 1980s technology. Pull out an old VT100 terminal if needed and get things done. That's a huge way to lower risk versus layers and layers of modern tooling.
Modern stacks are fragile. If one layer breaks, you're dead. Chrome uses gigabytes of RAM to render a web page. That's fine for web browsing - if it crashes, you just reload. When your network authentication server goes down due to unmanaged complexity, that affects millions of people who either complain, or give up and switch to a different provider.
Here's a household analogy: your furnace goes down in the middle of winter (or air conditioning in summer). Imagine that to get it to work again, you need some new tool, or the licensing server has to be contacted, or your phone app has to be updated first, or you need an internet connection but there’s an outage for some unrelated reason. Three layers of broken dependencies prevent you from fixing anything.
Versus a system which can be fixed with a screwdriver, wrench, and hammer. You can either fix it, or at least take out your frustrations on the thing with a hammer.
The corporate purchasing trap
I've seen customers buy equipment for corporate reasons or partnership reasons, over the objections of their engineers.
"We saved 20% on equipment!"
The engineers respond: "We're going to lose that money and more on engineering time."
These are different budget buckets, so nobody notices the real cost.
From our perspective, we see customers often overpaying by a factor of two, sometimes a factor of 10, for what they actually need. That's just on licences. Some commercial products are less efficient, so you end up needing more hardware. Now you're not paying 2-10 times the cost - you might be paying 20 times what you actually need.
The information flow between people doing the work and people making decisions isn't always perfect. Sometimes there are decisions made for corporate reasons. I understand that.
What frustrates me is when engineers raise objections, get overruled, and then spend years dealing with the consequences.
Adapting to your world, not the vendor's
Real customers ask: "If we switch to your RADIUS server, do we have to change our user database? Change our business processes?"
Our answer: "Of course not! We'll configure FreeRADIUS to work with whatever database, and whatever schema you have. It’s your data, after all!"
Is the schema username then password? Or username, address, then password? We don't care. It doesn't matter. We tweak one SQL query, and it works. That takes all of 5 minutes to change and test.
Your user provisioning stays the same. Your ticketing system doesn't change. Nothing other than the RADIUS server sees any change. It's that simple.
This matters more than you might think. All too often, commercial products assume specific database schemas. If your schema doesn't match their assumptions, you're looking at migration projects, data transformation, or custom development work. Often at considerable cost.
With flexible configuration, you adapt the software to your infrastructure. Not the other way round.
We've written extensively about how to customise FreeRADIUS for OEM deployments - the same principles apply whether you're embedding it in a product or deploying it in your network.
How often do large ISPs change their RADIUS policies? Rarely to never. Perhaps at most, once every six months, or maybe once a year. What part changes all of the time? Users. Adding users, deleting users, changing user policies. Those changes are all made in the database, and are just user management. They don’t affect the RADIUS server configuration.
This leads us to an open secret in the RADIUS community. Everyone thinks that RADIUS servers are weird, complex pieces of software. And they can be. But in the common ISP case of “check username and password”, the RADIUS server can be thought of as a thin wrapper around the user database. It’s an important wrapper, to be sure. But the bulk of the work is being done by the database.
A RADIUS server is still needed for applying policies, interoperation with different NAS vendors, complex policies, Wi-Fi access, certificate management, multi-site fail over and redundancy, etc. But once a RADIUS server is, set up, nearly all changes are to the user database, which is outside of the RADIUS configuration.
In fact, most ISPs are extremely wary of changing the RADIUS server configuration. While RADIUS isn’t as widely known as DNS or DHCP, it is just as criticial as them. Perhaps even more so, because if RADIUS doesn’t work, then the user can’t even get online to do DNS or DHCP! As a result, ISP systems are designed to clearly separate user changes from policy changes.
Since the bulk of the changes are to the user configuration, the configuration of the RADIUS server rarely needs to change. When changes to the RADIUS server are made, they need to be tested in lab environments, validated, and only then rolled out to production. It’s best to automate these processes, of course.
As for reporting interfaces, most ISP administrators don't even want to see them every day (though they should be there if needed). What they do want: alerts, triggers, which are actionable information that tells the administrator not only that something unusual has happened, but what should be done to fix the problem.
Bug fixes in five minutes versus six months
All of the above is nice, but what happens when something goes wrong? When you call InkBridge Networks for support, you don't a get tier one technician who follows a script of "have you tried turning it off and on again?" You get someone who knows FreeRADIUS in depth. If it's a serious issue, you will usually talk to the exact engineer who built your system after a very short time. That process tightens the timeframe for fixing things dramatically.
We've heard from customers that when they have a product from a large company, feature requests or bug fixes take three months, six months, or a year before they are addressed.
New customers are surprised at how quick our response are. They ask "What do you mean I'm on the phone with you and you fixed the bug and you're pushing it out?”
“Give me five minutes and I'll have a new package you can download."
Yes. That's what we can do. Small company, efficient processes.
If you need minor features urgently, we can roll out a pre-release version to that customer, to work around an issue. Big companies can't do this. Their processes don't allow it.
Nobody's perfect. There will be bugs. The question is: how quickly can you get them fixed? Who controls the timeline? Is the vendor caring about your timeline?
After this experience, customers are shocked at how long they put up with long delays and general unresponsiveness from their previous vendor. Our customer retention rate is therefore extremely high.
Why "no one got fired for buying IBM" keeps people stuck
So what factors keep people using those commercial products?
Fear factor. "I don't know anything about open source - it's scary."
The irony is that HP sells services based on FreeRADIUS. Cisco sells services based on FreeRADIUS (they might not tell you, but they do). Major ISPs with 10M+ users run on FreeRADIUS. The product is stable and widely deployed. But the fear factor prevents many people from ever considering it as an option.
It's easier to stick with a known quantity. Risk analysis seems too hard. No one got fired for buying IBM.
I understand that. I've seen the pattern repeatedly. What I'd encourage people to consider is, what's the actual risk? Running stable software that's deployed globally and tested everywhere? Or running commercial software where your vendor can change licensing terms, deprecate features, or get acquired tomorrow? Each product has its pros and cons. But if you never educate yourself about those costs and benefits, how can you be sure that you’re making the right choice?
If you're considering alternatives to your current authentication infrastructure, we've addressed common concerns about FreeRADIUS and other options based on real conversations with customers who had the same questions.
Start with what you actually need
Ask different questions when evaluating software:
- What do I actually need to accomplish?
- Can I adapt this when my requirements change?
- Who controls changes - me or the vendor?
- What happens if the vendor changes direction?
- Can I keep running this without forced upgrades?
- What's the total cost over five years? Ten years?
Not every product is right for everyone. Commercial products have their place. Sometimes the convenience is worth it. Sometimes corporate requirements demand commercial vendor relationships. Sometimes the additional features genuinely help for your specific use case.
But understand the trade-offs: flexibility versus convenience, ownership versus managed service, adaptation versus acceptance, long-term control versus short-term ease.
The senior engineers who've been around long enough to get burned - they value control. They want to be able to fix things at 2 AM without vendor assistance. They're suspicious of dependencies that can break. They want configuration they can back up, read, and modify.
Those engineers are right to be cautious.
Need help?
InkBridge Networks has been at the forefront of network infrastructure for over two decades. Our team of seasoned experts has encountered and solved nearly every conceivable network access issue. For network authentication built on 25 years of expertise rather than vendor feature checklists, get in touch.
Related Articles
The RADIUS protocol: How it works and why it's secure
Learn how security-by-design improvements have transformed RADIUS into a more secure protocol than the expensive platforms built on top of it.
Stop looking for FreeRADIUS alternatives
Afraid of FreeRADIUS? If worries about support, scalability, and security have you looking for alternatives, FreeRADIUS creator Alan DeKok explains why those fears are unfounded.