The User Plane Function (UPF) is the network function that actually moves subscriber traffic in a 5G network. It is the anchor point for every PDU session and the interconnect to the data network, and it is defined in 3GPP TS 23.501. Because it sits directly in the path of user data, the UPF is one of the highest value targets in the 5G core, yet it is often discussed only in terms of throughput and latency rather than security. This deep dive looks at the UPF as an attack surface: the interfaces it exposes, where its trust assumptions break down, and how to harden it. It builds on our earlier post on GTP-U security by widening the lens from one protocol to the whole function.
What the UPF is and why it matters
The UPF handles packet routing and forwarding, packet inspection, per session and per flow quality of service enforcement, traffic usage reporting, downlink buffering, and it acts as the PDU Session Anchor that keeps a session stable as a device moves. In a standalone 5G core the control plane decides policy and the UPF enforces it on real traffic. That division is exactly why the UPF matters for security: whoever can influence the UPF, directly or through its control channel, can influence where user traffic goes, whether it is dropped, and whether it can be observed. Everything else in this article follows from that single fact.
The UPF interface map
The UPF is defined by the interfaces around it. Each one is a distinct trust boundary with its own protocol and its own failure modes.
N4: the control channel from the SMF
The Session Management Function (SMF) programs the UPF over the N4 interface using the Packet Forwarding Control Protocol (PFCP), specified in TS 29.244. Through PFCP the SMF creates, modifies, and deletes the forwarding, QoS, and reporting rules that govern a session. PFCP is powerful by design, which is why N4 is the most sensitive interface the UPF exposes. PFCP was built to run inside a protected core and carries limited built in peer authentication, so its security depends heavily on network isolation and transport protection rather than on the protocol itself.
N3: the user plane from the RAN
N3 connects the gNB to the UPF and carries user traffic in GTP-U tunnels, specified in TS 29.281. GTP-U has no native confidentiality or integrity protection, so the traffic and the tunnel identifiers it uses are only as protected as the transport underneath them. This is the same structural weakness that has followed GTP across generations, described in our post on common attacks on GTP.
N6: the edge to the data network
N6 connects the UPF to the data network, which is typically the internet, an enterprise network, or the IMS domain that carries voice. N6 is therefore the point where the mobile core meets an external, often untrusted network, which makes it a classic external attack surface that has to be firewalled and monitored like any internet facing boundary.
N9: between UPF instances
N9 carries traffic between two UPFs, for example in home routed roaming or in deployments that chain an intermediate UPF to an anchor UPF. It uses GTP-U in the same way as N3 and inherits the same need for transport protection, with the added consideration that in roaming it can cross an operator boundary.
Where UPF security actually breaks down
The specification gives the UPF a clear role. The security problems appear in how that role is implemented and deployed.
N4 and PFCP: abusing the control channel
If an attacker can reach the N4 interface, whether through a misconfigured management network, a compromised adjacent function, or an insider position, PFCP becomes a lever over live traffic. Public security research has documented denial of service scenarios in which floods of PFCP session establishment, modification, or deletion messages exhaust processing capacity or force sessions to drop, as well as scenarios where crafted rules redirect or discard user traffic. The common thread is that PFCP assumes a trusted network. When that assumption does not hold, the protocol offers little of its own to fall back on. Isolating N4, protecting it with IPsec, validating peer identity, and rate limiting PFCP are therefore not optional extras but the primary defence.
N3 and GTP-U: an unauthenticated user plane
Because GTP-U carries no security of its own, two problems recur. First, without transport protection an attacker positioned on the path can inject or manipulate tunnelled packets. Second, malformed GTP-U packets have repeatedly been shown in public research to crash or degrade user plane implementations that do not validate input robustly. The mitigations are consistent: IPsec on N3, strict parsing and input validation in the UPF, and monitoring for anomalous tunnel activity rather than trusting that only the RAN can send GTP-U.
N6: internet borne exposure
Because N6 faces a data network, the UPF inherits the entire class of threats that face any gateway to the internet or to a third party network. Unfiltered N6 exposure can let external traffic reach places it should never touch, and can turn the UPF into a pivot toward the rest of the core. N6 needs firewalling, segmentation, and the same egress and ingress discipline you would apply to any perimeter.
The platform: virtualization, edge and private 5G
UPFs are increasingly deployed at the edge to keep traffic local and latency low, which means they often run on virtualized and Kubernetes based infrastructure, sometimes on premises that the operator does not fully control, as is common in private mobile networks. A UPF is only as trustworthy as the platform under it, so the security of the underlying NFVI, the container orchestration, and the physical site all become part of the UPF's threat model. An edge UPF in a poorly secured location is a very different risk profile from one in a hardened central data centre.
User plane security policy: integrity and ciphering
3GPP TS 33.501 defines a user plane security policy that governs whether traffic on a PDU session is ciphered and integrity protected between the device and the RAN. Support for user plane integrity protection is required, but whether it is activated is driven by policy, and historically full rate user plane integrity protection was constrained by performance considerations. The practical takeaway is that operators should treat user plane integrity protection as a deliberate policy decision per service and per session type, not as something that is simply on everywhere. Where it is not active, the manipulation risks on the user plane are correspondingly higher, which raises the importance of the transport and monitoring controls described above. These questions sit alongside the broader design choices covered in our post on secure 5G core design patterns.
A practical UPF hardening checklist
Pulling the threads together, a defensible UPF deployment generally comes down to a short set of controls applied consistently. Isolate and protect N4 so that PFCP is never reachable from an untrusted network, and apply IPsec plus rate limiting and peer validation on that interface. Apply IPsec on N3 and N9, and ensure the UPF validates GTP-U input rather than trusting its peers. Firewall and segment N6 as a genuine perimeter. Harden the platform beneath the UPF, including the NFVI, the orchestration layer, and the physical site, with particular care for edge and private deployments. Set user plane security policy deliberately. Finally, monitor the user plane itself: signaling and traffic anomalies at the UPF are exactly the kind of activity that a telecom aware intrusion detection capability is built to surface.
The UPF rewards attention. It is where policy meets real traffic, and its security is determined less by the specification than by how its interfaces are isolated, how its platform is hardened, and how its traffic is watched. If you want a review of your UPF and user plane exposure, or of the wider 5G core around it, get in touch at [email protected].
