SEPP

Overview

The SEPP — Security Edge Protection Proxy — is the trust boundary node in 5G roaming architecture. Every SBI message that crosses a PLMN boundary — a visited network's AMF querying a home network's UDM, a visited SMF checking a roaming subscriber's subscription data — must pass through a pair of SEPPs: one in the visited network, one in the home network.

The SEPP was created to solve a problem that has no equivalent in 4G: when SBI uses HTTP/2 with TLS, that TLS session terminates at each hop. An IPX provider acting as an intermediary in the roaming path can read and modify plaintext HTTP/2 message bodies despite the outer TLS session. In a 4G Diameter roaming path, the equivalent concern exists but is mitigated differently; in 5G, the SBI messages carry subscriber-sensitive data (SUPI, authentication vectors, subscription profiles) as structured JSON that any observer on the transit path can parse.

The SEPP addresses this by introducing a second layer of cryptographic protection — JSON Web Signature (JWS) and JSON Web Encryption (JWE), collectively called PRINS (Protocol for N32 Interconnection Security) — applied to specific sensitive fields within the HTTP/2 message body. This protection persists end-to-end through the IPX network: even if the IPX provider terminates the outer TLS, the inner JWE on sensitive fields remains encrypted until the remote SEPP decrypts it. The IPX provider can read the routing headers (necessary to forward the message) but cannot read subscriber-sensitive fields.

The SEPP is defined in 3GPP Release 15 and is mandatory for 5G roaming. Its design reflects a deliberate decision to apply defence-in-depth to the roaming interface — not relying solely on transport-layer security for a transit path that crosses multiple administrative domains.

---

How it works

The SEPP operates in two modes depending on the nature of the inter-PLMN path: direct TLS (N32-c) and PRINS-protected (N32-f). The mode is negotiated during the initial handshake between the two SEPPs.

N32-c: security capability negotiation

Before any subscriber-related messages flow, the two SEPPs establish a control connection on N32-c. This is a direct TLS 1.3 connection between the home and visited SEPPs (or via IPX intermediaries that are explicitly trusted by both PLMNs). Over N32-c, the SEPPs negotiate:

• The supported protection policy: which IE (Information Element) fields in which HTTP methods require JWE encryption, and which require JWS signing only.
• The TLS cipher suites for the N32-f data connection.
• The IPX identity list — IPX providers that are authorised to modify specific non-sensitive routing headers on the N32-f path.

This negotiation is critical: a misconfiguration here that marks sensitive fields as not requiring encryption silently degrades the security of all subsequent messages.

N32-f: PRINS-protected message forwarding

With the protection policy agreed, subscriber-related SBI messages flow over N32-f. The originating SEPP (in the visited network, for a home-routed request) transforms an outbound HTTP/2 message as follows:

1. The SBI message body is parsed. Fields designated as requiring JWE in the protection policy are encrypted using the target SEPP's public key, derived from their certificate. Fields requiring JWS are signed with the originating SEPP's private key.
2. The resulting PRINS message — an HTTP/2 message with a modified body containing the encrypted/signed field values alongside a routing metadata block — is forwarded to the IPX or directly to the remote SEPP.
3. IPX providers can read and modify the routing metadata block (which contains unencrypted routing labels) to steer the message, but cannot decrypt or modify the protected field values.
4. The receiving SEPP decrypts the JWE fields using its private key, reconstructs the original HTTP/2 message, and forwards it to the target NF within its network.

Authorised modification by IPX

The SEPP model explicitly acknowledges that IPX providers may legitimately need to modify certain message fields for routing purposes (for example, replacing source IP addresses). The N32-c negotiation includes an authorised modification list: specific fields that a named IPX provider is permitted to modify on the N32-f path. Any modification outside this authorised list causes the receiving SEPP to reject the message.

---

Architecture role

In a 5G roaming deployment, the SEPP is deployed at each PLMN's network edge, adjacent to the existing signalling gateway infrastructure. For an operator that previously deployed a Diameter Edge Agent (DEA) for 4G roaming, the SEPP occupies the same topological position but with a fundamentally different security model.

In 5G SA roaming: The visited network's NFs (AMF, SMF) send SBI requests for subscriber data to the home network via the visited SEPP → IPX → home SEPP → target NF path. The SEPP pair is fully in the signalling path for every cross-PLMN SBI call.

In 5G home-routed sessions: PDU session traffic (user plane) is routed directly back to the home network's SMF and UPF. The control-plane signalling for this session traverses the SEPP pair, but user-plane GTP-U traffic does not.

