Why do appliance-based SD-WAN designs often create the same problems after a refresh?

Why the refresh does not remove the operational burden

Appliance-based SD-WAN often feels new after a refresh, but the operating model usually is not. A new box still needs patching, upgrade coordination, hardware replacement planning, site-by-site administration, and change control, so the refresh resets equipment age without resetting the lifecycle work around it.

That is why the same pain reappears in a different form. The organisation may get better throughput or supportability, but it still owns a distributed fleet that must be kept current, monitored, and retired on schedule.

SASE and SSE Guide is useful here because it shows how SD-WAN fits into a broader access and traffic-steering architecture, which is often where appliance refreshes either simplify or multiply the operational burden.

In practice, the refresh changes the asset, not the responsibilities attached to it. If the architecture still depends on per-site appliances, the team is still running a hardware lifecycle, just with a newer generation of hardware.

What actually repeats after a box replacement

The recurring work is usually predictable: software patching, firmware updates, replacement forecasting, rollback planning, and local troubleshooting when a site behaves differently from the standard build. Those tasks do not disappear just because the old appliance was swapped out.

This is also why refresh projects can create a false sense of progress. The organisation may complete the procurement and rollout phase, then discover that the real cost sits in the steady-state admin model, where every appliance still has to be governed as an individual operating unit.

For teams that want a reality check on the control burden, the NIST SP 800-53 Rev 5 Security and Privacy Controls catalog is a useful reference because it reflects the control expectations behind maintenance, configuration, monitoring, and change discipline.

NIST Cybersecurity Framework 2.0 is also relevant because the issue is not just the device itself, but the organisation's ability to govern, protect, detect, respond, and recover across a distributed operational footprint.

When appliance refreshes are treated as a one-time fix, the team often underestimates how much patch cadence, site variance, and retirement planning remain embedded in the design.

When appliance-centric design becomes a governance problem

The deeper issue is governance consistency. An appliance model spreads responsibility across sites, vendors, contracts, and maintenance windows, which makes it harder to keep policy, version state, and operational ownership aligned over time.

That matters because the refresh cycle can mask accumulated debt. Older appliances are replaced, but configuration drift, uneven update timing, and site-level exceptions can remain, so the environment keeps inheriting the same management complexity in a new wrapper.

NIST Cybersecurity Framework 2.0 fits this point well because it frames the issue as ongoing governance and operational resilience, not just product replacement.

Breach and Attack Simulation (BAS) Guide is also relevant for validating whether the refreshed design actually reduced exposure, because control validation is often the only way to prove that the new appliance estate is performing better than the old one.

The practical takeaway is that appliance refreshes should be judged by whether they reduce the number of things the organisation must manually govern, not just by whether they improve the hardware spec sheet.

Practitioner Guidance

What to verify: Check whether the refresh has changed the operating model or only the hardware. If patching, replacement planning, local break-fix handling, and exception management still sit with the same teams, the redesign has not reduced lifecycle burden.

What to prioritise: Focus first on whether the architecture is standardised enough to reduce site-by-site variance. A refresh that preserves custom per-location handling usually preserves the same long-term maintenance cost, even if initial deployment looked cleaner.

Decision rule: If the main business case is lower operational overhead, require evidence that the refresh removes recurring administration tasks, not just that it replaces ageing appliances with newer ones. If it does not, treat the proposal as a hardware update, not an operational simplification.

Practitioner takeaway: The real test is whether the refresh shrinks the governance surface area. If the answer is no, the organisation has modernised the box while keeping the same lifecycle burden.

Related resources from NHI Mgmt Group

• Why do browser-based login flows often create session problems in mobile apps?
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?