The transition to 5G is not merely an upgrade in speed; it represents a fundamental architectural shift that redefines what it means to secure a mobile network. By moving away from proprietary telecom hardware to cloud-native, IT-centric environments, 5G introduces an entirely new threat landscape. While 5G was designed to be the most secure cellular generation yet, its reliance on web technologies expands the attack surface significantly, requiring telecom engineers, security architects, and CISOs to adopt new defensive paradigms.
Understanding this shift is critical because 5G is not just another "G" — it is the convergence point where traditional telecom engineering meets IT security. The implications are profound: the same vulnerability classes that have plagued web applications for decades — injection flaws, broken authentication, insecure deserialization — are now attack vectors against critical national infrastructure. For security professionals trained in classical telecom protocols like SS7 vulnerabilities or Diameter protocol, this means acquiring entirely new skillsets. For IT security experts, it means understanding the unique operational constraints of real-time telecommunications systems where millisecond-level latency budgets leave no room for heavyweight security middleware.
This comprehensive guide dissects the 5G security architecture, exploring the newly introduced risks and the methodologies required to secure the next generation of global telecommunications infrastructure. It covers the Service Based Architecture (SBA), Security Edge Protection Proxy (SEPP), Subscription Concealed Identifier (SUCI), RAN security evolution, legacy interworking risks, and advanced threat modeling — all contextualized with real-world case studies and regulatory guidance.
I. Introduction: The Expanded Attack Surface
Previous generations of cellular networks (3G, 4G/LTE) relied on specialized, closed-source hardware and obscure telecom-specific protocols (like SS7 vulnerabilities and Diameter protocol). Security through obscurity was the unspoken default — proprietary interfaces and niche protocol knowledge created a natural barrier to entry for attackers. 5G, however, is built on a Service Based Architecture (SBA). Functions that used to be physical boxes are now containerized microservices running in Kubernetes clusters.
Instead of SS7 or Diameter, these microservices communicate via HTTP/2 and RESTful APIs over TLS. While this IT-centric approach allows for unprecedented agility, NETWORK SLICING, and edge computing, it also means that 5G networks inherit the vast universe of traditional web vulnerabilities — from API injections to container escapes. The 3GPP specification evolution from Release 15 onward has codified these new security requirements, but implementation remains inconsistent across operators worldwide.
This module examines the security posture of the 5G core network, focusing on the transition from traditional perimeter-based security to a zero-trust architecture. Security practitioners can validate these concepts hands-on using a private 5G lab environment with open-source tools like Open5GS and srsRAN.
The Scale of the 5G Security Challenge
To appreciate why 5G security demands a fundamentally different approach, consider the quantitative expansion of the attack surface:
| Dimension | 4G/LTE | 5G SA | Security Implication |
|---|---|---|---|
| Core Architecture | Monolithic EPC | Microservices SBA | Container escape = full core compromise |
| Inter-NF Protocol | GTP-C / Diameter | HTTP/2 + REST APIs | OWASP Top 10 applies directly |
| Subscriber Identity | IMSI (cleartext over air) | SUCI (encrypted) | Passive catching mitigated; active attacks evolve |
| Roaming Security | SS7/Diameter (minimal auth) | SEPP + PRINS (mTLS) | Configuration-dependent; IPX trust still fragile |
| Network Isolation | APN-based (flat) | Network Slicing (logical) | Cross-slice attacks via shared infrastructure |
| RAN Model | Single-vendor monolithic | O-RAN multi-vendor | New interfaces (E2, O1, A1) expand attack surface |
| Device Density | ~100K devices/km² | ~1M devices/km² | Massive IoT botnets for signaling storms |
| Edge Computing | Centralized | MEC distributed | Physical security of edge nodes critical |
This table reveals a consistent pattern: every architectural improvement that enables 5G's performance gains simultaneously introduces a new class of security risk. The net result is an attack surface that is orders of magnitude larger and more complex than any previous generation. Our telecom pentesting guide details how to systematically evaluate these expanded surfaces.
The Zero-Trust Paradigm in 5G
The traditional telecom security model relied on perimeter defense — trusted internal networks with hardened borders. 5G's cloud-native architecture makes this model obsolete. Zero-trust is not optional; it is architecturally mandated by 3GPP TS 33.501.
- Convergence of IT and Telco: Attackers no longer need specialized telecom knowledge to breach the core network; proficiency in cloud security and REST API exploitation is often sufficient. The barrier to entry has dropped from "requires SS7 interconnect access" to "requires API fuzzing tools."
- Critical Infrastructure Dependency: 5G underpins IoT, autonomous vehicles, telemedicine, and smart grids. A breach in the 5G core can have cascading physical consequences — from disrupted emergency services to compromised industrial control systems.
- Supply Chain Complexity: The reliance on open-source software (Kubernetes, Envoy, OpenTelemetry) and multi-vendor integrations increases the likelihood of supply chain attacks. The 2020 SolarWinds incident demonstrated how supply chain compromises cascade; the same pattern applies to cloud-native 5G cores.
- Regulatory Pressure: ENISA's 5G Security Toolbox, NIST's SP 1800-33, and GSMA's NESAS certification all mandate specific security controls that operators must implement and audit.
II. The 5G Service Based Architecture (SBA)
The 5G Core (5GC) is fundamentally an IT network. Understanding its components is the first step in securing it. The SBA introduces a service mesh model where every Network Function (NF) registers with the Network Repository Function (NRF) and discovers peer services dynamically — analogous to a Kubernetes service registry.
Core Network Functions and Their Security Roles
Each NF in the 5G SBA has a distinct security profile that must be individually hardened:
| Network Function | Role | Critical Security Concern |
|---|---|---|
| AMF (Access & Mobility Mgmt) | UE registration, handover | DDoS target for signaling storms |
| SMF (Session Mgmt) | PDU session control | Policy bypass via forged requests |
| UPF (User Plane) | Data packet forwarding | Data exfiltration if compromised |
| UDM (Unified Data Mgmt) | Subscriber data store | Crown jewel — full subscriber database |
| AUSF (Authentication Server) | 5G-AKA execution | Credential theft, replay attacks |
| NRF (NF Repository) | Service discovery | 5G SBA vulnerabilities — impersonation of any NF |
| PCF (Policy Control) | QoS and charging rules | Policy manipulation for service theft |
| NSSF (Network Slice Selection) | Slice routing | Cross-slice routing attacks |
| SEPP (Security Edge Protection) | Inter-PLMN gateway | Roaming attack mitigation point |
A. HTTP/2 and RESTful APIs in the Core
In the 5G SBA, Network Functions (NFs) expose their capabilities via RESTful APIs over an HTTP/2 transport. This is defined in 3GPP TS 29.500 and represents the most radical departure from legacy telecom architecture.
- The Benefits: HTTPS (TLS 1.3) provides strong mutual authentication and encryption between network elements, solving many of the interception issues that plagued legacy networks. The use of standard HTTP semantics means that existing API gateways, Web Application Firewalls (WAFs), and observability tooling can be adapted for telecom use.
- The Risks: This architecture brings OWASP Top 10 vulnerabilities directly into the telecom core. Poorly configured APIs, broken object level authorization (BOLA), insufficient rate limiting, and input validation failures act as open doors for attackers. A compromised container within the core could potentially impersonate legitimate NFs if TLS certificate management is misconfigured. For a deeper dive into these specifics, see our research on SBA-specific vulnerabilities.
B. The Security Edge Protection Proxy (SEPP)
To handle roaming — traditionally a massive vulnerability point in SS7 networks — 5G introduces the Security Edge Protection Proxy (SEPP). The SEPP acts as a secure gateway at the edge of the network, protecting the home network from malicious signaling originating from visited networks.
- How it Works: The SEPP uses Application Layer Security (PRINS — Protection of Roaming Information in N32 Signaling) to provide end-to-end authentication, integrity, and confidentiality protection for signaling messages between different Mobile Network Operators (MNOs). PRINS operates over the N32 interface, applying JSON-based message protection with JWS (JSON Web Signature) and JWE (JSON Web Encryption).
- The Vulnerability Gap: While SEPP theoretically solves roaming interception, its effectiveness relies entirely on secure configuration. Misconfigurations, shared cryptographic keys between collaborating operators, or vulnerabilities in the SEPP software itself can nullify these protections. The IPX provider trust model — where intermediate transit networks handle message routing — introduces additional risk because IPX providers may not implement PRINS consistently.
The contrast with legacy roaming security is stark. In SS7-based roaming, any interconnected operator could send unrestricted MAP messages to query subscriber data. In Diameter-based roaming, DEA (Diameter Edge Agent) filtering was optional and inconsistently deployed. SEPP with PRINS is mandatory in 5G SA, but the "mandatory" specification and real-world deployment are different stories.
C. Container Security and Kubernetes Hardening
The 5G SBA runs on Kubernetes, inheriting its entire security surface. Key hardening requirements include:
1. Pod Security Standards (PSS): All NF pods must run with restricted security context — no privileged containers, no host namespace sharing, read-only root filesystems.
2. Network Policy Micro-segmentation: Kubernetes relies on Network Policies for micro-segmentation. In rapid deployment cycles, MNOs often deploy clusters with overly permissive policies, allowing lateral movement between unrelated functions.
<CodeBlock language="yaml" filename="nf-ingress-policy.yaml" code="apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: amf-ingress-restriction namespace: 5g-core spec: podSelector: matchLabels: app: amf policyTypes:
- Ingress ingress:
- from:
- podSelector: matchLabels: app: gnb">
3. Service Mesh Enforcement: An Istio or Linkerd service mesh enforces mTLS between all NF pods, provides fine-grained traffic policies, and generates observability telemetry critical for detecting lateral movement attempts.
4. Secrets Management: NF-to-NF OAuth2 tokens, TLS certificates, and encryption keys must be managed via external secret stores (HashiCorp Vault, AWS KMS) — never hardcoded in container images or ConfigMaps.
III. Securing the Radio Access Network (RAN)
While the Core network handles orchestration and data routing, the Radio Access Network (RAN) connects user equipment (UE) to the network. The RAN is where over-the-air transmissions occur, making it inherently exposed to physical-layer attacks. For a comprehensive analysis of RAN-specific threats, see our dedicated research on RAN air interface vulnerabilities.
A. Traditional vs. Open RAN (O-RAN)
Historically, RAN equipment was provided by a single vendor (e.g., Ericsson, Nokia, Huawei) in a monolithic "black box." The industry is rapidly shifting toward Open RAN (O-RAN), which standardizes interfaces so operators can mix and match components from different vendors.
The Security Trade-off: O-RAN increases transparency and removes vendor lock-in, theoretically improving security through open scrutiny. However, it exponentially increases the attack surface by introducing new standardized interfaces (like the E2, O1, and A1 interfaces) and software components (like the RAN Intelligent Controller - RIC), all of which must be secured individually.
| Aspect | Traditional RAN | Open RAN (O-RAN) |
|---|---|---|
| Vendor Model | Single vendor, proprietary | Multi-vendor, open interfaces |
| Interface Security | Proprietary (security by obscurity) | Standardized E2/O1/A1 (documented attack surface) |
| Software Updates | Vendor-managed, infrequent | Community-driven, rapid iteration |
| Supply Chain Risk | Single point of trust | Multiple vendors = multiple trust boundaries |
| AI/ML Surface | Minimal | RIC xApps introduce ML poisoning risk |
| Physical Security | Integrated units, harder to tamper | Disaggregated, more physical access points |
B. Rogue Base Stations and IMSI/SUPI Catching
In 3G and 4G, attackers used "Stingrays" or IMSI catchers (rogue base stations) to trick devices into connecting, allowing the attacker to steal the International Mobile Subscriber Identity (IMSI) and intercept traffic. This attack leverages the fundamental trust model flaw in pre-5G networks: the UE authenticates to the network, but the network does not authenticate to the UE.
5G addresses this by encrypting the subscriber identity over the air. The IMSI is replaced by the Subscription Concealed Identifier (SUCI), which is encrypted using the home network's public key (ECIES scheme) before transmission. It is only decrypted inside the secure core by the SIDF (Subscription Identifier De-concealing Function) to reveal the Subscription Permanent Identifier (SUPI).
The Reality: While true 5G SA (Standalone) mitigates passive IMSI catching, several attack vectors persist:
- Downgrade attacks forcing fallback to 4G/3G/2G where IMSI is sent in cleartext
- SUCI correlation attacks — while the SUCI changes per registration, timing and location metadata can still be correlated
- baseband exploitation in smartphones — exploiting the modem firmware directly to extract the SUPI from the device's USIM before encryption occurs
C. Physical and Fronthaul Vulnerabilities
With the push for higher bandwidth (mmWave), 5G requires significantly more cell sites — potentially 10x the density of 4G — often deployed in physically accessible locations like street lamps, building sides, and utility poles. This increases the risk of physical tampering or tapping into the "fronthaul" eCPRI connections that link these Remote Radio Units (RRUs) back to the Distributed Units (DU) and Centralized Units (CU).
Multi-access Edge Computing (MEC) further distributes sensitive processing to the network edge. A compromised MEC node could intercept user plane data before it reaches the secure core, making edge node physical security a critical operational requirement. TelcoSec's dedicated lab environments provide controlled settings for testing these edge deployment scenarios.
IV. Legacy Interworking: The Achilles Heel
A 5G network rarely exists in isolation. For the foreseeable future, 5G networks must interoperate with legacy 4G, 3G, and even 2G infrastructure to ensure continuous coverage. This interworking is arguably the biggest immediate threat to 5G security — a chain is only as strong as its weakest link.
Non-Standalone (NSA)
Most early 5G deployments are NSA (Option 3x). In 5G NSA, the network uses the 5G New Radio (NR) for faster data speeds but still relies entirely on the 4G Evolved Packet Core (EPC) for signaling and control, inheriting all 4G EPC vulnerabilities — including Diameter attacks and GTP tunnel manipulation.
Downgrade Attacks
Advanced attackers will actively attempt to force a 5G device to downgrade its connection to 4G, 3G, or 2G to leverage well-known legacy vulnerabilities such as SS7 interception, missing mutual authentication in 2G, or KASUMI cipher weaknesses in 3G. The 2019 "Torpedo" attack demonstrated that even 4G paging protocols leak enough information for targeted downgrade exploitation.
C. Interconnect Vulnerabilities
Even a pure 5G Standalone (SA) network must handle SMS and voice calls routing through older networks globally via IWF (InterWorking Function) gateways. Attackers continuously exploit the SS7 vulnerabilities and Diameter protocol interconnects between international operators. If the gateways between the 5G Core and these legacy networks are not rigorously filtered and monitored, attackers can still execute tracking, interception, and fraud attacks against 5G subscribers.
D. The Interworking Security Gap: A Quantitative View
| Attack Vector | Legacy Protocol | 5G Mitigation | Residual Risk |
|---|---|---|---|
| Subscriber Tracking | SS7 ATI/SRI-SM | SUCI concealment | IWF gateway bypass, SS7 roaming probe |
| Call/SMS Interception | SS7 MAP redirect | End-to-end encryption | Lawful intercept API misuse, SS7 fallback |
| Billing Fraud | Diameter CCR manipulation | OAuth2 NF authorization | IWF policy inconsistency |
| DoS/Service Denial | Diameter overload | NRF-based load balancing | Signaling storm via IoT botnet |
| Identity Theft | SIM swap via SS7 | eSIM + stronger auth | Social engineering persists |
V. Threat Modeling 5G Deployments
Securing a modern telecom network requires moving beyond compliance checklists and adopting an adversarial mindset. The MITRE FiGHT framework provides the telecom-specific equivalent of MITRE ATT&CK, mapping adversary techniques to 5G infrastructure components. Our telecom penetration testing guide details how to operationalize these threat models.
A. Supply Chain and Software Composition Risks
The multi-vendor nature of 5G SBA and O-RAN means that a vulnerability in a seemingly minor third-party microservice can compromise the entire core. Rigorous Software Bill of Materials (SBOM) tracking, continuous vulnerability scanning, and zero-trust principles within the cluster are mandatory. The 2021 Log4Shell vulnerability (CVE-2021-44228) affected multiple commercial 5G Core products because they relied on Apache Log4j in their management interfaces — demonstrating how a single library dependency can cascade across an entire telecom infrastructure.
B. Signaling Storm DDoS
The high density of IoT devices supported by 5G — up to 1 million per square kilometer — creates a massive potential botnet. A coordinated Signaling Storm, where millions of compromised IoT devices simultaneously send registration or PDU session establishment requests, can overwhelm the AMF and SMF, causing cascading network outages. Unlike volumetric DDoS that targets bandwidth, signaling storms target the control plane's finite processing capacity.
C. Cross-Slice Lateral Movement
5G network slicing security allows operators to create isolated, logical networks on the same physical infrastructure. If the hypervisor, orchestration layer (Kubernetes), or shared network functions (NRF, NSSF) are compromised, an attacker could traverse from a low-security slice (like public IoT) into a critical-infrastructure slice (like emergency services or autonomous vehicle coordination). Researchers can validate these scenarios by setting up a private 5G lab with slice-aware configurations.
D. MITRE FiGHT Mapping for 5G SBA
| FiGHT Technique | Description | Affected NFs | Detection Approach |
|---|---|---|---|
| FGT1557 | NF Service Discovery Abuse | NRF | Anomalous NF registration patterns |
| FGT1078 | Valid Account Exploitation | AUSF, UDM | Behavioral analytics on auth sequences |
| FGT1040 | Network Sniffing (User Plane) | UPF | DPI anomaly detection at UPF egress |
| FGT1498 | Network DoS (Signaling Storm) | AMF, SMF | Rate limiting + ML-based traffic classification |
| FGT1595 | Network Slice Manipulation | NSSF, NRF | Slice policy audit + integrity monitoring |
VI. Industry Impact & Regulatory Context
5G security is no longer just a technical concern — it is a geopolitical and regulatory imperative. Operators must navigate an increasingly complex compliance landscape:
- EU 5G Security Toolbox: Member states must assess risk profiles of 5G suppliers and apply restrictions on high-risk vendors in sensitive core functions. ENISA publishes annual threat landscape reports covering 5G-specific risks.
- NIST SP 1800-33: Provides the U.S. federal framework for 5G cybersecurity, addressing both standalone and non-standalone deployment security considerations.
- GSMA NESAS: The Network Equipment Security Assurance Scheme establishes baseline security requirements for network equipment, audited by accredited test laboratories.
- 3GPP TS 33.501: The canonical security specification defining authentication, key management, and security procedures for the 5G system. Explore the full 3GPP specification timeline for historical context.
Understanding these frameworks is essential for any professional operating in the 5G security space. The TelcoSec Academy curriculum covers regulatory compliance as part of its advanced certification tracks.
VII. Authoritative References
- 01 3GPP TS 33.501Security architecture and procedures for 5G system3GPP TS 33.501 – 5G Security Architecture →
- 02 GSMA FS.315G Security Guide - Version 7.0READ INDUSTRY GUIDE →
- 03 MITRE FiGHT5G Threat Map & Adversary TacticsVIEW THREAT MODEL →
- 04 ENISA 5G Threat LandscapeEuropean Union Agency for Cybersecurity - 5G SupplementREAD ENISA REPORT →
- 05 NIST SP 1800-33Guide to 5G CybersecurityACCESS NIST PUBLICATION →
- 06 3GPP TS 29.500Technical Realization of Service Based ArchitectureACCESS SBA SPEC →
VIII. Frequently Asked Questions
The most significant shift is the move from proprietary, hardware-based telecom equipment to a cloud-native, IT-centric Service Based Architecture (SBA). While this allows for greater flexibility, it also means 5G inherits common IT vulnerabilities like API flaws, container escapes, and web-based attacks. The convergence of telecom and IT security domains is now complete in 5G.
The Security Edge Protection Proxy (SEPP) acts as a gateway that protects the home network from malicious signaling originating from visited networks during roaming. It provides end-to-end authentication, integrity, and confidentiality for inter-operator signaling using the PRINS protocol, addressing many roaming vulnerabilities found in legacy SS7 vulnerabilities and Diameter protocol networks.
5G Standalone (SA) significantly mitigates passive IMSI catching by encrypting the subscriber identity over the air using a Subscription Concealed Identifier (SUCI). However, downgrade attacks, implementation flaws, and baseband exploitation in smartphones can still pose risks. Active catching techniques continue to evolve alongside 5G defenses.
Network slicing creates logically isolated virtual networks on shared physical infrastructure. While slices are designed to be independent, they share underlying resources (Kubernetes clusters, NRF, physical hardware). A compromise of shared infrastructure components could allow an attacker to traverse from a low-security slice to a high-security one — known as a cross-slice lateral movement attack.
MITRE FiGHT (5G Hierarchy of Threats) is the telecom-specific adaptation of the MITRE ATT&CK framework. It catalogs adversary techniques, tactics, and procedures (TTPs) specifically targeting 5G infrastructure — from NF impersonation to signaling storms. It is an essential reference for telecom pentesting methodology and red team operations.
No. 5G NSA uses the 5G radio interface but relies on the 4G Evolved Packet Core (EPC) for signaling, inheriting all 4G vulnerabilities including Diameter protocol signaling attacks and GTP tunnel manipulation. Only 5G SA with a full cloud-native 5GC provides the security improvements specified in 3GPP TS 33.501.
Conclusion & Next Steps
5G represents a massive leap forward in both capability and underlying security design. The introduction of the SBA, SEPP, SUCI encryption, and mandatory mutual authentication solves many historical telecom problems that plagued SS7 vulnerabilities and Diameter protocol networks for decades. However, the adoption of cloud-native architecture means that telecom security is now indistinguishable from cloud and enterprise IT security, coupled with the legacy baggage of interworking gateways that bridge the old and new worlds.
The path forward requires a multi-layered defense strategy:
- Zero-trust architecture enforced at every NF boundary with mTLS and OAuth2
- Continuous security testing using telecom-specific penetration testing methodologies and the MITRE FiGHT framework
- Legacy interworking hardening with rigorous SS7/Diameter signaling firewalls at all IWF gateways
- Regulatory compliance across GSMA NESAS, ENISA toolbox, and NIST frameworks
- Hands-on validation through private LTE/5G lab that replicate production attack scenarios
Ready to secure your deployment? Whether you are transitioning to a 5G Core, deploying O-RAN, or need to validate your legacy interconnects, TelcoSec provides the specialized expertise required. Explore our telecom engineering tools for protocol analysis, check the 3GPP specification navigator for standards reference, or dive into our TelcoSec research library for additional threat intelligence.
