Why Zero Trust Matters for 5G

Traditional perimeter-based security assumed everything inside the network was trusted. A firewall at the edge protected a flat internal domain. This model collapses in 5G for three structural reasons:

1. Service-Based Architecture (SBA): The 5G Core is decomposed into dozens of Network Functions (NFs) communicating over HTTP/2 APIs. Each NF is a potential attack surface. A compromised NF that is implicitly trusted can laterally move to any other NF.

1. Multi-stakeholder deployment: Network slicing, edge computing, and neutral-host models mean multiple organizations share infrastructure. Trust boundaries between MNOs, MVNOs, enterprises, and hyperscalers cannot be assumed.

1. Cloud-native infrastructure: NFs run as containerized microservices on shared Kubernetes clusters. A container escape or compromised pod can access the host network unless microsegmentation is enforced.

The Zero Trust model -- defined by NIST SP 800-207 -- mandates that no entity is trusted by default, every access request is authenticated and authorized independently, and least-privilege access is enforced continuously. 3GPP has embedded Zero Trust principles into the 5G security architecture starting with TS 33.501 (Security architecture and procedures for 5G System) and extended through TS 33.510 (Security for the 5GC SBA) and TS 33.855 (Study on security of the 5G SBA).

Core Principles Applied to 5G

5G SBA Security Mechanisms

NF Registration and Discovery Security

The NRF (Network Repository Function) serves as the trust anchor for the 5GC SBA. When an NF registers, it presents an X.509 certificate issued by the operator's PKI. The NRF validates the certificate chain, NF type, and PLMN ID before storing the NF profile. Discovery requests are also authenticated -- an NF requesting discovery of another NF must present a valid OAuth2.0 access token.

Registration flow (TS 33.501 Section 13.2):

1. NF establishes mTLS connection to NRF using its client certificate
2. NRF validates certificate against trusted CA chain
3. NF sends NFRegister request with NF profile (type, services, PLMNs, slice info)
4. NRF validates NF type matches the certificate's Subject Alternative Name (SAN)
5. NRF stores profile and returns 201 Created with NF instance ID

OAuth2.0 Token Flow in 5GC

3GPP adopted the OAuth 2.0 Client Credentials Grant (RFC 6749 Section 4.4) for NF-to-NF authorization. The NRF acts as the Authorization Server.

The JWT contains claims including nfType, nfInstanceId, scope (e.g., namf-comm, nsmf-pdusession), snssaiList, and plmnId. This ensures an NF can only access the specific services it needs on specific slices.

Worked Example 1 -- OAuth2.0 Token Validation

Scenario: The SMF needs to create a session with the AMF for a UE on slice S-NSSAI (SST=1, SD=000001). Step 1 -- Token Request: `

POST /oauth2/token HTTP/2

Host: nrf.5gc.mnc001.mcc310.3gppnetwork.org

Content-Type: application/x-www-form-urlencoded

TLS Client Certificate: CN=smf-01.5gc.operator.com

grant_type=client_credentials

&scope=namf-comm

&target_nf_type=AMF

&requester_nf_type=SMF

&requester_snssai_list=[{"sst":1,"sd":"000001"}]

` Step 2 -- NRF Validates and Issues Token:

• NRF verifies client cert CN matches registered SMF instance
• NRF checks that SMF is authorized to access AMF services for this S-NSSAI
• NRF generates JWT with 15-minute expiry:

`json

{

"iss": "nrf.5gc.mnc001.mcc310.3gppnetwork.org",

"sub": "smf-01-instance-id",

"aud": "amf.5gc.mnc001.mcc310.3gppnetwork.org",

"scope": "namf-comm",

"snssaiList": [{"sst": 1, "sd": "000001"}],

"exp": 1711540800,

"iat": 1711539900

}

` Step 3 -- SMF Calls AMF: `

POST /namf-comm/v1/ue-contexts/{supi}/n1-n2-messages HTTP/2

Host: amf.5gc.mnc001.mcc310.3gppnetwork.org

Authorization: Bearer eyJhbGciOiJFUzI1NiIs...

` Step 4 -- AMF Validates Token:

• Verifies JWT signature against NRF public key
• Checks exp > current time
• Checks aud matches its own NF instance
• Checks scope includes namf-comm
• Checks snssaiList includes the requested S-NSSAI
• If all pass, processes the request; otherwise returns 403 Forbidden

This per-request token validation ensures that even if an NF is compromised, it cannot access services outside its authorized scope.

Microsegmentation Strategies

Microsegmentation in 5G operates at three layers:

Worked Example 2 -- Kubernetes Network Policy for NF Isolation

Scenario: Operator Y runs AMF and SMF in the same Kubernetes cluster. Zero Trust requires that the SMF pod can only communicate with the AMF on port 29518 (Namf SBI port) and the NRF on port 29510. Network Policy (Calico/Cilium): `yaml

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: smf-egress-policy

namespace: 5gc-cp

spec:

podSelector:

matchLabels:

nf: smf

policyTypes:

- Egress

egress:

- to:

- podSelector:

matchLabels:

nf: amf

ports:

- port: 29518

protocol: TCP

- to:

- podSelector:

matchLabels:

nf: nrf

ports:

- port: 29510

protocol: TCP

- to:

- podSelector:

matchLabels:

nf: upf

ports:

- port: 8805

protocol: UDP # PFCP

`

