5G Security Guide: Architecture, Network Slicing and SIM Identity

5G is far more secure by design than 4G, but most of those protections are optional, depend on a standalone 5G core, or only work if the operator switches them on. The 3GPP security architecture in TS 33.501 adds concealed subscriber identities, a home-controlled authentication model, a security proxy at every roaming border and OAuth 2.0 authorisation between core network functions. The core is now cloud-native software on Kubernetes, with every container and secrets problem that brings. This guide explains the 5G security architecture, network slicing, the machine identities inside the service-based core, private 5G and enterprise use of 5G, with the settings and questions that matter. It is for operator security architects and enterprise teams buying private 5G, 5G IoT or 5G-based SD-WAN.

Key takeaways

• Standalone matters. SUCI, 5G AKA home control, the SEPP and the service-based core security model come with the 5G Core; a non-standalone deployment that rides on a 4G core does not deliver them.
• The null scheme defeats SUCI. Subscriber identity concealment only protects the permanent identifier when the operator provisions home network keys and a non-null ECIES profile on the SIM.
• The 5G core is a non-human identity system. Every network function holds an X.509 certificate and requests OAuth 2.0 access tokens from the NRF, so certificate and token governance is now core network security.
• Slices are a policy promise, not a wall. Isolation between slices depends on per-slice credentials, separate data stores, rate limits and monitoring that NSA and CISA describe in detail; shared infrastructure stays shared.
• Legacy signalling still applies. 5G roaming uses HTTP/2 through the SEPP, but interworking with 4G, 3G and 2G keeps SS7, Diameter and GTP firewalls in scope.

The 5G security architecture in brief

3GPP TS 33.501 defines security for the 5G System. It is organised by security domains (clause 4.1) and covers network access security, network domain security, the service-based architecture and roaming.

Primary authentication: 5G AKA and EAP-AKA'

• Two methods: TS 33.501 specifies EAP-AKA' (clause 6.1.3.1) and 5G AKA (clause 6.1.3.2). Both derive keys from the long-term secret on the USIM and both give mutual authentication between the device and the home network.
• Home control: the home network, through the AUSF, confirms that the device actually authenticated in the visited network. GSMA describes this as a defence against roaming fraud, because a visited network can no longer claim an authentication that did not happen.
• Private network credentials: GSMA FS.40 notes that non-public networks can use non-AKA methods such as EAP-TLS, so an enterprise can authenticate devices with certificates.

Radio and user plane protection

• User plane integrity: 5G adds integrity protection for user traffic between the device and the gNB (clause 6.6.4.2), which 4G lacked. Activation is a policy decision, so check it is on.
• NAS security: NSA and CISA list NAS integrity and confidentiality as a baseline layer for slice security, alongside mutual TLS between functions and IPsec on non-service-based interfaces.
• False base stations: GSMA FS.40 states that false base stations cannot be prevented outright, so the practical goal is to block insecure downgrades and to deny them anything useful, which is what SUCI does for the identifier.

SIM identity: SUPI, SUCI and the null scheme

The SUPI is the permanent subscriber identifier on the SIM, the 5G counterpart of the 4G IMSI. In LTE the IMSI could be sent in plaintext before the network authenticated, which is what IMSI catchers exploit. 5G conceals it as the SUCI, encrypted with the home network public key so that only the home network can read it. NIST CSWP 36A, which focuses on SUCI, sets out the operational details:

• Where it is computed: the SUCI is calculated by the device or by the USIM. The SIM must support the calculation and must carry the home network public key, which can be provisioned at personalisation or updated over the air.
• Protection schemes: TS 33.501 Annex C defines the null scheme and two ECIES profiles, Profile A and Profile B. NIST notes Profile B uses parameters aligned with NIST SP 800-56A. Operators can set priorities when a subscription has more than one scheme.
• The null scheme: it does not encrypt the SUPI at all. NIST and GSMA both tell operators to configure a non-null scheme. The FCC's CSRIC advisory group recommends that US operators avoid null encryption except for unknown devices requesting emergency services.
• What stays visible: the mobile country code and mobile network code stay in the clear so the visited network can route the request home.
• Who decrypts: the SIDF in the home UDM holds the private key; roaming SUCIs are sent home for de-concealment.
• The optional trap: NIST notes that Release 15 or later devices must support SUCI but enabling it in the network is optional for operators, and that SUCI gives no protection on 4G LTE.

For enterprises the SIM is also the device's identity anchor. eSIM profiles are downloaded over HTTPS, with the SM-DP+ and the eUICC mutually authenticating using PKI certificates, according to GSMA. GSMA FS.43 covers security guidelines for storing UICC credentials. Treat SIM inventory and swap processes as identity lifecycle controls. See the SIM Swap Fraud Guide and the Device and IoT Identity Guide.

The service-based core: certificates and OAuth 2.0 between network functions

In the service-based architecture, network functions (NFs) expose HTTP/2 APIs to each other. GSMA FS.40 states that NFs use HTTP/2 over TLS with server and client certificates and that OAuth 2.0 authorises access to NF services with fine-grained tokens per consumer.

