Every generation of mobile network has had to solve the same problem: how does a subscriber's home operator exchange signaling with a foreign network when that subscriber roams, without simply trusting whatever arrives from the interconnect? SS7 never solved it — any node on the network could query, redirect, or impersonate any other, and the resulting "Category-2" interception model (an adversary positioned in the SS7/IPX transit path reading or modifying signaling in transit) has been exploited by surveillance vendors and criminal groups for over a decade. 5G was explicitly designed to close this gap. The Security Edge Protection Proxy (SEPP) sits at the PLMN boundary and is meant to guarantee that no entity between two operators — including the IPX (IP Exchange) carriers that physically route the traffic — can read or tamper with roaming Service Based Interface (SBI) messages.
That guarantee depends entirely on one control being enforced without exception: JSON Web Encryption (JWE) on the N32-f interface. 3GPP built in a legacy interoperability fallback — a "no protection" negotiation outcome — to ease the transition from Diameter-based roaming partners who hadn't yet deployed a SEPP. When that fallback is left reachable for 5G-capable partners, either through misconfiguration or through an adversary actively forcing the capability negotiation down, the N32-f channel reverts to plaintext HTTP/2 across the IPX. The result is the SS7 Category-2 problem, reproduced inside the architecture that was supposed to retire it. This is precisely the class of regression this research documents: a control that exists on paper, is standardized correctly, and is routinely absent in practice.
This research dissects how the SEPP's N32-c capability negotiation can select "no protection" for N32-f, why that outcome is standards-compliant yet catastrophic for roaming confidentiality, and how an IPX-positioned adversary exploits it to intercept and modify subscriber data crossing the roaming boundary — replicating the interception model SS7 roaming was never able to shake.
I. SEPP Architecture: The N32-c / N32-f Split
Every inter-PLMN SBI call in a 5G Standalone roaming relationship passes through a pair of SEPPs — one at the home network (SEPP-H) and one at the visited network (SEPP-V) — connected across the IPX transit path. The interface between the two SEPPs is split into two logically distinct planes, and understanding that split is the key to understanding where the vulnerability lives:
- N32-c (control plane) handles the initial TLS handshake between SEPPs and, critically, the security capability negotiation — the exchange that decides how N32-f will be protected.
- N32-f (forwarding plane) carries the actual proxied SBI messages — the Nudm, Namf, Npcf, and other service calls that NFs in each PLMN exchange with their roaming counterparts.
3GPP TS 33.501 §13 mandates that N32-f messages be wrapped in JSON Web Encryption (JWE), under a scheme 3GPP calls PRINS (Protocol for N32 Interconnect Security). JWE separates each SBI message into modifiable and non-modifiable Information Elements per TS 29.573, encrypting the payload end-to-end between SEPP-H and SEPP-V while still allowing IPX-level routing metadata to pass through unencrypted. The design intent is explicit: the IPX provider is a routing intermediary, not a trusted party to the content of roaming signaling.
┌───────────────────────────────────────────────────────────────────────┐
│ 5G SEPP ROAMING ARCHITECTURE │
│ │
│ HOME PLMN (HPLMN) IPX Provider VISITED PLMN │
│ │
│ [UDM]─[AMF]─[SMF] [IPX node] [AMF]─[SMF] │
│ │ │ │ │
│ [SEPP-H]──── N32-f (JWE) ──────────┤──── N32-f (JWE) ─[SEPP-V] │
│ │ │ │ │
│ Protected IPX sees only │
│ from IPX encrypted JWE │
│ │
│ ⚠ IF JWE NOT ENFORCED: IPX sees plaintext SBI (SUPI, session data) │
│ ← This is the SS7 Category-2 problem replicated in 5G │
└───────────────────────────────────────────────────────────────────────┘
This is a direct architectural response to the SS7 interconnect trust problem: rather than trusting every node on the transit path by default, 5G roaming confines trust to the two operator-controlled SEPPs and treats everything between them — including the IPX — as untrusted transport. On paper, this closes the exact gap that made SS7 location tracking and SMS interception possible at scale.
II. What JWE Is Actually Protecting
Under the PRINS model, when SEPP-H forwards an SBI request or response destined for a roaming partner, it does not simply relay the HTTP/2 message. It parses the message body, classifies each JSON attribute as modifiable (fields an IPX may legitimately need to rewrite for routing, e.g. certain header parameters) or non-modifiable (subscriber and session data that must never be altered in transit), and wraps the non-modifiable portion in a JWE object using keys established during N32-c. SEPP-V decrypts and reassembles the original SBI call before forwarding it to the internal NF.
The practical effect: an IPX operator handling millions of roaming transactions per day should never see a SUPI, an authentication vector, or a PDU session parameter in cleartext — only the routing envelope needed to move the encrypted payload to the correct destination SEPP. This is a materially stronger guarantee than anything SS7 or even Diameter offered, where IPX-level actors routinely had full visibility into MAP and Diameter AVPs by design.
III. The "NONE" Downgrade: Where Backward Compatibility Becomes a Bypass
3GPP TS 29.573 defines the N32-c security capability exchange as a negotiation, not a hard requirement. Each SEPP advertises a supportedSecCapabilityList, and the responding SEPP selects one. The list can legitimately include TLS (hop-by-hop only, not end-to-end) and NONE (no protection at all) alongside JWE — a deliberate accommodation for roaming partners transitioning from Diameter-based interconnects who haven't yet deployed SEPP JWE support.
N32-c Security Capability Exchange (3GPP TS 29.573):
SEPP-V → SEPP-H:
{
"secNegotiateReqData": {
"sender": "sepp.mnc009.mcc234.3gppnetwork.org",
"supportedSecCapabilityList": [
"TLS", ← hop-by-hop TLS (not end-to-end)
"NONE" ← no protection at all
// NOTE: "JWE" not offered
]
}
}
SEPP-H (misconfigured, accepting "NONE"):
{
"secNegotiateRspData": {
"sender": "sepp.mnc007.mcc262.3gppnetwork.org",
"selectedSecCapability": "NONE" ← 5G e2e protection waived!
}
}
The failure mode here is not a protocol bug — it is a policy failure. Nothing in the exchange is malformed; the HPLMN SEPP simply has to be configured to reject NONE for any 5G-capable partner and refuses to do so. This is functionally identical to the SS7 problem of operators leaving legacy MAP operations like AnyTimeInterrogation reachable from external Global Titles because blocking them risked breaking a roaming relationship — backward compatibility pressure quietly overriding the security model.
An adversary who can influence or observe this exchange doesn't need to break cryptography. They need only ensure the negotiation lands on NONE — whether by exploiting an already-misconfigured HPLMN SEPP, or, in a more active scenario, by operating or compromising a node on the N32-c path capable of manipulating the supportedSecCapabilityList offered during negotiation before it reaches the legitimate SEPP-H.
IV. IPX-Path Interception Mechanics
Once N32-c has settled on NONE, every N32-f message between the two SEPPs traverses the IPX as plaintext HTTP/2. Anyone positioned on that path — the IPX provider itself, or an actor who has compromised an IPX transit node — has full read and write access to roaming SBI traffic:
N32-f Forwarded Message (plaintext, no JWE):
POST /nudm-sdm/v2/imsi-262071234567890/nssai HTTP/2
Authorization: Bearer eyJhbGci... ← OAuth2 token
3gpp-Sbi-Originating-Network-Id: 5G:mnc009.mcc234.3gppnetwork.org
Content visible to IPX:
- SUPI: imsi-262071234567890 ← permanent identity
- Request type: subscription data query
- Serving AMF: amf01.mnc009.mcc234... ← roaming AMF location
- PDU session data, NSSAI slices ← service configuration
This is not limited to passive observation. Because the message is unencrypted end-to-end, the intercepting party can also modify it in transit — inserting, deleting, or altering SBI parameters — with neither SEPP able to detect the tampering, since JWE's integrity protection never applied in the first place. Reachable N32-f calls in this state include:
- Nudm_SubscriberDataManagement (UDM ↔ AMF roaming) — exposes SUPI, subscription data, and allowed NSSAI
- Nudm_UEContextManagement (UDM ↔ AMF) — exposes the subscriber's serving AMF, which maps directly to a geographic region, functionally equivalent to the location intelligence SS7's SendRoutingInfo and ProvideSubscriberInfo provided
- Npcf_PolicyAuthorization (PCF ↔ AF) — QoS parameters and traffic routing policy, modifiable in transit
- Namf_EventExposure (AMF ↔ external AF) — UE location events and registration state
The parallel to legacy signaling interception is not cosmetic. An IPX-positioned adversary reading N32-f in "no protection" mode obtains the same category of intelligence — permanent subscriber identity, approximate location via serving node, and session metadata — that made commercial SS7 surveillance platforms viable, with the added capability of silently rewriting the data rather than merely observing it.
V. ENISA's 2023 Assessment: The Regression Documented
This is not a theoretical concern. The European Union Agency for Cybersecurity conducted a 5G security assessment spanning multiple European operators and published SEPP-specific findings in its 2023 "5G Cybersecurity Standards" report:
| Finding | Operators Affected |
|---|---|
| SEPP deployed with N32 backward-compatibility mode enabled | Several EU operators |
SEPP accepting NONE security capability for 5G-capable partners | Documented in assessment |
| N32-f JWE not enforced across all roaming partner combinations | Common finding |
| Operator unaware of the N32-c negotiation outcome for a given partner | Majority assessed |
ENISA's root cause analysis matched the mechanism described above: operators had configured NONE support to interoperate with roaming partners who hadn't yet deployed SEPP JWE, but left that configuration active indiscriminately — including for partners who had deployed a JWE-capable SEPP, effectively opting out of end-to-end protection with no compensating control in place. The report's conclusion is unambiguous: N32 without enforced JWE provides no meaningful security improvement over legacy Diameter roaming, and the SS7 Category-2 vulnerability class is, in practice, reproduced in 5G Standalone roaming deployments that should have retired it.
1. Enforce JWE on every N32-f message, with no exceptions list. The SEPP must reject any N32-f message that is not JWE-wrapped and must never offer or accept NONE for a 5G SBA roaming partner. A backward-compatibility carve-out with an empty exception list is the only safe configuration — partial exceptions are how this vulnerability class re-enters production.
sepp:
n32:
security_capability:
offered_capabilities: ["JWE"] # Only offer JWE
minimum_acceptable: "JWE" # Never accept NONE or TLS-only
reject_none_capability: true
on_non_jwe_n32f:
action: reject
http_status: 403
log: true # Log for SIEM
backward_compat_exception:
allowed_for: [] # No exceptions - all partners must use JWE
2. Enforce N32-c policy at negotiation time, not after the fact. The HPLMN SEPP must only ever offer JWE in supportedSecCapabilityList, must abort any exchange where the visiting SEPP selects NONE, and must alert on any downgrade attempt rather than silently accepting it.
| N32-c Policy Rule | Action | TS Reference |
|---|---|---|
Remote SEPP offers only NONE | REJECT | TS 33.501 §13.2.4 |
Negotiation result = NONE | ABORT | TS 33.501 §13.2.4 |
| Remote SEPP presents no valid certificate | REJECT | TS 33.501 §13.1 |
| Downgrade from JWE to NONE attempted mid-relationship | ALERT | FS.37 §6.3 |
3. Run continuous SEPP audits against GSMA FS.37, not a one-time deployment check. Every roaming partner in the SEPP routing table needs a recorded, current N32-c negotiation result; every partner should show JWE, and any partner showing NONE is a live finding, not background noise.
# Query active N32 sessions and their security capability (vendor-specific)
sepp-admin list-n32-sessions --show-security-capability
# Expected output (compliant):
# Partner | N32-c Result | JWE Enforced
# sepp.mnc009.mcc234 | JWE | Yes
# sepp.mnc010.mcc310 | JWE | Yes
# (no partner should show NONE)
Verification (Authorized Lab Assessment)
# Test 1: N32-c capability exchange offering only NONE
# Expected: SEPP rejects; N32 session not established
# Test 2: N32-f forwarded message without a JWE wrapper
# Expected: SEPP returns 403 Forbidden; message not forwarded to UDM/AMF
# Test 3: N32-c offering JWE + NONE; verify selected capability
# Expected: SEPP selects JWE only; NONE is never selected
# Test 4: Valid JWE-protected N32-f message from an authorized roaming partner
# Expected: SEPP decrypts, validates, and forwards to the internal NF
VI. Authoritative References
- 01 3GPP TS 33.501Security architecture and procedures for the 5G system, §13 - SEPP and N32 security3GPP TS 33.501 – 5G Security Architecture →
- 02 3GPP TS 29.5735G System; Public Land Mobile Network (PLMN) Interconnection; N32 interface3GPP TS 29.573 – N32 Interface Specification →
- 03 GSMA FS.375GS Roaming Guidelines - SEPP Security ConfigurationGSMA Security Resources & Guidelines →
- 04 ENISA 5G Cybersecurity Standards Report (2023)5G Security Controls Matrix and Roaming Assessment FindingsENISA 5G Security Controls →
- 05 3GPP TS 29.510NRF Services - NF discovery referenced in SEPP roaming context3GPP TS 29.510 – NRF Services →
VII. Frequently Asked Questions
Both, in a specific sense. 3GPP standardized the NONE capability outcome deliberately, as a bridge for roaming partners without SEPP JWE support. It is not a flaw in the cryptography or the protocol itself — it is a policy decision left to the operator. The vulnerability appears when operators leave that bridge open for partners who no longer need it, or fail to audit which partners are still negotiating NONE. That gap between "standardized fallback" and "enforced default" is where the exposure lives.
NSA deployments anchor on the 4G EPC core and typically route roaming signaling over Diameter rather than N32, so this specific SEPP bypass targets 5G Standalone (SA) roaming relationships. NSA subscribers remain exposed to the separate, well-established class of Diameter roaming vulnerabilities that predate SEPP entirely.
Mechanically almost identical — an actor positioned on the interconnect transit path (IPX) reads or modifies signaling never meant to reach them. The difference is that SS7 had no protection to bypass; there was never end-to-end encryption to downgrade. The SEPP N32 case is a regression: 5G built the correct control (JWE-protected N32-f) specifically to prevent this, and the vulnerability is that the control can be silently disabled per roaming relationship.
Yes, but only if they are actively auditing N32-c negotiation outcomes — the ENISA assessment found most operators were not. The SEPP should log every capability negotiation result, and a GSMA FS.37-aligned audit process should flag any partner showing anything other than JWE as an open finding requiring remediation, not a routine roaming configuration note.
No. N32-c TLS protects the capability negotiation channel itself against tampering by an unrelated third party, but it does not change what capability the two SEPPs agree to select. A TLS-protected negotiation can still legitimately conclude with selectedSecCapability: "NONE" if the HPLMN SEPP's policy allows it — TLS secures the conversation, not the outcome of it.
Conclusion & Next Steps
The SEPP N32 architecture is a genuine improvement over the SS7 and Diameter roaming model — mutual TLS at N32-c, certificate-bound SEPP identity, and JWE-protected N32-f collectively remove the implicit trust that made Category-2 interception trivial for decades. But that improvement is entirely conditional on JWE actually being enforced, and 3GPP's own backward-compatibility accommodation gives operators a standards-compliant way to quietly opt out. ENISA's 2023 findings show this isn't a hypothetical misconfiguration — it is a documented, recurring pattern across live EU roaming deployments.
The path forward for operators running or peering with a 5G SA core:
- Immediate: Audit every active N32-c session and confirm
selectedSecCapability = JWEfor every roaming partner - Short-term: Remove
NONEfrom the SEPP's offered and acceptable capability lists entirely — zero exceptions - Medium-term: Build continuous N32-c negotiation monitoring into SIEM, alerting on any downgrade attempt
- Long-term: Formalize GSMA FS.37 SEPP audits as a recurring assessment, not a one-time deployment gate
Understanding how 5G roaming security can regress to its SS7 predecessor is essential context for anyone assessing a live 5G core. Explore our 5G SBA vulnerability research for the broader Service Based Architecture attack surface, or review SS7 location tracking for the interception model this bypass reproduces.
