For years, network engineers kept the world running with ingenuity, late nights, and a mountain of scripts. Python, Netmiko, NAPALM, cron jobs — these were the tools that powered backups, diff checks, and mass pushes long before the industry had anything better to offer.

Those solutions were brilliant for their time. They filled the gaps vendors ignored, and they allowed teams to automate when automation wasn’t even a recognised discipline yet.

But the world around us has changed.
Regulators have caught up, networks have scaled beyond human capacity, and customers now expect provable resilience — not “it usually works.”

Today, the issue isn’t whether engineers can script.
The issue is whether organisations can afford to base critical infrastructure on tools that have no authentication, no governance, and no audit trail.

This is the part the industry is struggling to accept:
script-driven NCM has crossed the line from “technical debt” to “compliance risk.”

Why the Script Era Reached Its Limit

The automation culture that dominated the last decade was born from necessity. When your vendor didn’t offer an API, you wrote one. When the CLI changed, you adjusted the regex. When backups needed scheduling, you dropped another job into cron.

But these systems were never designed for identity management, privileged access, or regulatory reporting. They were private tools for internal convenience, not defensible systems for regulated environments.

Most script-driven setups share the same weaknesses: they concentrate knowledge in one or two individuals; they rarely include authentication boundaries; they lack proper change history; and they offer no visibility to leadership. When the person who wrote the automation leaves, the automation ages rapidly — and quietly.

This isn’t a technical judgement. It’s operational reality.

The Security Problem Nobody Can Ignore Anymore

Network automation today doesn’t live in a vacuum. It sits in the path of credentials, device access, policy enforcement, and production control.

And that creates a tension scripting simply can’t resolve.

Most script ecosystems rely on plaintext variables, static credential storage, and unaudited execution. Tools like Oxidized and RANCID — both giants in their day — were built in an era when “auth” meant “IP reachability.” Even popular frameworks like Netmiko and Paramiko assume the engineer is the trust boundary.

That assumption no longer holds.

Modern security models expect:

• identity-based access

• centralised authentication

• provable configuration integrity

• logged actions

• separation of duties

Scripting culture can emulate some of this, but it can’t provide it as a governable system.

That gap is no longer tolerable.

NIS2 and DORA: Where Compliance and Reality Collide

Here’s where the conversation stops being an opinion and becomes legislation.

Under EU NIS2, organisations considered “essential” or “important” — including telecoms, ISPs, hosting providers, and cloud service operators — must implement clear, enforceable practices around configuration, change management, access control, and accountability. ENISA guidance leaves little ambiguity: secure, documented configuration processes with controlled access are required.

Then there’s DORA, the Digital Operational Resilience Act.
For financial and critical entities, configuration integrity, traceability, and verifiable recovery become baseline controls. Regulators expect organisations to demonstrate exactly who made a change, what was changed, when, and under which authority.

A Python script with a connection loop doesn’t satisfy that.
A cron job triggering Oxidized doesn’t satisfy that.
A Git repo containing NAPALM commands doesn’t satisfy that.

The era of “nobody’s ever asked” is over.
Compliance now dictates the minimum standard of tooling.

This is why the topic has moved from engineering forums to the boardroom.

Operational Fragility: The Risk Nobody Talks About

Even without regulation, script-driven automation has a shelf life.

Networks grow.
Vendors change syntax.
Libraries deprecate functions.
The original author moves roles, or moves on entirely.

What remains is a brittle system that works until it doesn’t, often without warning. When things break, there is no audit log, no rollback, no chain of custody — just a scramble to figure out which script did what, and whether it ran at all.

Business continuity can’t be based on “ask the person who wrote it.”

So What Comes Next?

The industry is entering a phase where network configuration management must look more like security infrastructure and less like hobbyist tooling. Organisations need systems that are authenticated, authorised, logged, and reviewable. They need modern UI and API layers, versioning, auditing, reporting, and reliable search. They need software that can be validated, upgraded, secured, and scaled intentionally.

This is the new baseline — not the premium tier.

And it’s why rConfig v8, Pro enterprise and our new Vector editions, exists.

Where Open Source Goes From Here

Open source shouldn’t mean “open access.”
It shouldn’t mean unauthenticated tools or abandoned codebases.

Open source deserves enterprise-grade engineering: clear identity boundaries, RBAC, SSO, config integrity, security-by-design, and yes — compliance alignment.

That’s the direction we’re taking with rConfig Core v8: a modern, secure, open, API-first NCM platform that meets the reality of 2025 rather than the assumptions of 2012. The industry doesn’t need more scripts; it needs accountable automation that regulators, engineers, and leadership can all stand behind.

This isn’t the end of ingenuity.
It’s the beginning of maturity.

Explore rConfig Core v8

GitHub: https://github.com/rconfig/rconfig