Where identity fits

• The NRF is a crown jewel: academic analysis of the 3GPP design notes that a compromised NRF could issue malicious tokens or tamper with registered service profiles, and that the NRF can be flooded with token requests. Protect its signing keys in an HSM, restrict who can register NF profiles and monitor token issuance volumes.
• One identity per function: NSA and CISA, in Part I of their 5G cloud guidance, ask for a distinct identity for every network element, ideally per interface, X.509 certificates from a trusted CA instead of passwords, MFA where passwords cannot be avoided, and automated certificate rotation, for example through a service mesh.
• Scope tokens tightly: research cited above notes that a token issued for a service type could be usable across slices with different policies. Require slice and audience restrictions in producer validation.
• Include the management plane: MANO, CI pipelines, Kubernetes service accounts and device logins hold the core's most powerful credentials.

See the Machine-to-Machine OAuth (Client Credentials) Guide, the mTLS Guide and the Telecoms Identity Security Guide.

Cloud-native core security: the NSA and CISA series

NSA and CISA, through the Enduring Security Framework, published Security Guidance for 5G Cloud Infrastructures in four parts: Part I, Prevent and Detect Lateral Movement; Part II, Securely Isolate Network Resources; Part III, Protect Data in Transit, In-Use, and at Rest; Part IV, Ensure Integrity of Infrastructure. Part I is the most operational:

1. Authenticate every session: control, user, management and cloud infrastructure sessions, with mutually authenticated TLS 1.2 or later and X.509 certificates as the example.
2. Segment at the pod: security groups per Kubernetes pod, private networking between microservices, default-deny Network Policies at pod and worker node level, and mTLS between pods through a service mesh.
3. Log every access attempt: time, resource, requester, requester location and the allow or deny decision, with protected logs and regular access-anomaly analytics.
4. Patch on a clock: the guidance gives roughly 15 days for critical vulnerabilities and 60 days for others, referencing NIST SP 800-40.
5. Hunt for lateral movement: scanning or unusual ports between OA&M interfaces, logins at odd times, unusual internal communication and unexpected container system calls.

See the Kubernetes Security Guide and the Kubernetes Service Account Token Guide.

Network slicing security

A network slice is a logical network with its own characteristics, identified by an S-NSSAI, running on shared infrastructure. GSMA PRD NG.116 defines the Generic Slice Template with 35 slice attributes. A device receives an authorised S-NSSAI only after primary authentication; network slice-specific authentication and authorisation (NSSAA) can then run over EAP, with the NSSAAF relaying to the slice tenant's AAA server. NSA and CISA's network slicing paper sets out the threats and the countermeasures.

Enterprise buyers of a slice should ask which of these the operator implements, whether NSSAA with separate credentials is offered, what the slice SLA says about isolation and logging, and whether slice logs can be exported to the customer's SIEM. NSA and CISA note that zero trust inside a slice does not extend to the wider operator network or external networks. See the Network Segmentation Guide.

Roaming, interconnect and steering of roaming

• SEPP on N32: the SEPP is a non-transparent proxy at the network border. It protects N32 messages with application-layer security, filters messages, validates JSON and hides internal topology. N32-c handles the control handshake and N32-f carries forwarded messages, protected with PRINS or TLS (TS 33.501 clause 13.2). FS.40 adds that transport between the SEPP and an IPX provider uses NDS/IP or a mutually authenticated TLS VPN.
• Legacy signalling stays in scope: FS.40 states that SS7, GTP and Diameter monitoring, filtering and threat intelligence continue to apply when 5G interworks with 4G and earlier. The relevant GSMA documents are FS.11 (SS7 interconnect monitoring and firewall guidelines), FS.19 (Diameter interconnect security), FS.20 (GTP security), FS.21 (interconnect signalling security recommendations) and FS.36 (5G interconnect security). FS.37 covers GTP-U security, which applies to N9; the IPUPS function discards malformed GTP-U and forwards only packets tied to active PDU sessions.
• Steering of roaming: GSMA IR.73 defines steering of roaming mechanisms that direct roamers to preferred visited networks, including networks that support authentication confirmation. 5G adds a control-plane method that updates the device's preferred network list over NAS, protected by 3GPP TS 31.115, according to FS.40.
• Enterprise relevance: roaming IoT fleets inherit their operator's interconnect posture, so ask which signalling firewall and SEPP filtering controls it runs. See the Telecom Network Security Guide.

Private 5G, 5G IoT and enterprise use

Decision guidance

• Choose an operator slice when the site is small, the use case is connectivity rather than control, and the team has no telecom engineers. Put isolation, logging and incident notification terms in the contract.
• Choose a private network for factories, ports and campuses that need deterministic coverage, on-site data or OT integration, and only if the organisation can operate a cloud-native core with the controls in the NSA and CISA series. Smaller organisations usually buy it as a managed service and should ask for the same evidence.
• Prefer standalone for any design that relies on SUCI, 5G AKA home control or slice-specific authentication.
• 5G as SD-WAN or backup transport is a link, not a trust boundary. Keep the overlay's encryption and device authentication, lock down the cellular router's management interface and treat its SIM and admin credentials as managed device secrets. See the SD-WAN Security Guide.
• 5G IoT devices still need everything in the IoT Security Guide: unique credentials, signed updates and inventory. Cellular authentication proves the SIM, not the firmware.

