TL;DR
- Dropped or slow IPsec tunnel setups under load signal a gateway that's hit its scaling limit.
- A throughput ceiling during peak traffic often shows up as latency spikes rather than outright outages.
- Rising power and cooling costs at scale usually point to software-based encryption rather than hardware acceleration.
- Inability to isolate traffic by tenant or network slice limits how a gateway supports Private 5G and neutral-host deployments.
- Manual, tunnel-by-tunnel policy management and no path to quantum-ready encryption both signal a gateway that wasn't built for carrier scale.
Most operators don't replace a security gateway (SecGW) because it fails outright — they replace it because it quietly stops keeping up. The signs show up as degraded performance, rising costs, and manual workarounds long before anything actually breaks. Here are seven to watch for.
IPsec Tunnels Are Failing to Establish or Timing Out
Every RAN element connecting to your core needs its own IPsec tunnel[1]. If tunnels are timing out during setup, or existing ones drop under load, your gateway has likely hit its maximum tunnel count or setup rate — not a software bug you can patch around.
This becomes more visible as you add cell sites, small cells, or O-RAN radio units faster than your gateway's rated tunnel capacity.
Tunnels that degrade under load time out before they ever reach the gateway.
You're Hitting a Throughput Ceiling During Peak Traffic
A gateway that handles average load fine but degrades during peak hours is throughput-constrained, not just under-provisioned. This usually shows up first as latency spikes on time-sensitive services rather than a hard outage — which makes it easy to miss until customers notice.
If your gateway also lacks built-in DDoS protection, peak legitimate traffic isn't the only thing that can push it past its limit. We go deeper on why IPsec throughput specifically breaks down under 5G traffic loads in an upcoming post.
Power and Cooling Costs Are Climbing as You Scale
If adding tunnel capacity means a proportional (or worse) jump in power draw and cooling load, your gateway is likely relying on software-based encryption rather than hardware acceleration. This is one of the more expensive signs to ignore, since it compounds with every expansion rather than showing up as a one-time cost.
Software-based encryption needs more rack, more power, and more cooling than a hardware-accelerated appliance doing the same work.
Your Gateway Can't Isolate Traffic by Tenant or Slice
As Private 5G and neutral-host deployments serve multiple tenants over shared infrastructure, a gateway needs to enforce separate security policies per tenant, slice, or traffic plane. If yours applies one flat policy to everything crossing it, it wasn't built for multi-tenant environments — see how network slicing strengthens 5G security for what proper isolation looks like.
One flat policy leaves tenants sharing a lane; per-tenant policy isolates each one on the same gateway.
There's No Path to Quantum-Ready Encryption
Encrypted traffic captured today can be decrypted later once quantum computing matures — a risk NIST's Post-Quantum Cryptography standards[2] are designed to close off. If your current gateway has no roadmap for Post-Quantum Cryptography (PQC) or Quantum Key Distribution (QKD), you're accumulating risk on every long-lived session it encrypts today. We cover this in more detail in an upcoming post on quantum-ready encryption.
Security Policy Is Managed Manually, Tunnel by Tunnel
Zero trust architecture assumes no connection is implicitly trusted and every session is authenticated on its own terms[3]. If your team is still configuring policy per tunnel by hand rather than through centralized, automated enforcement, that's not just an operational drag — it's a zero trust gap waiting to be exploited as your tunnel count grows.
You're Locked Into a Single Vendor's Proprietary Hardware
Open, multi-vendor architectures like O-RAN were built specifically so operators aren't locked into one vendor's closed ecosystem, with the O-RAN Alliance publishing open interface specifications for exactly this reason[4]. If your gateway only interoperates with a single vendor's RAN or core equipment, upgrading any one piece of your network means renegotiating the whole stack. We compare Nybsys's own hardware tiers — ISG 7010, 7015, and 7030 — in an upcoming post so you can see what fitting the gateway to your deployment scale actually looks like.
Ready to check your network against these signs?
If two or more of these sound familiar, it's worth evaluating a purpose-built platform to see where your current setup stands.
Request a demo of the Aegis Security Gateway →Frequently Asked Questions
How do I know if my security gateway has hit its tunnel limit?+
Look for tunnels timing out during setup or dropping under load, especially as you add new cell sites or radio units. This points to the gateway reaching its maximum tunnel count or setup rate, not a fixable software issue.
Is a throughput ceiling always obvious as an outage?+
No. It often shows up first as latency spikes on time-sensitive services during peak traffic, which is easy to miss until it affects customers directly.
Why do power costs increase disproportionately as some gateways scale?+
Gateways relying on software-based encryption instead of hardware acceleration typically see power and cooling costs rise faster than the tunnel capacity they're adding.
What does it mean if a gateway can't isolate traffic by tenant?+
It means the gateway applies one flat security policy to all traffic, which doesn't work for Private 5G or neutral-host deployments that need separate policies per tenant or network slice.
Is vendor lock-in really a security gateway problem?+
Yes — if your gateway only interoperates with one vendor's proprietary hardware, you lose the flexibility that open, multi-vendor architectures like O-RAN were designed to provide.
References
- IETF — Security Architecture for the Internet Protocol (RFC 4301). datatracker.ietf.org/doc/html/rfc4301
- NIST — Post-Quantum Cryptography project. csrc.nist.gov/projects/post-quantum-cryptography
- NIST — Zero Trust Architecture (SP 800-207). csrc.nist.gov/pubs/sp/800/207/final
- O-RAN Alliance — Specifications. o-ran.org/specifications