Zero Trust Security at the RAN-to-Core Boundary: Where the Gateway Fits

Zero trust is one of the most-used phrases in network security, and one of the most abstract. It's usually explained as a policy or a mindset — "never trust, always verify." That's correct, but it leaves out a practical question: at the boundary between your radio access network and your core, what actually enforces it? This post answers that — where zero trust stops being a principle and becomes an enforced control.

Zero Trust Is More Than Identity and Access

Most zero trust explanations center on people: verify the user, check the device, grant least-privilege access. That's the identity-and-access layer, and it matters — it's the core of zero trust security as most teams first encounter it, and it's consistent with the architecture NIST lays out in SP 800-207^[1].

But zero trust also applies at the network layer, below individual user sessions. Here it means something more specific: no traffic segment is trusted just because of where it sits in the topology. A packet arriving from a radio unit isn't trusted simply because that radio unit is inside your network. It has to be authenticated on its own terms, every time. That network-layer interpretation is the one that matters at the RAN-to-core boundary.

Why RAN Elements Can't Be Implicitly Trusted

In a traditional enterprise network, "inside the perimeter" once implied "trusted." A distributed radio access network breaks that assumption completely.

Radio units, small cells, and O-RAN elements are physically distributed — mounted on rooftops, poles, and remote sites — and their backhaul often crosses public or shared infrastructure the operator doesn't fully control. O-RAN's open, multi-vendor interfaces widen this further, which is why the O-RAN Alliance publishes dedicated security specifications^[3] for those interfaces. A radio element sitting on a third-party rooftop, connected over the public internet, is not meaningfully "inside" anything. Treating it as trusted because it belongs to your network is exactly the assumption zero trust exists to remove.

This is why the RAN-to-core boundary is the natural place to enforce zero trust: it's the point where traffic from many untrusted-by-default radio elements converges before entering the core.

Where the Gateway Fits: The Enforcement Point

A principle needs a place to be applied. At the RAN-to-core boundary, that place is the security gateway (SecGW).

The gateway enforces zero trust in concrete terms. It authenticates every IPsec tunnel individually — following the security architecture defined in IETF RFC 4301^[2] — so a radio element has to prove it's legitimate before its traffic is allowed toward the core. It doesn't grant trust based on network location. And it does this per tunnel, at the scale of thousands of distributed nodes, which is what makes zero trust workable rather than theoretical at carrier scale.

In other words: zero trust says "authenticate every connection." The SecGW is the component that actually does it, for every radio element, at the boundary. That's the difference between a security policy and a security control.

Why This Matters Most in Multi-Tenant and Neutral-Host Deployments

Zero trust at the boundary becomes essential the moment more than one party shares the infrastructure. In a neutral-host deployment, several operators or tenants run over shared radio infrastructure — and a single flat trust policy across all of them is a liability, not a convenience.

Here the gateway's per-tunnel authentication pairs naturally with network-slice isolation. Network slicing separates traffic into isolated virtual networks, and zero-trust enforcement at the gateway ensures each slice's traffic is authenticated and kept to its own policy boundary rather than implicitly trusting anything that shares the physical network. Together they turn "shared infrastructure" from a trust problem into a managed one.

For teams standing up shared or private deployments, this connects directly to the security fundamentals covered in our private 5G security primer. And we go deeper on the throughput engineering that lets a gateway authenticate every tunnel without becoming a bottleneck.

Frequently Asked Questions

References

1. NIST SP 800-207, Zero Trust Architecture — csrc.nist.gov/pubs/sp/800/207/final
2. IETF RFC 4301, Security Architecture for the Internet Protocol — datatracker.ietf.org/doc/html/rfc4301
3. O-RAN Alliance Specifications — o-ran.org/specifications