Phased rollout for a private 5G network

1. Design: define security domains, decide SNPN or PNI-NPN, choose authentication (SIM-based AKA or EAP-TLS), and agree who holds the NRF signing keys and the SUCI home network keys.
2. Supplier assurance: ask for GSMA NESAS evaluation evidence (FS.13 gives the overview) and 3GPP SCAS test results for the network products, plus SBOMs for the cloud-native functions.
3. Build the PKI first: per-NF certificates from a dedicated issuing CA, automated rotation, and a dedicated intermediate CA per slice where slices exist.
4. Pilot: one cell and a test SIM batch with a non-null SUCI profile; verify that captured attach messages show a concealed identifier, that unauthorised NFs are refused tokens and that logs reach the SIEM.
5. Expand in rings: add device groups by risk, starting with non-critical sensors, before OT control traffic.
6. Roll back: keep the previous Wi-Fi or wired path live until the 5G path has passed a failover test, and keep configuration baselines so a bad policy or slice change can be reverted from version control.

Detection and measurement

• What to log: NRF token requests and denials, NF registrations and profile changes, SEPP filtering decisions, AMF authentication failures and synchronisation failures, OA&M logins, Kubernetes audit logs for the core namespaces and orchestration pipeline changes.
• What to alert on: a new NF instance registering outside a change window, token requests for scopes an NF has never used, spikes in authentication failures in one cell (possible false base station or misconfigured SIMs), new local accounts or SSH keys on network devices, and changes to AAA server addresses.

Common failure patterns

• Buying "5G" that is non-standalone: the radio is 5G but the core is 4G, so none of the 5G Core identity protections apply. Ask which core the service uses.
• SUCI enabled with the null scheme: the network reports SUCI in use while the permanent identifier still crosses the air in clear.
• Static, shared network device credentials: the Salt Typhoon telecom intrusions relied mainly on valid credentials for network devices, then harvested SNMP community strings, TACACS and RADIUS secrets and weakly encrypted local passwords from configuration files, and stayed for years in one case. The same credentials exist around every 5G core.
• Treating slice isolation as physical separation: shared UDRs, shared CAs and no per-slice rate limits let one tenant's incident reach another.
• Unmanaged NF certificates and NRF keys: long-lived certificates, manual rotation and signing keys in files turn the service-based core into an NHI sprawl problem.

Framework mapping

In ISO/IEC 27001:2022 Annex A the topic sits mainly in A.8.20 Networks security, A.8.21 Security of network services and A.5.21 Managing information security in the ICT supply chain. In the EU, the 5G Toolbox asks Member States to strengthen security requirements, assess supplier risk profiles, restrict high-risk suppliers including exclusions for critical assets such as core network functions, and maintain vendor diversification. For UK operators, see the UK Telecommunications Security Act Guide.

Practitioner checklist

• Confirm the service or private network uses a standalone 5G Core before relying on 5G identity protections.
• Provision home network keys and a non-null ECIES profile (A or B) on every SIM, and verify concealment in a packet capture.
• Issue a unique X.509 certificate to every network function, automate rotation and keep the NRF signing key in an HSM.
• Enforce scope, audience and slice checks on every NF access token and alert on unusual token requests.
• Apply default-deny Kubernetes Network Policies and mTLS between pods in the core, and patch critical flaws within 15 days.
• For slices, require NSSAA with separate credentials, per-slice data stores and CAs, rate limits at N6 and exported logs.
• Run SEPP filtering on N32 and keep SS7, Diameter and GTP firewalls for interworking traffic.
• Remove shared and default credentials from network devices, move SNMP to v3 and put OA&M access behind MFA and central AAA.
• Ask suppliers for NESAS and SCAS evidence and SBOMs, and record supplier risk in the risk register.

Standards and references

• 3GPP / ETSI: TS 33.501 Security architecture and procedures for 5G System
• NIST: CSWP 36A Protecting Subscriber Identifiers with the Subscription Concealed Identifier (SUCI)
• GSMA: FS.40 5G Security Guide
• NSA and CISA: Security Guidance for 5G Cloud Infrastructures, Part I
• NSA and CISA: 5G Network Slicing, Security Considerations for Design, Deployment, and Maintenance
• ENISA: Threat Landscape for 5G Networks
• European Commission: EU Toolbox for 5G Security
• NIST NCCoE: 5G Cybersecurity (SP 1800-33)

Related NHI Mgmt Group resources: Telecoms Identity Security Guide · Machine-to-Machine OAuth (Client Credentials) Guide · Device and IoT Identity Guide · Wi-Fi Security Guide · Salt Typhoon Threat Actor Profile