For a long time, Oxidized and RANCID were the heroes of network automation. They were community-driven, lightweight, dependable, and genuinely ahead of their time. They helped thousands of organisations survive an era when vendors offered little or nothing in the way of automation or modern configuration management.

If you were running a medium or large network in the 2000s or 2010s, these tools probably saved you more than once. I respect that. Every engineer does. Many of us built our early automation skills around them.

But in 2025, we’re dealing with a very different world.
The tools didn’t fail — the world changed.

Regulation, threat models, identity expectations, and business continuity requirements have shifted so far that running Oxidized or RANCID in production is no longer a quirky engineering decision. It’s an organisational risk. A governance failure. In certain sectors, it’s even approaching a compliance violation.

This isn’t personal, unfair, or anti–open source. It’s simply the reality of how networks are governed today.

Let’s break down why these once-great tools can’t defend you anymore — and why regulators, auditors, insurers, and even your own board will increasingly challenge their use.

The Tools Worked. The World Moved On.

To understand the problem, you have to appreciate the context in which these tools were created.

Oxidized and RANCID were built for an era when networks were simple, threats were unsophisticated, and automation wasn’t mainstream. Security frameworks were looser, reporting obligations were lighter, and nobody was expecting a network device backup system to satisfy regulatory or legal requirements.

These tools prioritised function. They did not — and were never designed to — incorporate identity governance, audit logging, authentication standards, data integrity models, or access boundaries. They weren’t intended to satisfy auditors, compliance officers, regulators, or insurers. They existed to solve a practical engineering problem: “Please just gather my configs reliably.”

That was enough then. It is nowhere near enough now.

The Core Problem: They Have No Security Boundary

This is the part that cannot be glossed over.

Oxidized historically shipped without authentication.
If you could reach the interface, you could access the entire system.

Even today, many deployments remain unauthenticated because the tool was never built around identity as a first-class requirement. RANCID sits in a similar category: great for its time, but created long before access control and user attribution were considered mandatory components of any infrastructure platform.

For tools that hold the keys to your entire network — router configs, firewall rules, switch hierarchies, device credentials, operational history — the absence of authentication isn’t a quirk. It’s a structural failure.

And structural failures are where breaches happen.

When a system with this level of access has no identity boundary, no logging, and no oversight, it creates a single point of catastrophic compromise. An internal user, a compromised account, a lateral movement attack, or even a misconfiguration could expose the entirety of your network in one move.

From a CISO’s perspective, this is essentially a breach waiting to happen.
From a CIO’s perspective, it’s an exposure the business cannot justify.
And from a regulator’s perspective, it’s non-compliant on sight.

The Silent Crisis: Credentials and Configs in the Open

If you ask any cyber forensics team what scares them the most, they’ll tell you: credentials stored in plaintext and ungoverned configuration data.

Oxidized and RANCID rely on exactly that model. Device credentials are often stored directly in configuration files. SSH keys are reused for years. Rotation is manual, if it happens at all. The tools assume that whoever has server access is trusted.

This made sense 15 years ago. It’s reckless today.

A compromise of these systems doesn’t just expose your configuration backups — it exposes the ability to change your network. In other words: impact, not just information.

This is why insurance underwriters increasingly scrutinise configuration systems. It’s also why post-incident investigations frequently highlight NCM tooling as a weak point when things go wrong.

No modern security model — zero trust, identity-first, or otherwise — can justify storing the blueprints of your network in a system with no security perimeter.

Maintenance Reality: You Can’t Secure What Nobody Controls

Another uncomfortable truth: these tools simply aren’t maintained at the level modern organisations require.

RANCID is effectively legacy software now.
Oxidized is maintained, but not in the structured, timely, accountable way that enterprise risk frameworks expect.

Businesses relying on these tools are depending on volunteer cycles, inconsistent release schedules, partial documentation, and unscoped future development. For non-critical systems, this may be fine. But for the platform responsible for the integrity of your network configuration — the documentation of your infrastructure — it doesn’t stand up to scrutiny.

