5G Security Architecture

Earlier mobile generations were built from purpose-built hardware appliances connected by well-defined interfaces. 5G reimagines the core network as software running on general-purpose cloud infrastructure.

The service-based architecture

The 5G core is defined by 3GPP as a set of Network Functions (NFs) — the AMF, SMF, UPF, AUSF, UDM, and others — that expose services to one another over HTTP/2 REST APIs. This Service-Based Architecture (SBA) replaces rigid point-to-point interfaces with a flexible service mesh. Any NF can discover and consume the services of another through the Network Repository Function.

Why this matters for security

The consequence is profound: the core network is now an API estate. The classic web-application risks — broken authentication, excessive data exposure, injection, and authorization flaws catalogued in the OWASP API Security Top 10 — apply directly to the signaling plane of a national mobile network.

Virtualization inherits cloud risk

NFs run as virtual machines or containers orchestrated by platforms like Kubernetes. That means 5G inherits the full stack of cloud-native security concerns: hypervisor and container escapes, insecure orchestration, supply-chain risk in images, and misconfigured infrastructure-as-code.

In 5G, a compromise of the orchestration layer can affect every network function it hosts. The blast radius is defined by the platform, not the appliance.

5G materially strengthens some long-standing weaknesses of mobile networks, particularly around subscriber identity and authentication.

Concealing the permanent identifier

In earlier networks, the permanent subscriber identity (IMSI) was transmitted in cleartext during attach, enabling IMSI-catcher surveillance. 5G introduces the Subscription Concealed Identifier (SUCI), which encrypts the permanent identifier (SUPI) using the home network's public key before it ever leaves the device. This is one of 5G's most important privacy improvements.

Unified authentication

3GPP defines 5G-AKA and EAP-AKA' as the primary authentication frameworks. Authentication is anchored in the home network rather than delegated entirely to the visited network, reducing the trust placed in roaming partners.

Trust does not eliminate risk

These improvements harden the front door, but they do not secure everything behind it. Once a device is authenticated, the security of its traffic depends on correct configuration of the SBA, slice isolation, and edge controls. Enterprises deploying private 5G should treat the standard's cryptographic guarantees as a foundation, not a finished security posture — the gaps are almost always in deployment and configuration, which is where a security assessment focuses.

Network slicing is one of 5G's defining capabilities: a single physical infrastructure hosts multiple logical networks, each tuned for a use case — ultra-reliable low-latency control, massive IoT telemetry, or high-bandwidth video.

The isolation promise

Each slice is meant to be logically isolated so that a fault or compromise in one cannot affect another. A slice serving a hospital's connected devices should be insulated from a slice serving consumer broadband.

Where isolation breaks down

Because slices share physical compute, memory, and transport, isolation is enforced in software and configuration — and software isolation can fail:

• Shared network functions that serve multiple slices become cross-slice pivot points.
• Resource exhaustion in one slice can degrade others without proper quotas (a noisy-neighbor denial of service).
• Misconfigured slice selection can route a device to the wrong slice, bypassing intended controls.

Verifying, not assuming

Slice isolation must be tested like any other security boundary. This means validating that a workload in one slice genuinely cannot reach the control or data plane of another, and that shared NFs enforce per-slice authorization. GuardsArm's penetration testing approach treats each slice boundary as an attack surface to be probed rather than a guarantee to be trusted.

5G pairs with Multi-access Edge Computing (MEC) to push processing close to where data is generated — factory floors, stadiums, and roadside cabinets — cutting latency dramatically.

Compute leaves the data center

Moving compute to the edge means moving it to physically exposed, often unstaffed locations. An edge site in a street cabinet does not have the physical security of a hardened data center. This changes the threat model to include physical tampering, local network access, and theft.

The User Plane Function at the edge

The User Plane Function (UPF) is frequently deployed at the edge to keep traffic local. Because the UPF handles subscriber data traffic, compromise of an edge UPF can expose or manipulate that traffic directly.

Securing the edge

• Enforce hardware-rooted trust and secure boot on edge nodes.
• Encrypt all traffic between the edge and the central core.
• Segment edge workloads and apply zero-trust principles — authenticate every service call rather than trusting the local network.
• Monitor edge nodes for tampering and anomalous behaviour.

The edge extends the mobile operator's trust boundary to the far end of the network — often to places no security guard will ever visit. Design for that reality.

5G does not launch into a vacuum. Most deployments begin as non-standalone (NSA), anchoring the 5G radio to a 4G core, and even standalone networks must interwork with older systems for roaming.

Legacy signaling weaknesses persist

The SS7 and Diameter protocols that carry signaling in 2G/3G/4G networks have well-documented weaknesses that have enabled location tracking, call interception, and fraud. Because 5G must interwork with these networks, those risks remain in scope wherever interworking exists.

Securing 5G interconnect

3GPP introduces the Security Edge Protection Proxy (SEPP) to protect the interface between operators' networks during roaming. The SEPP provides message filtering, topology hiding, and protection of signaling between home and visited networks. A correctly deployed SEPP is essential — but it is a control that must be configured and monitored, not merely present.

Interconnect as a supply chain

Roaming partners and interconnect providers form a trust web. A weakness in one partner can propagate. Operators should apply the same third-party risk discipline to interconnect partners that they apply to any critical vendor: contractual security requirements, monitoring, and the assumption that any partner may be compromised.

Private 5G — dedicated networks for factories, ports, hospitals, and campuses — is where many enterprises will first own 5G infrastructure directly, and therefore own its security.

You now run a mobile core

Deploying private 5G means the enterprise becomes responsible for operating network functions, orchestration, and slicing. This is a significant expansion of the security team's remit and usually requires new skills or a specialist partner.

A practical control set

• Harden the platform. Apply CIS benchmarks to the Kubernetes and host layer beneath the NFs; the core is only as secure as the cloud stack under it.
• Secure the APIs. Enforce mutual TLS and OAuth 2.0 authorization between network functions, and monitor the service mesh for anomalous calls.
• Segment ruthlessly. Isolate the 5G core from IT networks and apply zero-trust access to management interfaces.
• Inventory devices. Massive IoT connectivity means many low-power, rarely-patched endpoints; onboard them with strong identity and constrain what each can reach.
• Test the whole stack. Radio, core, slicing, and edge each need validation.

Aligning to standards

Ground the program in 3GPP security specifications, NIST guidance on 5G cybersecurity, and ENISA's 5G threat landscape work. A structured assessment against these frameworks turns a broad, unfamiliar attack surface into a prioritized roadmap — the point at which a GuardsArm engagement typically adds the most value.