The 5G Security Roadmap: 256-Bit Crypto, Post-Quantum, and the Interconnect Gap

The roadmap, not the redesign

There is already a good answer to "what is 5G security." The 5G security architecture was rebuilt from the key ladder up: a longer key hierarchy, home-network control over authentication, SUPI concealed as SUCI with ECIES so the permanent identity never crosses the air in clear, and the first integrity protection on the user plane. If you need the mechanics of 5G-AKA, NEA/NIA ciphering, or the SEPP that fronts roaming, those are spoke articles and they cover the current state well. This is not that article.

This is the roadmap. It answers a different, more uncomfortable question: where is 5G security actually going, and how big is the gap between what the specs promise and what runs in production today? Three gaps drive everything below. First, 5G fixed attribution on the interconnect — it did not fix trust, and the roaming ecosystem has not finished adopting even the attribution fix. Second, the 256-bit air-interface algorithms have been fully standardized since March 2024 and are wired into nothing. Third, post-quantum is a multi-year migration that, for 3GPP, has barely started — it is still at the inventory stage.

Every number below is sourced to a primary document I or the research team read directly: TS 33.501 V20.1.0 (the March 2026 spec), the GSMA NG.132 roaming report, the FCC reimbursement reports, NVD CVE records, and the relevant 3GPP study reports. Where a claim rests on a press account or a preprint rather than a spec, I say so. This is a hub: it stays at pillar altitude and links down to the spokes for the mechanics.

5G fixed attribution, not trust — and the ecosystem hasn't caught up

The interconnect's original sin is that SS7 and Diameter were built for a closed club of trusted operators. Any node on the signalling network was implicitly believed. That assumption is why in May 2017, O2 Telefónica Germany confirmed that attackers had exploited SS7 to redirect banking mTANs and drain customer accounts — the foreign-operator network access used in the attack was obtained in January 2017 (this is a press-attributed operator confirmation, so treat it as reported, not spec-grade). The underlying SS7 weaknesses had been public since Engel and Nohl demonstrated them in 2014. ENISA's March 2018 assessment rated interconnect signalling security — across SS7, Diameter, and 5G — at a "medium to high level of risk."

3GPP SA3's own framing is unusually candid about what 5G set out to repair. The stated goal of 5G SA roaming security is to address "the root cause of a wide range of attacks that have taken and continue to take place over the roaming infrastructure in the past decades: the lack of attribution." Read that carefully. The fix is attribution — making messages provably originate from a named operator — not the elimination of trust between operators. The mechanism is the SEPP and the N32 interface, which splits into N32-c (mutual SEPP authentication and security-mechanism negotiation) and N32-f (the actual signalling exchange).

N32-f can be protected two ways, and the difference matters more than most overviews admit (it is the subject of Figure 1):

• TLS, for bilateral / direct roaming. Two SEPPs, one mutually-authenticated TLS connection, end to end. Simple.
• PRINS, for mediated roaming. Application-layer security using a JOSE profile, designed so that contracted intermediaries (IPX hubs) can read and modify selected information elements under negotiated protection and modification policies. 3GPP allows a maximum of two roaming intermediaries, each contracted to one SEPP's PLMN, when the intermediary does more than plain IP routing.

Here is the part the marketing skips. PRINS is the clever, hub-friendly design — and the GSMA concluded plain TLS, not PRINS, for the first phase. The 5GMRR work (GSMA NG.132; cite the current v5.0, which retains the v4.0 conclusion) states that, on the principle of "simplest model per use case," TLS is the connection model for Phase 1 bilateral inter-PLMN roaming; intermediaries — IPX, Hosted SEPP, RVAS, Roaming Hub — are deferred to Phase 2. Public data quantifying live PRINS deployments does not exist; the honest characterization is that PRINS adoption remains limited and in progress, not that "nobody runs PRINS." For the SEPP component mechanics, see the SEPP roaming security spoke.

