The Secure Way to Manage Configs and Admin Secrets at Scale

A new site opens. The network comes up. Wi-Fi works. The phones ring. People can do their jobs.

Then a few months pass.

A vendor needs a “quick” firewall change to finish an install. Someone swaps an ISP circuit and makes a temporary adjustment to get traffic flowing. A switch gets replaced after a failure and is configured in a hurry because the site is down. No one writes it down because there is another location opening next week.

Nothing about that is unusual. It is how multi-location IT actually works.

But once you are operating 25+ locations, those small one-off changes stack up. And they create two problems that show up fast at the executive level:

• Configuration drift: sites slowly stop matching the standards you think you have

• Admin secrets sprawl: privileged passwords and keys end up scattered across people, vendors, devices, and documents

This is where “IT hygiene” becomes a business risk issue. Drift drives outages and slows troubleshooting. Secrets sprawl expands your attack surface and makes offboarding painful. Both make audits and integrations harder than they need to be.

This article is a tighter, field-tested way to think about config management and admin secrets management, built for real-world multi-site growth. No perfection required. Just a system that holds up under pressure.

A lot of config management content is written for cloud and data center environments, where the infrastructure is controlled and repeatable. Multi-location reality is different.

Every site is a little different. Carriers vary. Closets vary. Building conditions vary. Vendors vary. And the pace of change is constant, especially if you are opening new offices or acquiring them.

That is why config management at scale is less about “being tidy” and more about being able to answer two basic questions quickly and confidently:

1. What is running at this site right now?

2. Who has admin access right now?

If those answers are slow or uncertain, your organization is relying on tribal knowledge. That works at five locations. It breaks at 50.

If your current network is built on "tribal knowledge," reach out to see how we can help you transition to a field-tested system designed to handle the realities of multi-location scale.

Drift rarely happens because someone is reckless. It happens because urgency wins.

A site is down and someone makes the fastest change to restore service. A vendor pushes for an exception to meet a deadline. A circuit handoff changes and you adapt on the fly. A replacement device shows up and you rebuild from memory.

Each change makes sense in the moment. The problem is what happens after.

If the change is not recorded, reviewed, and validated against a baseline, it becomes part of the environment. Over time, every location becomes its own special case.

That leads to predictable pain. Troubleshooting takes longer because the “same” site behaves differently. Security controls become inconsistent because the same policies are not enforced everywhere. Audits become manual because evidence is scattered or missing. And acquisitions take longer because you inherit unknown configurations and unknown access.

Drift is not a one-time mistake. It is a process. You either manage it intentionally, or it manages you.

If drift is a slow leak, secrets sprawl is the open valve.

In multi-location environments, admin access tends to spread in familiar ways. Shared local admin credentials get reused across sites because it is convenient. Vendors keep passwords because they “need it to support the system.” Device credentials end up in spreadsheets, documents, or personal vaults because there is no single place everyone trusts. And after an acquisition, inherited passwords often linger with unclear ownership because the priority is getting the doors open, not cleaning up access.

The biggest issue is not “password policy.” It is blast radius.

When privileged access is shared and loosely tracked, basic questions become hard to answer. Who still has access after a vendor relationship ends? What happens if a contractor’s laptop is compromised? Can you prove who accessed a critical system and when? How fast can you rotate credentials after a key employee leaves?

That is not theoretical. Those are the exact questions you get from leadership after an incident, from auditors, and from cyber insurance.

​Here is a definition that works across dozens of sites, not just on paper:

Config management is the ability to deploy a known baseline, control and record changes, and prove what is running at each location over time.

Notice what is not in that definition: perfection. No one is claiming every site will be identical. The goal is consistency where it matters, and visibility where it cannot be identical.

The simplest way to build that capability is to focus on four elements:

1. A baseline you can actually deploy

2. A clean way to handle exceptions

3. Validation so drift does not hide

4. Evidence so you can prove what you have

If any of those are missing, your “standards” are just intentions.

The baseline is your “default” configuration for a site type. Think of it as your starting point for any new site, conversion, or replacement device.

A good baseline does not need to be fancy. It needs to be clear, usable, and realistic for the physical world.

For most organizations, the baseline should cover the common foundation pieces. That includes how WAN connectivity is handled, including typical carrier scenarios, along with a clear firewall policy structure and segmentation approach. It should also spell out switch conventions like VLAN naming, port profiles, uplinks, and management access, plus Wi-Fi standards that address authentication, guest access, and isolation expectations. Finally, it needs logging and remote management expectations so you can support sites consistently.

You will have more detail in the engineering version. But the baseline should also exist in a form your team can execute across regions and vendors without reinventing it every time.

The best test is simple: could a competent technician follow this at a new site and produce a predictable result?

Multi-location IT always has exceptions. Some sites have legacy cabling. Some have odd carrier handoffs. Some have building constraints. Some have a business need that breaks the default.

The mistake is pretending exceptions are rare, then handling them informally.​

Exceptions are fine. Hidden exceptions are not.

A healthy program makes exceptions visible and accountable. You should be able to point to what is different at a site and why it is different, who approved the deviation, and whether it is meant to be temporary or permanent. Just as important, exceptions need to be revisited when the site changes or when standards evolve so yesterday’s workaround does not become tomorrow’s mystery.

