TL;DR — What to verify before deployment
- Size the platform for active tunnels, encrypted throughput, packet rate, tunnel setup, rekey activity, latency, and high-availability reserve — not simply whether it "supports IPsec."
- Treat GSMA NESAS as security assurance and product-evaluation evidence, not as a blanket certification or guarantee of security.
- Use the SecGW as one policy-enforcement point within a broader zero trust architecture; tunnel authentication by itself is not zero trust.
- Benchmark energy and thermal behavior under production-like encrypted workloads, including small packets and failover capacity.
- Demand demonstrated interoperability across the intended RAN, transport, core, PKI, routing, monitoring, and orchestration environment.
Most SecGW evaluations fail quietly. A platform passes a demo, clears procurement, and then struggles the first time it faces real tunnel scale, a security audit, or a multi-vendor RAN. The five mistakes below are not exotic — they are predictable evaluation gaps. Each can be reduced by defining measurable acceptance criteria before procurement and repeating those tests under production-like conditions before rollout.
Evaluating a SecGW Like a Generic Firewall or Enterprise VPN Appliance
What goes wrong
A feature checklist that says "supports IPsec" is not enough. In many mobile-network architectures, a Security Gateway protects IP traffic crossing between network security domains. 3GPP TS 33.210[1] addresses network-domain security at the IP layer, while IETF RFC 4301[2] defines the broader IPsec security architecture. A SecGW must translate those foundations into the scale, availability, and operating model required by the target network.
Enterprise firewalls and VPN appliances may be excellent products for their intended workloads. The mistake is assuming that support for the same protocols proves suitability for carrier or distributed-RAN traffic. Production behavior depends on tunnel concurrency, tunnel churn, packet size, cipher suite, packets per second, routing, logging, and high-availability design — not peak throughput alone.
Figure 2. Neutral validation scorecard for comparing a branch VPN appliance with a carrier-grade SecGW. Populate the fields with tested results for tunnel scale, setup and rekey rates, encrypted throughput, packet rate, and failover.
What to measure
- Maximum concurrent active IPsec tunnels under the intended configuration.
- IKEv2 tunnel-establishment rate and sustained tunnel-churn rate.
- Rekeys per second during routine rotation and synchronized rekey events.
- Encrypted throughput and packets per second across realistic packet-size distributions.
- Latency and jitter under steady load, peak load, logging, and inspection features.
- Performance with the required cipher suites, certificate sizes, and policy complexity.
- Capacity with high availability enabled and the reserve required after a node failure.
- Failover recovery time, routing convergence, and tunnel or session continuity.
Evidence to request
- A complete test methodology, including packet sizes, traffic direction, cipher suites, tunnel age, logging settings, and failure conditions.
- Results from production-scale or customer-witnessed testing rather than a lightly loaded feature demonstration.
- Clear statements of hard limits, licensed limits, and performance assumptions.
Skipping Independent Security Assurance and Product Evaluation
What goes wrong
Deployment pressure can make a vendor's security claims feel sufficient. They are not a substitute for evidence. GSMA's Network Equipment Security Assurance Scheme (NESAS)[3] provides a common framework that audits a vendor's product-development and lifecycle processes and supports security evaluation of specific network products by authorized laboratories using defined requirements and test cases.
NESAS does not accredit or certify equipment vendors or their products. Laboratory accreditation is separate. Operators should describe NESAS as an assurance and evaluation scheme, then verify the exact vendor, product, software version, scope, requirements, and results that apply.
Figure 3. The evidence trail a vendor should be able to demonstrate across the full gateway lifecycle — certificate enrollment, IKEv2 establishment, routine rekeying, certificate rotation, transparent failover, revocation, and audit logging.
Evidence to request
- Which exact product and software version were evaluated.
- Which security requirements and test cases were included or excluded.
- Which authorized laboratory performed the evaluation and what results are publicly available.
- How the vendor handles secure development, vulnerability disclosure, remediation, signed software, secure boot, software bills of materials, and update integrity.
- Whether the operator's intended configuration introduces functions or integrations outside the evaluated scope.
A product without NESAS evidence is not automatically insecure. It does mean the operator must obtain equivalent assurance through other evidence and testing rather than treating the vendor's claim as independently established.
Treating Tunnel Authentication as a Complete Zero Trust Strategy
What goes wrong
A SecGW can be an important policy-enforcement point, but it is not a complete zero trust architecture. NIST SP 800-207[4] emphasizes protecting resources and making authentication and authorization decisions without granting implicit trust based only on network location or ownership. An authenticated tunnel proves selected facts about the connection; it does not automatically prove that every flow inside the tunnel should reach every service.
A flat policy may look acceptable during a single-tenant pilot. The weakness appears when the network adds another tenant, a neutral-host arrangement, a new operational technology environment, or a network slice with different security and compliance requirements.
Figure 4. Zero trust policy flow in which an identity and trust layer and a policy decision layer drive the security gateway as policy enforcement point for each tenant and network slice, Identity and context inform policy decisions; the SecGW enforces least-privilege access and exports separate logs and telemetry.
What to design before rollout
- Identity and credential model for RAN elements, sites, tenants, services, administrators, and automation systems.
- Least-privilege policies by tenant, slice, device role, site, service, and management function.
- Separate data-plane, control-plane, and management-plane protections where the architecture requires them.
- Policy-decision and policy-enforcement responsibilities, including how policy changes are approved and audited.
- Logging, telemetry, alerting, and incident evidence for denied access, certificate failure, policy changes, and unusual tunnel behavior.
- A revocation and quarantine process for compromised devices, sites, credentials, or software versions.
Compare candidate platforms using measurable criteria for tunnel scale, failover, security assurance, segmentation, energy efficiency, observability, and interoperability.
Evaluating Purchase Price Without Measuring Production Energy Efficiency
What goes wrong
A low appliance price does not guarantee a low operating cost. Energy consumption and cooling requirements depend on the platform design and workload: encrypted throughput, packet size, tunnel concurrency, rekey activity, enabled services, redundancy, processor utilization, and any cryptographic acceleration.
The error is not choosing software-based or hardware-accelerated encryption in the abstract. The error is extrapolating production cost from an idle appliance or a lightly loaded proof of concept.
What to benchmark
- Total system power at idle, normal operating load, sustained peak load, and failover load.
- Watts per encrypted gigabit and watts per 1,000 active tunnels.
- Performance and power at small packet sizes, not only large-packet throughput.
- Thermal behavior, fan demand, rack density, and site cooling requirements.
- Energy use with required logging, telemetry, policy, routing, and security services enabled.
- The number of appliances and amount of spare capacity needed to meet availability objectives.
Ask for raw measurements and test conditions. A percentage-reduction claim without the baseline platform, workload, software configuration, packet profile, and availability assumptions is not enough for a defensible total-cost model.
Accepting Proprietary Dependencies Without an Interoperability Plan
What goes wrong
"Open" is not a product feature that can be verified with a logo or a standards list. It must be demonstrated across the interfaces and operational systems the operator will actually use. O-RAN specifications[5] define interfaces, functions, and processes for open, intelligent, virtualized, and interoperable Radio Access Networks. O-RAN alignment can be relevant when O-RAN components are in scope, but it does not by itself prove end-to-end SecGW interoperability with every RAN, transport, core, certificate authority, router, monitoring platform, or orchestrator.
Figure 5. Open multi-vendor telecom architecture with IKEv2 IPsec tunnels from multiple RAN and core vendors into a high-availability security gateway cluster, plus a seven-point interoperability validation matrix spanning RAN, core, PKI, routing, NMS/SIEM, orchestration, APIs, configuration portability, and witnessed testing.
What to require
- Interoperability evidence for the intended RAN, core, transport, PKI, NMS/SIEM, and orchestration combinations.
- Standards-based telemetry and configuration interfaces, with documented APIs and data models.
- Configuration export, backup, migration, and rollback procedures that do not depend on a single vendor service.
- A roadmap for software, cryptographic, and hardware upgrades without forced replacement of unrelated network components.
- Contractual clarity on licenses, support, feature portability, end-of-life obligations, and access to operational data.
The goal is not to eliminate every vendor dependency. The goal is to identify dependencies before purchase, test the important ones, and preserve practical options for expansion, replacement, and migration.
The 15-Point SecGW Validation Checklist
Use this list during architecture review, procurement, proof of concept, and production acceptance testing.
A Better Proof of Concept
A SecGW proof of concept should be a production-acceptance rehearsal, not a feature tour. Use representative tunnel counts, packet sizes, cipher suites, policies, certificates, routing, logging, failures, and operational procedures. Record both the result and the exact test conditions so competing platforms can be compared fairly and the same tests can be repeated after major software changes.
Evaluate Nybsys Aegis against the same evidence framework
See how the Nybsys Aegis Security Gateway addresses carrier-scale security gateway requirements, then map each requirement to architecture documentation and supporting test evidence.
Explore Aegis Security Gateway →Frequently Asked Questions
What is the difference between a SecGW and an enterprise firewall or VPN appliance?+
Both may support IKE and IPsec, but suitability depends on the required architecture and workload. A telecom SecGW evaluation typically emphasizes concurrent tunnels, setup and rekey rates, encrypted packet performance, routing, redundancy, certificate operations, policy scale, and carrier availability. Protocol support alone does not establish production fitness.
Does GSMA NESAS certify a vendor or product?+
No. GSMA states that NESAS does not accredit or certify equipment vendors or their products. NESAS audits defined vendor development and lifecycle processes and supports security evaluation of specific products by authorized laboratories. Operators should verify the exact product, version, scope, requirements, and published results.
Which SecGW performance metrics matter most?+
Concurrent active tunnels, tunnel-establishment rate, rekeys per second, encrypted throughput, packets per second, latency, packet-size behavior, policy and logging overhead, and capacity during failover are all important. The correct weighting depends on the target network and growth model.
Is a SecGW enough to implement zero trust?+
No. A SecGW can enforce important network policies, but zero trust also requires identity, authentication and authorization decisions, least privilege, resource-focused access, telemetry, lifecycle controls, and governance. Tunnel authentication is one input, not the entire architecture.
How should operators compare SecGW energy efficiency?+
Measure complete-system power under representative encrypted workloads. Useful normalized measures include watts per encrypted gigabit and watts per 1,000 active tunnels, accompanied by packet sizes, cipher suites, rekey activity, enabled functions, redundancy, and thermal conditions.
How can an operator reduce vendor lock-in?+
Define required interfaces and integrations before purchase, require witnessed interoperability testing, favor documented standards-based APIs and telemetry, preserve configuration and operational-data access, and establish migration, licensing, support, and end-of-life terms contractually.
Scope and Limitations
SecGW architecture varies by operator, access technology, trust-domain design, deployment model, and regulatory environment. The criteria in this article should be adapted to the applicable 3GPP architecture, traffic profile, availability objective, operational model, and security requirements. Product claims should be validated using documented test conditions and the exact software and hardware configuration proposed for deployment.
References
- 3GPP TS 33.210, Network Domain Security (NDS); IP network layer security — 3gpp.org/dynareport/33-series.htm
- IETF RFC 4301, Security Architecture for the Internet Protocol — datatracker.ietf.org/doc/html/rfc4301
- GSMA, Network Equipment Security Assurance Scheme (NESAS) — gsma.com/.../network-equipment-security-assurance-scheme
- NIST SP 800-207, Zero Trust Architecture — csrc.nist.gov/pubs/sp/800/207/final
- O-RAN ALLIANCE, O-RAN Specifications — o-ran.org/specifications