And the spec itself concedes the gap. SA3's article states plainly that 5G's end-to-end security approach "represents a fundamental change" but that "the roaming ecosystem, with its diverse set of players and stakeholders, still needs to fully embrace this approach at the time of writing."

Your 5G security is only as good as your 2G fallback

There is a sharper edge to this. NG.132 says, in writing, that when a roamer moves across 2G/3G/4G/5G in a visited network with parallel legacy links, the signalling between visited and home network "switches from HTTP to Diameter to SS7." That sentence sits in the cross-generation access discussion (the "welcome SMS" / RVAS case) — keep that context — but the implication is blunt: the strongest N32 protection you deploy on the 5G plane can be sidestepped by generation fallback. It is the 2017 mTAN lesson, one layer up. On the user plane, NG.132 requires IPUPS (Inter-PLMN UP Security, defined in Release 16) on N9 between operators, with NDS/IP — but that, too, only protects the 5G path.

The 256-bit paradox: standardized since 2024, deployed nowhere

This is the cleanest example of "standardized is not deployed" in the whole security stack, and it is verifiable by anyone who downloads the spec.

The three 256-bit algorithm sets are fully specified, each as a three-document series, all in Release 18, all under change control. Their official titles say "Snow 5G based," "AES based," and "ZUC based" 256-bit sets:

• TS 35.240–242 (SNOW 5G based): 256-NEA4 / 256-NIA4 / 256-NCA4
• TS 35.243–245 (AES based): 256-NEA5 / 256-NIA5 / 256-NCA5
• TS 35.246–248 (ZUC based): 256-NEA6 / 256-NIA6 / 256-NCA6

NCA is a new authenticated-encryption algorithm class. The first versions (v18.0.0) were published in March 2024. So the algorithms exist, named, frozen, available.

Now grep the system spec. A direct search of TS 33.501 V20.1.0 (March 2026) finds zero occurrences of 256-NEA, 256-NIA, or 256-NCA. Annex D — the normative list of ciphering and integrity algorithms — still contains only NEA0 (null) and the 128-bit sets (128-NEA1/2/3 and 128-NIA1/2/3). Two years after the algorithms were standardized, the 5G system does not reference them. The transition machinery is the long pole: it is being studied in TR 33.700-41, "Study on enabling a cryptographic algorithm transition to 256bits" (Release 19) — a study, not a normative integration. The background work goes back to TR 33.841 (created January 2018), done in collaboration with ETSI SAGE. There is no committed 3GPP release or date for normative 256-bit integration into TS 33.501; do not let anyone tell you there is. The honest framing is that many commentators expect it in the 6G timeframe, but that is attribution, not a spec milestone.

Why the lag? The drivers are not a known weakness in 128-bit AES today — they are the long device-and-network lifecycle of mobile infrastructure and the looming quantum question, which is the next section. The encryption algorithms spoke documents the deployed 128-bit NEA/NIA sets in detail; this pillar covers only their not-yet-wired successors.

Post-quantum on a telco timetable

Post-quantum cryptography deserves its own deep treatment, and it has one: the quantum-safe cryptography for 5G/6G spoke covers the NIST algorithm families and the operator migration path in depth. Here I stay at roadmap altitude — where PQC sits in the 3GPP and GSMA programme, and how it connects to the 256-bit track above.

The baseline is set. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) on 13 August 2024. Every telco PQC migration builds on those three standards. It is worth keeping the threat model straight, because the 256-bit and PQC tracks answer different attacks. Grover's algorithm weakens symmetric crypto by a square-root factor, which is the long-horizon argument for moving NEA/NIA from 128-bit to 256-bit keys. Shor's algorithm breaks asymmetric crypto outright — which is what threatens the public-key parts of the system: the ECIES that conceals SUCI, the certificates and key exchange underneath TLS on the SBI and N32, and IPsec on the backhaul. The 256-bit track and the PQC track are not substitutes; they harden different layers.