When auditors or regulators ask:

• What is your patch schedule?

• How do you ensure the tool is secure?

• Who is accountable for vulnerabilities?

• How do you track and control changes?

—you cannot answer those questions with “open-source volunteers usually fix things pretty fast.”

That doesn’t satisfy ISO 27001.
Or SOC2.
Or PCI.
Or any regulator under NIS2 or DORA.

Governance and accountability aren’t technical luxuries. They’re operational requirements.

The Shift: Network Configuration Is Now a Regulated Function

This is the part most businesses still haven’t internalised.

Under EU NIS2 (Directive 2022/2555) and DORA (Regulation 2022/2554), configuration management has moved from an internal best practice to a formal legal expectation.

Both frameworks are explicit: organisations must maintain secure, controlled, auditable processes for configuration and change management. They must demonstrate identity, accountability, traceability, recovery readiness, and resilience.

These are not optional extras.
They are required controls.

A platform with:

• no authentication

• no access control

• no user attribution

• no audit logging

• no accountable maintainership

• no security boundary

…cannot meet those controls.

No interpretation needed.
No loopholes.
It simply can’t.

This is why the conversation is moving into the boardroom — because the risk has moved there too.

Insurance and Liability: The Hidden Consequence

Cyber insurance providers have one priority: reducing the likelihood and impact of a claim.

If your configuration system has no authentication layer, no audit trail, no ability to verify changes, and no assurance of patching, you will be categorised as high-risk.

The consequence? Higher premiums, reduced payouts, or outright denial after an incident.

This is often what finally convinces executive leadership. Not the technical argument. Not the compliance argument. The financial one.

When the insurer asks,
"Who has access to device backups?"
and the answer is
"Anyone who can reach the server,"

—your organisation is already in breach of its own policy.

If Proposed Today, No Executive Would Approve These Tools

This is the simplest and most damning illustration.

If an engineer walked into a leadership meeting today and said:

“I’d like to store every network configuration, every credential, every routing table snapshot, and the full history of the network in a system that has no authentication, no logging, no change history, no vendor support, and no patch guarantees.”

The answer would not be “Sounds good.”

It would be “Absolutely not.”

Yet thousands of organisations are already running exactly that setup — not intentionally, but by inertia.

Legacy isn’t harmless.
Legacy is risk.

The Way Forward: Maturity, Not Blame

None of this is an attack on engineers or open-source contributors.
Oxidized and RANCID were brilliant. They were necessary. They filled a vacuum, and the community owes them credit.

But the world has changed.
Regulation has changed.
Threats have changed.
Business risk has changed.
CIO and CISO responsibility has changed.

What hasn’t changed is the architecture of these tools.

The industry now needs solutions built for identity, governance, auditability, compliance, and accountability — not just convenience.

This is exactly why rConfig V8 Core exists.
It’s why Pro, Enterprise, and Vector exist.
It’s why the open-source architecture has been rebuilt from the ground up.

The goal isn’t to replace open source.
It’s to modernise it.

To keep what made these tools great, and fix what makes them dangerous.

The Conclusion: You Can’t Defend What You Can’t Control

Running Oxidized or RANCID in production in 2025 is no longer a technical choice.
It’s a governance decision.
A compliance decision.
A liability decision.
One that can expose the business to regulatory action, insurance failure, and operational risk.

This isn’t a debate about taste in tools.
It’s about responsibility.

The tools had their era.
They earned respect.

But they can’t meet the needs of the world we operate in today — and the world regulators expect us to operate in tomorrow.

It’s time for modern, secure, accountable NCM.
It’s time for tooling that can stand up to auditors, insurers, and threat actors alike.
And it’s time for the industry to move from “good enough” scripts and legacy platforms to systems that protect the business — not jeopardise it.

That’s the future we’re building with rConfig.
Open, secure, and built for the world as it is now — not as it used to be.