This is where many organizations quietly lose control. Not because they allow exceptions, but because exceptions are not tracked and reviewed. They turn into drift.

If your program relies on humans remembering to compare configs, it will not scale. Validation is what turns a baseline into an operational reality.

Validation does not have to be heavy. It can be scheduled, sampled, or event-driven. What matters is that it happens consistently.

Event-driven validation is especially effective in multi-location environments because drift often shows up right after specific moments of change. ISP changes and circuit cutovers, firewall replacements, and switch swaps or closet rework are all common triggers. Vendor installs can also introduce drift when they require changes to routing, ports, or firewall policies. Acquisitions and conversions are another big one, because you are inheriting equipment, configurations, and access patterns that were never built to your standards.

If you validate after those events, you catch drift while it is still small and easy to fix, before it turns into a mystery later.

Most IT teams can write standards, few have the "flex capacity" to deploy them consistently across regions. Let MellinTech handle the physical and operational heavy lifting of your next rollout.

Engineers often underestimate how valuable “proof” is for leadership.

Executives do not want to hear “we think most sites follow standards.” They want to hear “here is how we know,” especially when audits, insurance renewals, or acquisitions are in play.

Evidence is not just for auditors. It is how you run a grown-up multi-location environment. When you have a reliable device inventory for each site, clear configuration versions and change history, and a record of who approved changes and why, you stop guessing. You can quickly see which locations are out of compliance and what the plan is to bring them back in line. You can also confirm when credentials were last rotated and who owns them, instead of discovering problems during an incident or an audit.

When you have that, you can make decisions faster and report risk honestly.

Acquisitions are where weak config and secrets practices become painfully visible.

The business needs the acquired sites online quickly. The common move is to connect the acquired network into the corporate environment and plan to “standardize later.”

That approach is fast in the short term, but it can be expensive and risky in the long term. You are bringing unknown configurations and unknown credentials into your environment before you have visibility and control.

A safer approach is to treat M&A onboarding as a conversion pipeline. Start by establishing visibility into what is there and who has access so you are not guessing about configurations or inherited credentials. Next, put baseline controls in place so the site can operate without becoming an unmanaged risk. Then standardize and fully integrate once you have confirmed the environment is aligned to your standards and you can support it predictably.

You can still move quickly, but you are not collapsing “unknown” into “trusted” on day one.

This also creates a repeatable playbook. When M&A is part of your growth strategy, repeatability is a competitive advantage.

Don't let your next acquisition become a security liability. Stop connecting "unknown" networks directly into your trusted corporate environment. Connect with an M&A Integration Expert.

Secrets management fails in multi-location organizations for one simple reason: it becomes a cleanup project. And cleanup projects lose to daily operations.

Instead, treat secrets management as part of your operating model. The goal is not to make life harder. The goal is to make access controlled, understandable, and easy to revoke.

A practical approach comes down to four decisions.

Every device and critical system has an internal owner, even if a vendor supports it. If no one owns it, rotation and offboarding will not happen.

Shared credentials make troubleshooting easy in the moment and accountability impossible later. As you scale, that tradeoff becomes unacceptable.

The best rotation policy is tied to moments that matter: acquisition close, employee departure, vendor transition, suspected compromise, or major infrastructure change.

Break-glass access is not a weakness if it is handled correctly. It is a safety mechanism. It should be protected, monitored, and reviewed.

Once those decisions are made, the tools and processes become easier to implement because you are solving the right problem.

Multi-location config management is not only a software problem.

Standards break when closets are undocumented, labeling is inconsistent, cabling is unknown, racks are overloaded, and device replacements happen under pressure. That physical reality is what creates the exceptions and one-off changes that lead to drift.

This is where a lot of IT teams get stuck. They can write standards. They cannot execute them consistently across regions, vendors, and site conditions with a small internal team.

That gap between “standard” and “field reality” is where multi-location programs succeed or fail.

If you want progress fast, aim for a system you can run, not a document you can admire.

Start with one site type and one baseline. Prove you can deploy it consistently. Then expand.

Here is a simple sequence that works well:

1. Define the baseline for your most common site type

2. Decide what can vary and how exceptions will be recorded

3. Centralize inventory, ownership, and config version tracking

4. Establish event-based triggers for validation and credential rotation

5. Validate a sample set of sites, fix what you find, and repeat

The win is not “everything is perfect.” The win is that drift becomes visible and manageable, and admin access becomes governable.

MellinTech supports multi-location organizations with 25+ sites. We are a technology partner for the physical and operational work that makes standards real across locations.

That includes:

• Designing and installing site connectivity during new construction

• Executing repeatable standards across regions during rollouts and M&A conversions

• Keeping environments consistent through moves, adds, and changes without disrupting operations

In other words, we help teams close the gap between policy and field execution. Because that is where config management and secrets management either hold up, or quietly fall apart.

At scale, config management is not about being tidy. It is about keeping growth from turning into operational debt and security exposure.

When you can deploy a baseline, control exceptions, validate changes, and prove what is running at each site, you get a network that is easier to operate and faster to integrate.

When you control admin secrets with ownership, event-based rotation, and clear access rules, you reduce risk without slowing the business.

And when both are built into the way you open, convert, and maintain sites, you stop relying on heroic effort and start relying on a system.

If you are expanding locations, upgrading technology across regions, or integrating acquisitions, that system is one of the best investments you can make.