On-premises vs commercial operator: a sovereignty question

A dedicated 5G service can give a critical facility reliable connectivity, predictable performance, and a level of traffic isolation from the public network. But there is a question that often gets less attention during procurement: who actually controls the infrastructure behind that service?

The answer matters when connectivity is critical to operations. A commercial 5G service may be dedicated to your organization, but the infrastructure supporting it can still belong to and be operated by the telecom provider. If an outage affects the public network, the service built on top of it can be affected too.

Consider a production site during a severe storm. A macro tower serving the area loses power, its backup batteries run out, and the backhaul is interrupted. The site's dedicated 5G service goes down with it. Production stops, not because anything failed inside the facility, but because its connectivity ultimately depended on infrastructure several kilometers away, outside the organization's control.

This highlights a distinction that matters for defense and critical infrastructure: having dedicated connectivity is not the same as controlling the network that provides it. And this is where the underlying architecture becomes important.

"Private network" gets used loosely, and that's part of the problem. A private APN, a dedicated 5G service based on network slicing, a dedicated radio access network with a shared core, and a fully standalone infrastructure can all be presented to customers as forms of "private connectivity". But they leave very different amounts of control with the organization.

A network can be private in terms of access, meaning your traffic doesn't mix with anyone else's, without being sovereign in terms of infrastructure, administration, or control.

This is where network slicing comes in. Technically, a network slice is a logically separated portion of a mobile operator's 5G network that can be configured for a specific customer or use case. From the customer's perspective, it can look and behave like a dedicated service: defined performance characteristics, traffic isolation, and specific policies.

But the underlying infrastructure, including the operator's 5G Core, remains part of the operator's network.

That distinction is easy to miss in a procurement conversation. The customer buys a dedicated 5G service; technically, that service may be a slice of a much larger public network. If that public infrastructure has a failure or if access to the operator's core is disrupted, the customer's dedicated service can be affected as well.

The real question, therefore, is not simply whether a network is "private". It is where the critical network functions are located, who operates them, and who has the authority to control them.

In practice, customers evaluating dedicated 5G connectivity typically encounter three architectures, a distinction SMA-RTY discussed recently in a feature on La Repubblica.

• Network slicing: a dedicated service delivered through the operator's existing public network. A logically separated portion of the infrastructure is configured for a specific customer. The organization gets dedicated connectivity without owning the underlying network.
• Hybrid RAN: a dedicated radio access network on the customer's premises, combined with an external core. The organization gets its own antennas and radio infrastructure, but the core network (responsible for authentication, session management, policies, and routing) remains with the operator, typically in remote sites.
• Standalone on-premises: an independent private 5G network, with both the radio access network and the 5G Core deployed specifically for the organization, on its physical premises or within infrastructure it controls exclusively.

The difference is not simply how much equipment physically sits on-site, but how far the organization's control extends into the network architecture itself.

Only the standalone model removes the dependency on the operator's core and its day-to-day network control. It doesn't remove every technical dependency: a local infrastructure still needs power, backhaul, hardware maintenance, and software updates. But it radically changes who decides how the network operates and where critical functions reside. That is the architectural model NGCI is built on.

A standalone private 5G network, like NGCI (Next-Generation Communication Infrastructure), moves the 5G Core on-premises. Authentication functions, security policies, and the infrastructure managing network credentials and keys all run on infrastructure the organization owns and operates, located where the organization decides.

In practice, this means local traffic can be authenticated and routed entirely within the controlled perimeter, without requiring an external operator's core. The organization can define who has administrative access to the network and under what conditions, rather than delegating that decision to a commercial operator.

It also changes how security policies are managed. Credentials, keys, authentication policies, and traffic controls can be configured within the organization's own infrastructure instead of being inherited from a provider's standard operating model.

The distinction can be thought of simply: a dedicated service gives you a reserved lane; an on-premises network gives you control of the road itself.

That does not make an on-premises network independent from everything else. It means the organization can decide which external dependencies are necessary, and which are not.

This is usually where the objection comes in. Isn't a private network still dependent on something external for long-range connectivity? Doesn't it eventually need an external backhaul, perhaps a satellite link, to talk to the rest of the world?

It depends on what the network is being asked to do. Network operation and external connectivity are two separate questions. For local tactical operations, an on-premises standalone network doesn't need external connectivity at all: it can authenticate, route, and serve traffic entirely within its own coverage area. External links, whether satellite, fiber, or microwave, become optional, used to reach beyond the site rather than required for the network to function at all.

That distinction matters more than it might seem. A network that needs external connectivity to operate has a dependency sitting outside the organization's control by design. A network that can operate without it has one less variable to manage when conditions get difficult.

For defense operators, data sovereignty tends to get filed under legal or compliance: something to verify before signing a contract. That framing captures only half of what's actually at stake. Where data is processed and routed, who can administer the infrastructure, and which jurisdiction governs that access all determine, in practical terms, whether an adversary or a foreign authority could ever compel disclosure of tactical traffic. That's data sovereignty.

The other half is operational sovereignty: who owns, configures, and can disable the infrastructure itself, independent of where the data happens to sit. A network can tick the data sovereignty box, with servers on national soil, and still depend on a foreign vendor's cloud for management and orchestration. An on-premises standalone network can meaningfully narrow that gap by keeping infrastructure, credentials, and administrative control within the organization's own network boundary. It doesn't erase every third-party dependency, hardware vendors and software updates still exist, but the administrative and processing path becomes short enough to be monitored, audited, and controlled directly.

None of this argues that commercial networks are unfit for every purpose. Plenty of defense-adjacent activity doesn't require this level of control, and building standalone infrastructure everywhere would be neither practical nor necessary. The value of a standalone private network isn't that it makes an organization independent from everything. It's that it lets the organization decide which dependencies it's willing to accept, and which ones it isn't, instead of having that decision made by a commercial contract.

If your team is evaluating how network control and data confidentiality are handled in critical environments, we're glad to walk through the technical details: no generic sales pitch, just an open comparison of what changes on-premises versus with a commercial operator.