Relationship to the DEA (4G): The 4G DEA applied Diameter-level filtering. The 5G SEPP applies JSON-level field encryption. The security properties are complementary: the DEA relied on a trusted transport path and message-level policy enforcement; the SEPP provides cryptographic protection that persists across untrusted intermediaries.

SEPP-to-SEPP certificate trust: SEPPs authenticate each other using certificates issued under a GSMA-operated PKI (GSMA's Network Functions repository). This shared PKI is what allows a home network's SEPP to verify the identity of a visited network's SEPP without prior bilateral configuration — a key enabler for the scale of global 5G roaming.

---

Key interfaces

---

Security posture

The SEPP has a critical threat level because it is the sole security control for inter-PLMN 5G SBI traffic. If the SEPP is bypassed, misconfigured, or compromised, all cross-PLMN subscriber data flows are exposed. The 4G roaming infrastructure had a similar single-point-of-failure property in the DEA — the SEPP is 5G's architectural answer to the same problem, with stronger cryptographic foundations but correspondingly higher implementation complexity.

The critical distinction from the DEA is that the SEPP's security does not depend on trusting the IPX network. A correctly configured SEPP provides end-to-end field-level protection that persists even if the IPX provider is hostile. This is the primary threat model the SEPP was designed for: a commercially operated IPX network that, in principle, has technical access to all traffic that transits it.

---

Attack surface

SEPP bypass

If an NF in the visited network can establish a direct TLS connection to the home network's NFs without going through the SEPP (because the home NF's firewall is misconfigured to allow direct connections), the SEPP's protection is entirely bypassed. All SBI messages flow in plaintext to IPX.

Impact: All inter-PLMN subscriber data exposed to IPX and any MITM on the transit path. Difficulty: Low if misconfiguration exists; SEPP bypass is typically an operational failure rather than an active attack.

IPX MITM via certificate substitution

If the protection policy negotiated on N32-c permits JWS signing without JWE encryption for some fields, or if the JWE key management is weak, an IPX provider with access to the N32-f path can attempt to substitute their certificate in the JWE key material and decrypt protected fields.

Impact: Subscriber-sensitive data (SUPI, authentication material) disclosed to the IPX provider. Difficulty: High if properly configured; reduces to medium with a misconfigured protection policy.

Misconfigured protection policy

The protection policy defines which fields require JWE. An operator that deploys a SEPP but negotiates a protection policy that marks sensitive fields as not requiring encryption effectively has no protection for those fields on the N32-f path.

Impact: Silent exposure of subscriber data despite SEPP being present in the path. Difficulty: Low — this is a configuration error, not a protocol attack.

---

Mitigations

• Mandatory SEPP enforcement: Configure all home-network NFs to reject direct N32 connections from foreign networks. All inter-PLMN SBI traffic must enter via the SEPP, enforced by network-layer firewall rules.

• Protection policy audit: Regularly audit the N32-c protection policies negotiated with each roaming partner. All subscriber-sensitive fields — SUPI, SUCI, authentication vectors, subscription data — must be designated for JWE encryption. Do not accept protection policy downgrades during negotiation.

• GSMA PKI certificate validation: Validate SEPP peer certificates against the GSMA Network Functions repository PKI. Reject connections from SEPPs presenting certificates not issued under the GSMA root hierarchy.

• IPX authorised modification list review: The list of fields an IPX provider is authorised to modify (negotiated on N32-c) should be as restrictive as possible. Any field on this list can be modified by the IPX without cryptographic accountability. Review this list with each roaming partner.

• N32-c negotiation monitoring: Alert on N32-c negotiation failures, protection policy mismatches, and unexpected capability downgrades. These may indicate a misconfiguration on either end or an active attempt to negotiate weaker security.

---

Spec references

• 3GPP TS 33.501 — Security Architecture and Procedures for 5G System. Section 13 defines the SEPP and N32 interface security in detail, including the PRINS protocol. Annex E provides the field-level protection policy framework.

• 3GPP TS 29.573 — PLMN Interconnection Stage 3. Sections 5 and 6 define the N32-c negotiation procedure and N32-f message format including PRINS encoding.

• GSMA FS.24 — 5G Security Guide. Addresses the SEPP in the context of roaming security posture, including certificate trust model and the GSMA PKI for SEPP authentication.

---

Related topics

The SEPP protects access to the home network's UDM, AMF, and AUSF from the visited network in 5G roaming. It is the 5G architectural successor to the Diameter Edge Agent function of the DRA at the 4G roaming boundary.

The SEPP's role in the roaming architecture is described in roaming architecture. In 5G home-routed roaming, the S8 home routing reference describes how the data plane complements the SEPP-protected control plane. The 5G SA topic provides the broader standalone core architecture context.