On the industry side, the GSMA Post Quantum Telco Network (PQTN) task force was initiated by IBM and Vodafone at MWC Las Vegas in 2022 and grew to "more than 50 companies and over 20 major operators" (that membership count dates to 2023 and is likely higher now). GSMA PQ.03, "Post Quantum Cryptography – Guidelines for Telecom Use Cases," v2.0, was published 4 October 2024, building on the PQ.01 impact assessment and pushing a phased, prioritized migration; PQ.06 covers a prototype of hybrid PQC key exchange for the base-station / security-gateway IPsec link.

3GPP's contribution so far is deliberately upstream of any algorithm swap. Its first concrete PQC deliverable is TR 33.938, the "3GPP Cryptographic Inventory." This is Release 19 — and that release label is load-bearing: the portal shows "Initial planned Release: Release 19," and the archived versions are 19.0.0 (June 2025), 19.1.0 (September 2025), and 19.2.0 (January 2026). It has been under change control since June 2025. The inventory is exactly what it sounds like — a catalogue of where cryptography lives across 3GPP systems — and it is the precondition for any migration decision. You cannot replace what you have not enumerated. There is no normative PQC integration into TS 33.501 as of V20.1.0, and no committed date for one.

When the core is just software, it inherits software's bugs

The 5G core is the service-based architecture: network functions exposing RESTful services over HTTP/2, secured per TS 33.501 with TLS on the SBI (clause 13.1), NF authentication and a client credentials assertion (clause 13.3, CCA at 13.3.8), and OAuth 2.0 authorization where the NRF acts as the OAuth 2.0 authorization server, issuing access tokens per RFC 6749 (clause 13.4.1). That is a strong design on paper. It is also software, and software has a bill of materials and a CVE list.

A clear, important caveat first: no citable security incident against a production 5G SBA or SEPP deployment was found. Do not claim one exists, and do not claim 5G interconnect "has never been attacked" — that is absence of evidence. The documented incidents remain SS7/Diameter-era. What does exist, with CVE numbers, are vulnerabilities in open-source 5G core implementations and lab research:

• CVE-2025-63288: Open5GS 2.7.6 crashes its AMF (denial of service) on a malformed NGSetupRequest. CVSS 3.1 base score 7.5 (network vector, no privileges required), CWE-400, published 10 November 2025. Note the score is CNA-supplied, not NIST-assigned.
• The cross-service token attack (arXiv 2509.08992, 2025): free5GC is the only public open-source 5GC with a Release-17-compliant OAuth 2.0 SBI implementation (Open5GS and OpenAirInterface lack OAuth enforcement). Researchers reported 8 vulnerabilities, the worst a token-scope check whose failure was silently ignored — a wrapped nil-error bug — so that a token issued for one NF service could access other services. That is privilege escalation inside the SBA, defeating the exact OAuth boundary clause 13.4.1 is meant to enforce. All were confirmed by free5GC; 7 were patched at the time of writing. This is a vendor-acknowledged preprint, so weight it as such.

The lesson is structural. The OAuth/NRF authorization model is only as strong as its implementation, and "we use OAuth 2.0" is not the same as "scope is enforced on every call." If you run an open-source core in a lab or a private network — see the free5GC on Kubernetes walkthrough — track these advisories and patch the OAuth path specifically. If you want to reproduce how SBA traffic actually looks on the wire to audit it, the 5G PCAP analysis guide shows how to correlate the HTTP/2 SBA mesh with NGAP and NAS.

Zero trust was retrofitted, and 3GPP graded its own homework

The reference framework is NIST SP 800-207 (final, August 2020) with its seven tenets — among them "all communication is secured regardless of network location." The zero-trust-in-5G spoke covers the principles and why perimeter security fails in the SBA. The roadmap angle is different and more interesting: 3GPP measured its own architecture against those tenets, and the results are a scorecard, not a victory lap.

Two studies, both verified on the portal. TR 33.894, "Study on applicability of the zero trust security principles in mobile networks" (Release 18), evaluated the existing 5GC mechanisms tenet-by-tenet against NIST SP 800-207 using a network-centric model. TR 33.794, "Study on enablers for Zero Trust Security" (Release 19, under change control since December 2024), shifted to a management-plane-centric model focused on security monitoring and policy enforcement. Both target the SBA.

The honest reading — supported by Ericsson's February 2025 summary of the two studies — is that the SBA's mTLS-plus-OAuth2 story covers the tenets that depend on securing communication paths that actually use HTTPS and tokens. Where it is thin is the dynamic, continuous side of zero trust: real-time security monitoring and adaptive policy enforcement, which is precisely why those were pushed into the Release-19 enabler study (TR 33.794) rather than declared solved. Figure 3 lays this out as a tenet-by-tenet scorecard.

If you operate a core, the takeaway is to treat the OAuth/NRF authorization layer and continuous monitoring as the two areas where the spec is still catching up to the principle — not as finished features. Want to run a hardened core in a lab and see these controls behave? You can start a free 7-day trial — no card — and work through the SBA security and roaming labs hands-on.

The regulatory layer: where security becomes procurement

The last gap is not cryptographic at all — it is policy, and it has the biggest line items.

The EU 5G Toolbox ("Cybersecurity of 5G networks — EU Toolbox of risk mitigating measures") was published in January 2020 by the NIS Cooperation Group, combining strategic and technical measures, including restrictions on high-risk suppliers for critical and sensitive network assets. On 15 June 2023, a Commission communication stated that "Huawei and ZTE represent in fact materially higher risks than other 5G suppliers," deemed member-state restrictions justified, and applied the same criteria to the Commission's own communications and EU funding programmes.

The US version is the FCC's Secure and Trusted Communications Networks Reimbursement Program — "rip and replace." The numbers, from the FCC reports (cite the Seventh Report, December 2025, which supersedes the Sixth but carries the same core figures): Congress appropriated $1.9 billion against $4.98 billion in approved cost estimates — a $3.08 billion shortfall. The FY2025 NDAA (signed 23 December 2024) authorized borrowing up to $3.08 billion from the US Treasury; the FCC borrowed the full $3.08 billion in March 2025 and began allocating further funding from 15 April 2025. The strategic point for an engineer: a non-trivial share of "5G security" spend is being driven by supply-chain trust decisions, not by any flaw in the air-interface crypto — and that money competes for the same budget that would fund 256-bit and PQC migration.

What to actually do with this

The roadmap, compressed:

• Roaming: 5G gives you attribution on N32 — deploy it (SEPP, TLS-first per GSMA Phase 1), but assume generation fallback to Diameter/SS7 remains your real exposure until legacy is retired. PRINS is for mediated roaming and adoption is still early.
• 256-bit: The algorithms (256-NEA/NIA/NCA, TS 35.240–248) are ready; the system is not. Track TR 33.700-41. Do not budget for a 256-bit cutover on a fixed date — there isn't one.
• Post-quantum: Start your own cryptographic inventory now, mirroring TR 33.938's logic — you cannot migrate what you have not catalogued. Watch GSMA PQ.03 and the quantum-safe cryptography spoke for the algorithm-level detail. The first targets are the asymmetric layers Shor threatens (ECIES/SUCI, TLS, IPsec), not the symmetric NEA/NIA.
• SBA software: Your OAuth-on-NRF boundary is exactly as strong as its implementation. Patch open-source cores against the known scope-enforcement and DoS CVEs; verify token scope is enforced on every service call.
• Zero trust: 3GPP graded the SBA "partial" — monitoring and dynamic policy are the Release-19 gaps. Build observability around the SBA yourself rather than waiting for the spec.

5G's security architecture is genuinely better than 4G's at the layers it redesigned. The work that remains is in the seams: the interconnect ecosystem that hasn't finished adopting the fix, the 256-bit algorithms waiting for a transition spec, the PQC migration still at the inventory stage, and the software supply chain that turned cryptographic guarantees into CVE-tracked implementation details. That is the roadmap — and it is mostly ahead of us.