Description
The Security Edge Protection Proxy (SEPP) is a fundamental security node introduced in the 5G Core (5GC) architecture. It operates as a non-transparent proxy for all HTTP/2-based Service-Based Interface (SBI) messages that traverse network boundaries, primarily between different Public Land Mobile Networks (PLMNs) in roaming scenarios. The SEPP's primary function is to protect the N32 interface, which is the reference point for interconnectivity between SEPPs of different operators. It sits at the perimeter of a network, inspecting all inbound and outbound SBI traffic to and from Network Functions (NFs) like the AMF, SMF, and NRF.
Architecturally, the SEPP is a dedicated Network Function that implements application-layer security. It works in conjunction with the Network Repository Function (NRF) for service discovery and policy control. For outbound messages destined for another PLMN, the home SEPP receives the SBI request from a producer NF, applies security processing (including potential encryption and integrity protection), and forwards it to the visited PLMN's SEPP. The visited SEPP then validates the message, removes the security encapsulation, and routes it to the appropriate consumer NF within its network. This hop-by-hop security model ensures that the internal network topology and NF identities are hidden from external entities.
The SEPP employs two main security mechanisms for the N32 interface: N32-c and N32-f. N32-c is a control plane interface used for security context establishment and parameter negotiation between two SEPPs before data exchange. N32-f is the forwarding interface that carries the actual protected SBI messages. Protection can be applied using JSON Web Encryption (JWE) for confidentiality and JSON Web Signature (JWS) for integrity and authentication of the HTTP messages. The SEPP also performs message filtering and topology hiding, stripping or modifying sensitive routing information in headers to prevent external networks from mapping the internal NF deployment. Its role is critical for enabling secure roaming, network slicing across operators, and the exposure of network capabilities to third-party application providers via the Network Exposure Function (NEF).
Purpose & Motivation
The SEPP was created to address the significant security challenges introduced by the 5G Core's Service-Based Architecture (SBA) and its reliance on HTTP/2 APIs (the SBI). In previous generations (4G EPC), inter-operator signaling used diameter-based protocols like S6a and S8, which had their own security mechanisms (e.g., IPsec, diameter security). The shift to RESTful APIs and the need for more flexible network exposure created a new attack surface. Without a dedicated edge proxy, HTTP/2 messages between operators would be vulnerable to eavesdropping, tampering, and spoofing, and would expose internal network structures.
The primary problems the SEPP solves are securing the inter-PLMN communication for roaming and enabling safe third-party access. Roaming in 5G requires numerous SBI messages to flow between the home and visited network for authentication, session management, and policy control. The SEPP ensures these messages are authenticated, authorized, and protected end-to-end between the network perimeters. Furthermore, it facilitates topology hiding, which is a regulatory and security requirement for operators to conceal their internal network configuration from partners and potential attackers.
Its creation was motivated by the 3GPP's push for a cloud-native, web-friendly core network. The SBA allows for agile service deployment but inherits web security concerns. The SEPP is the standardized answer to applying robust, application-layer security tailored for telecom needs, replacing ad-hoc security gateways and ensuring a consistent, interoperable security baseline for global 5G deployment, especially for network slicing across administrative domains.
Architecture
In the Network Map
- Mobile Network → 5G Core → SEPP (Signaling)
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (25 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, the SEPP (Security Edge Protection Proxy) was introduced as a new architectural element for the 5G System, defined as a non-transparent proxy on the N32 reference point for inter-PLMN control plane signaling. Its newly specified core functionalities included message filtering, policing, and topology hiding to protect interconnections between PLMNs. Furthermore, the release established that the SEPP can be deployed in a distributed, redundant, stateless, and scalable manner.
- Updates to the Security Edge Protection Proxy description TS 23.501CR0045
- SEPP fully redundant and next-hop IPX proxy TS 23.501CR0339
- PLMN ID verification at receiving SEPP TS 29.573CR0011
- Informative Annex on End to End Call Flow via SEPP TS 29.573CR0012
- Clarification to the protection of attributes by the SEPP TS 33.501CR0370
- Shift of text from SEPP intro to subclause TS 33.501CR0458
+ 3 more changes
In Release 16, key enhancements for the SEPP included mandating TLS for secure connections between Network Functions and the SEPP, with specific mechanisms based on custom HTTP headers. The release also introduced defined procedures for error handling when there is a mismatch of security policies between SEPPs on the N32 interface. Furthermore, it provided necessary clarifications on the SEPP's role in processing and relaying messages containing the 3gpp-Sbi-Target-apiRoot HTTP header.
In Release 17, key enhancements for the SEPP included the introduction of SEPP capability negotiation and a procedure to discover the SEPP via the NRF. The release also provided clarifications on SEPP functionality for interconnect scenarios and on the establishment of N32-C connections.
- SEPP capability negotation TS 29.573CR0079
- CR to include R-16 feature of SEPP to 33.517 TS 33.517CR0009
- Clarifications on SEPP TS 23.501CR3462
- Discover the SEPP via NRF TS 29.573CR0066
- SEPP reference TS 33.501CR1336
- SEPP for interconnect scenarios TS 29.573CR0088
+ 2 more changes
In Release 18, key enhancements were made to the SEPP to improve interface robustness and source verification. New procedures were introduced for the SEPP to include and verify the source PLMN-ID and to perform source SNPN ID verification, strengthening security on the N32 reference point. Additionally, mechanisms were defined to handle potential clashes of message IDs between the SEPP and other network elements.
- Robustness interfaces and protocols defined for SEPP TS 33.517CR0011
- EN on the clash of the message ID created by the RI and any messages initiated by the c-SEPP TS 29.573CR0183
- Source SNPN ID verification at the receiving SEPP TS 29.573CR0125
- SEPP to include and verify the source PLMN-ID TS 33.501CR1573
In Release 19, a specific technical correction was made regarding the handling of encrypted data within SEPP messages. The release introduced a correction to the SEPP service description, specifically addressing the precise locations of encrypted blocks. This update provides necessary clarification for the proper implementation of the N32 interface security procedures between SEPPs in different networks.
- Correction on Encrypted Block Locations in SEPP Service Description TS 29.573CR0226
Explore further
Broader topics and technologies where SEPP plays a role.
Defining Specifications
3GPP specifications that define or reference SEPP, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.501 vk00 | 5G System Architecture Stage 2 | Rel-20 |
| TR 26.930 vj00 | WebRTC Enhancements for Immersive RTC over 5G | Rel-19 |
| TS 29.500 vj50 | 5GC Service Based Architecture Specification | Rel-19 |
| TS 29.513 vj40 | 5G PCC Signalling Flows & QoS Mapping | Rel-19 |
| TS 29.573 vj50 | PLMN/SNPN Interconnection Interface Stage 3 | Rel-19 |
| TS 33.117 vk00 | Catalogue of General Security Assurance Requirements | Rel-20 |
| TS 33.501 vk00 | 5G Security Architecture and Procedures | Rel-20 |
| TS 33.517 vk00 | 5G Security Assurance Specification (SCAS) | Rel-20 |
| TS 33.776 vj00 | Study of ACME for 5G SBA | Rel-19 |
| TR 33.841 vg10 | Security aspects; Study on 256-bit algorithms for 5G | Rel-16 |