This policy denies all egress traffic from the SMF except to the AMF (Namf), NRF (Nnrf), and UPF (N4/PFCP). If the SMF is compromised, lateral movement to the UDM, AUSF, or other NFs is blocked at the network layer -- before the OAuth token check even occurs.

SCP as Zero Trust Enforcement Point

The Service Communication Proxy (SCP), defined in TS 29.500, acts as a centralized or distributed proxy between NFs. In Zero Trust architecture, the SCP becomes the primary policy enforcement point (PEP):

• Token relay and validation: SCP validates Bearer tokens before forwarding requests, offloading validation from individual NFs.
• Rate limiting: Per-NF, per-service rate limits prevent compromised NFs from flooding others.
• Logging and auditing: All SBI transactions pass through SCP, providing a complete audit trail for SIEM integration.
• Load balancing: SCP distributes requests across NF instances with health-aware routing.

Deutsche Telekom's 5G Core deployment (2024) uses the SCP model with Envoy-based sidecars in a service mesh, achieving 100% SBI traffic encryption and reducing average token validation latency to 0.8 ms per request. Their implementation logs all SBI transactions to a Splunk SIEM, enabling real-time anomaly detection.

Operator Deployment Data

T-Mobile US -- Zero Trust SBA Implementation

T-Mobile deployed Zero Trust controls across their 5G SA Core in 2024:

• mTLS enforcement: 100% of SBI interfaces use TLS 1.3 with ECDSA-P256 certificates
• OAuth2.0 adoption: All NF-to-NF communication requires bearer tokens with 15-minute TTL
• Token validation rate: 2.4 million token validations per second across the SBA
• Certificate rotation: Automated rotation every 24 hours using cert-manager on Kubernetes
• Lateral movement incidents: Reduced from 12 (2022, NSA Core) to 0 (2024, 5G SA with ZTA)
• Incident detection time: Improved from 48 hours average to 4.2 hours with SCP-based anomaly detection

SK Telecom -- Slice-Level Microsegmentation

SK Telecom implemented per-slice Zero Trust policies for their enterprise 5G slicing service:

• Slice isolation: Dedicated NF instances per enterprise slice with separate Kubernetes namespaces
• Cross-slice traffic: Zero permitted flows between enterprise slices (enforced via Calico network policies)
• Authentication overhead: 1.2 ms average per OAuth2.0 token exchange (NF-to-NRF round trip)
• Policy violations detected: 847 per month (primarily misconfigured NF service registrations), all blocked
• Compliance: Achieved GSMA NESAS (Network Equipment Security Assurance Scheme) certification for all core NFs

mTLS Certificate Management at Scale

Managing certificates for hundreds of NF instances across a 5G Core is a critical operational challenge. A typical large-scale deployment involves:

• 200+ NF instances (AMF, SMF, UDM, AUSF, PCF, UPF, etc.)
• Each NF requires a unique X.509 certificate with SAN matching its FQDN
• Certificate lifetime must be short (hours to days) to limit exposure from compromised keys
• Rotation must be automated and zero-downtime

3GPP TS 33.310 specifies the PKI framework for 5G, mandating operator-managed CAs with cross-certification for roaming. In practice, operators use:

• HashiCorp Vault or cert-manager for automated issuance and rotation
• SPIFFE/SPIRE for workload identity in Kubernetes-based cores
• Hardware Security Modules (HSMs) for CA root key protection (FIPS 140-2 Level 3)

Post-Quantum Considerations

Current 5G mTLS relies on ECDSA and ECDH for key exchange and authentication. With quantum computing advances, these algorithms are vulnerable to Shor's algorithm. NIST finalized post-quantum cryptography standards in 2024:

• ML-KEM (Kyber): Key Encapsulation Mechanism for key exchange
• ML-DSA (Dilithium): Digital Signature Algorithm for authentication

3GPP SA3 is studying the integration of PQC into 5G security in Release 19 study items. The challenge is larger key and signature sizes: ML-DSA-65 signatures are 3,293 bytes vs 64 bytes for ECDSA-P256, impacting SBI message overhead and token sizes.

Implementation Roadmap

Operators transitioning to Zero Trust should follow a phased approach:

1. Phase 1 (3--6 months): Enable mTLS on all SBI interfaces, deploy SCP, implement certificate automation
2. Phase 2 (6--12 months): Implement OAuth2.0 token-based authorization for all NF-to-NF communication
3. Phase 3 (12--18 months): Deploy microsegmentation with Kubernetes network policies, per-slice isolation
4. Phase 4 (18--24 months): Integrate SBI transaction logging with SIEM, deploy anomaly detection ML models
5. Phase 5 (24+ months): Begin PQC migration for certificates and token signing algorithms

Key Takeaway: Zero Trust Architecture is not optional for 5G -- the SBA's distributed, multi-stakeholder nature demands it. 3GPP TS 33.501 and TS 33.510 provide the normative foundation with mTLS and OAuth2.0, while the SCP acts as the policy enforcement point. Operators like T-Mobile and SK Telecom have demonstrated that ZTA eliminates lateral movement attacks and reduces incident detection time by 10x. The next frontier is post-quantum cryptography integration, which 3GPP SA3 is actively studying for Release 19 and beyond.