FCC router ban begs the question: Do you know what’s running in your network?

The FCC’s ban on the procurement of foreign-made routers is being framed as a supply chain security decision. While all new routers procured must meet new standards, it doesn’t require organizations to remove or replace routers already running in their networks.

That makes the problem sound contained: Just adjust procurement and move forward. In practice, it’s not that simple.

The ban surfaces a more practical question: “Do you know what’s running in your network?” Routers sit directly in the critical path of traffic. They carry data between sites, applications, and data centers, and are often left in place for 10 to 15 years.

Over time, configurations change incrementally. Interfaces are added, tunnels modified, access rules updated, but documentation and ownership rarely keep pace.

Lack of visibility

For the people responsible for keeping networks running, that is where the risk sits. Operators configure routers, manage routing behavior, troubleshoot outages, and make changes in live systems where failure is immediate and visible. In many environments, they are not the ones who originally deployed the infrastructure.

They are working with partial records of what was built, how it was modified, and what depends on it. Most organizations are operating without a reliable, current view of what is deployed, what devices are active, how they’re configured, or dependencies.

In many cases, even basic questions are difficult to answer with confidence: which devices are still active, which configurations are still in use, and what systems depend on them. The FCC action doesn’t change the state of existing networks... it exposes it.

Policy is written as if systems are well understood and controlled. Operators know that’s rarely the case. On paper, the network is defined. In practice, it’s inferred.

Networks exposed

When a change is required, that lack of visibility becomes the problem. What starts as a planned change quickly turns into discovery of devices that weren’t tracked, routes still carrying traffic, and configurations no one can fully explain.

In large environments, incremental changes across hundreds of devices compound over time, increasing complexity and risk.

Networks often become fully visible only under stress – during outages, incidents, or failed changes. That’s when hidden dependencies and undocumented configurations surface, not during normal operation.

Without a clear view of the network, teams cannot confidently predict what a change will impact.

This is where changes stall. Teams pause mid-window because they don’t have enough visibility to confirm what is still in use. When visibility is incomplete, something inevitably gets missed. And when it does, the failure is immediate – traffic drops, tunnels fail, applications go offline, and user trust is degraded.

The most consistently exploited risks in these environments remain operational. Risks include default credentials, missed patches, exposed management interfaces, and unmanaged devices. These are targeted because they are easy to find and consistently exploitable.

These risks exist regardless of where a device was manufactured. Regardless of origin, maintenance and everyday usage are the risks consistently exploited as attackers do not need supply chain access when standard conditions already provide a reliable path in.

Supply chain risk becomes relevant when sensitive data traverses infrastructure that may be exposed to foreign control. In those cases, origin matters. But once a device is deployed, the dominant risk factor becomes how well it is understood, configured, and maintained.

Addressing supply chain risk without addressing visibility and operational risk leaves the same exposure in place.

For most organizations, the impact will be gradual. Existing systems will continue to run, and procurement constraints will surface over time through refresh cycles and new deployments. However, when those moments arrive, they depend on an accurate understanding of what is already in place.

How to navigate network changes safely

Most networks are far from clean systems. They resemble a house renovated room by room over a decade, without a full blueprint. New wiring is layered on old, and temporary fixes become permanent.

You don’t see how everything is connected and only find out when flipping one switch how it impacts something unexpected. Organizations can meet security requirements on paper while still operating systems they don’t fully understand. The FCC’s action creates a constraint. It does not create operational readiness.

When change becomes necessary, the challenge will not come from selecting a compliant device; rather, it will be executing the change safely in a network that has evolved without a complete blueprint.

Teams that navigate this well focus on parts of the network where change can be introduced safely and validated under real conditions, rather than attempting broad, high-risk modifications all at once.

The reason the ban does not retroactively apply to routers that were previously approved and are already sitting in your system (that being the ideal way to enact this ban) is simple. Those putting forward the mandate understand that it is not feasible.

This is not a procurement problem; it is a signal to a more fundamental challenge of visibility. This raises the stakes on understanding what is already deployed in networks and the existing risks. The problem becomes about execution, safety, cost and resources.

We've featured the best online cybersecurity course.

This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit