The 5G Core Explained: SBA, AMF, SMF, UPF and SEPP Security

The 5G core is a set of software network functions that talk to each other over HTTP/2 APIs with JSON bodies, a design 3GPP calls the service-based architecture. The AMF handles registration and mobility, the SMF manages data sessions, the UPF forwards user traffic, and the SEPP guards signalling between operators. Security rests on mutual TLS, OAuth 2.0 tokens issued by the NRF, and application layer protection on roaming links.

This post goes sideways from our 5G security architecture explainer, which covers SUCI, 5G AKA and the radio side. Here we stay inside the operator's network. Specification details come from the current 3GPP documents: TS 23.501 V20.3.0, TS 33.501 V20.3.0, TS 29.500 V20.0.0, TS 29.510 V20.1.0 and TS 29.573 V20.1.0, all dated September 2026.

Key takeaways

• The core is split into network functions (NFs): AMF (access and mobility), SMF (sessions), UPF (forwarding), AUSF (authentication), UDM (credentials and subscriber data), NRF (registry and token issuer), PCF (policy), NEF (external exposure) and SEPP (roaming edge), each defined in TS 23.501 clause 6.2.
• Control plane NFs expose service based interfaces. TS 29.500 says these interfaces "use HTTP/2 protocol" with "JSON" as the serialisation format, and the APIs are published as OpenAPI files.
• NFs register with the NRF and discover each other through it, directly or through a Service Communication Proxy (SCP), in four communication models defined in TS 23.501 Annex E.
• TS 33.501 requires every NF to support mutually authenticated TLS, and requires TLS inside a PLMN "unless network security is provided by other means." Service access authorisation uses OAuth 2.0 client credentials grants, with JSON Web Tokens issued by the NRF and signed with JWS.
• The SEPP is a non-transparent proxy on the N32 link between operators. N32-c negotiates security over TLS; N32-f carries messages protected either by TLS or by PRINS, which encrypts with JWE and lets roaming intermediaries record approved changes as signed JWS patches.
• Network slices are identified by an S-NSSAI made of a Slice/Service Type and an optional Slice Differentiator. Seven SST values are standardised. Isolation is not automatic: it comes from how the operator deploys NFs, NRFs, UPFs and transport for each slice.
• A cloud native core is containers on Kubernetes, often with open source components. CISA and NSA's four part "Security Guidance for 5G Cloud Infrastructures" (2021) covers lateral movement, pod isolation, data protection and image integrity.
• Open5GS, free5GC and the OpenAirInterface core are the common lab cores. Their defaults favour convenience: plain HTTP on loopback, a documented default web console password, and privileged containers for the user plane.

Timeline: the 5G core specifications and the guidance around them

The dates below come from the 3GPP specification archive upload dates, the publishers' own pages and the documents themselves.

Most of the government guidance dates from 2020 and 2021, when operators first moved core functions onto cloud platforms, while the specifications change every quarter. Read the two together.

What are the main 5G core network functions, and what does each do?

The 5G system splits into the user equipment (UE), the radio access network (RAN, the gNB base stations) and the core. In 4G, a few big boxes did most of the work: the MME handled mobility and sessions, the HSS held subscriber data, and the serving and packet gateways handled user traffic and some control. In 5G, 3GPP broke those responsibilities into smaller network functions, each with a defined job and a defined API. TS 23.501 lists their functionality in clause 6.2, and it repeatedly notes that "some or all" of a function's capabilities may live in a single instance, which is why vendors and open source projects can package them differently.

The functions that carry a phone's session

AMF, Access and Mobility Management Function. The AMF is where the RAN control plane (N2) and the phone's Non Access Stratum signalling (N1) terminate. Its list in TS 23.501 starts with "Termination of RAN CP interface (N2)" and "Termination of NAS (N1), NAS ciphering and integrity protection", then covers registration, connection, reachability and mobility management, access authentication and authorisation, lawful intercept for AMF events, transport of session messages between the phone and the SMF, and SMS transport. It also hosts the Security Anchor Function (SEAF), which TS 33.501 uses during authentication.

SMF, Session Management Function. The SMF sets up, modifies and releases PDU sessions, which are the 5G equivalent of a data connection. It allocates the phone's IP address (or gets one from a UPF or an external network), runs DHCP functions, selects and controls the UPF, and configures traffic steering so packets reach the right destination. It controls the UPF over N4.

UPF, User Plane Function. The UPF is the packet forwarder. TS 23.501 describes it as the anchor point for mobility, the "external PDU Session point of interconnect to Data Network", and the place that does packet routing, packet inspection, the user plane part of policy enforcement (gating, redirection, steering), lawful intercept collection, usage reporting, QoS enforcement and downlink buffering. User traffic reaches it from the gNB over N3 (GTP-U tunnels), goes between UPFs over N9 and leaves to the internet or a private network over N6. It is a data plane, not an HTTP service, which matters later for container privileges.

The functions that hold identity and credentials

AUSF, Authentication Server Function. Short and important. TS 23.501 says the AUSF "supports authentication for 3GPP access and untrusted non-3GPP access as specified in TS 33.501", plus authentication for disaster roaming. In the home network it runs the server side of 5G AKA or EAP-AKA'. Our SUCI and 5G AKA explainer walks through that exchange.

UDM, Unified Data Management. The UDM generates 3GPP AKA authentication credentials, stores and manages the permanent subscriber identity (SUPI), and performs "de-concealment of privacy-protected subscription identifier (SUCI)". It also records which AMF and SMF serve a subscriber, and can be stateless, with data held in the UDR (Unified Data Repository).

The functions that run the system

NRF, Network Repository Function. The NRF is the registry. It maintains the profile of every available NF instance and its services, answers discovery requests, notifies subscribers when NFs register or deregister, tracks NF health, and, as we will see, issues the OAuth 2.0 access tokens that NFs present to each other. TS 23.501 notes that multiple NRFs can be deployed at PLMN level, shared slice level and slice specific level.

PCF, Policy Control Function. The PCF provides "a unified policy framework to govern network behaviour" and hands policy rules, including QoS and charging rules, to control plane functions.

NEF, Network Exposure Function. The NEF is the controlled doorway for outside applications. It exposes network capabilities and events to third party Application Functions, accepts information from them, translates external identifiers to internal ones, and "handles masking of network and user sensitive information to external AF's according to the network policy." In practice the NEF is the most internet facing API in the core, and it deserves API gateway level controls.

SEPP, Security Edge Protection Proxy. The SEPP sits at the boundary between operators. TS 23.501 calls it "a non-transparent proxy" that does message filtering and policing on inter-PLMN control plane interfaces and topology hiding. We give it its own section below.

Supporting functions you will meet in any real core

SCP, Service Communication Proxy. The SCP routes messages between NFs, can do discovery on a consumer's behalf, and can apply communication security such as checking that a consumer may call a producer's API.

NSSF, Network Slice Selection Function. Picks the slices a device may use and helps select the serving AMF set.

Others. The UDR stores subscription and policy data, the CHF handles charging, the NWDAF produces analytics (including signalling storm detection in newer releases), and the N3IWF terminates IPsec from devices on untrusted non-3GPP access such as public Wi-Fi.

Network function summary table

The interface numbers are defined as reference points in TS 23.501. N1 is UE to AMF, N2 is RAN to AMF, N3 is RAN to UPF, N4 is SMF to UPF, N6 is UPF to a data network, N8 is UDM to AMF, N9 is UPF to UPF, N11 is AMF to SMF and N32 is SEPP to SEPP.

How does the service-based interface work over HTTP/2 and JSON?

In 4G, core elements spoke protocol specific languages such as GTP-C and Diameter. In the 5G core, control plane NFs publish services. Each service is a REST style API: the AMF publishes Namf services, the SMF publishes Nsmf, the NRF publishes Nnrf, and so on. A consumer NF calls a producer NF's service; the same NF can be a consumer for one exchange and a producer for another.

TS 29.500, the stage 3 "technical realization" of the service based architecture, puts it plainly: the service based interfaces "use HTTP/2 protocol" with "JSON" as the application layer serialisation protocol, and "HTTP/2 as described in IETF RFC 9113 shall be used." RFC 9113, published in June 2022, is the current HTTP/2 specification. The data models live in OpenAPI files that ship with each specification; the TS 29.510 archive, for example, contains TS29510_Nnrf_NFManagement.yaml, TS29510_Nnrf_NFDiscovery.yaml, TS29510_Nnrf_AccessToken.yaml and TS29510_Nnrf_Bootstrapping.yaml.

This choice has consequences that security teams should understand:

• The core now looks like any microservice platform, built on general purpose HTTP/2, JSON, TLS and OpenAPI code with general purpose bug classes.
• API paths are predictable. TS 29.510 defines the NF instance collection at a path ending in /nnrf-nfm/v1/nf-instances and the token endpoint at the NRF API root followed by /oauth2/token. Predictable paths make interoperability possible, and they also make it easy to enumerate an exposed core.
• Anything that can open a connection and present acceptable credentials can reach every capability, which is why NF to NF authorisation is the centre of 5G core security.

How NFs discover each other through the NRF

When an NF instance starts, it registers its NF profile with the NRF: its type, instance ID, addresses or FQDN, the services it offers, and which consumers may use them. Consumers then ask the NRF to find producers. TS 23.501 Annex E describes four communication models:

Models A and B are "direct communication"; C and D are "indirect communication." In model D the consumer does no discovery at all; it adds discovery and selection parameters to its request and the SCP finds a suitable producer. The NRF also offers a bootstrapping service, so an NF can learn the NRF's own endpoints, including the token and discovery URLs.

The NRF is a high value target in every model: a fake NF profile attracts traffic, open discovery reveals topology, and stolen tokens open other NFs. Registration and discovery need the same authorisation, logging and monitoring as token issuance.

How is NF to NF access authorised?

TS 33.501 clause 13 answers this in two layers: who you are (authentication, mostly TLS) and what you may do (authorisation, mostly OAuth 2.0).

Layer 1: mutual TLS

Clause 13.1 says "All network functions shall support mutually authenticated TLS and HTTPS", that "The identities in the end entity certificates shall be used for authentication and policy checks", and that NFs "shall support both server-side and client-side certificates." Certificates follow the SBA certificate profile in TS 33.310, and the TLS profile follows TS 33.210 with the restriction that it must be compatible with HTTP/2. TLS clients must send the SNI extension.

The important sentence for operators is this one: "TLS shall be used for transport protection within a PLMN unless network security is provided by other means." A note adds that if interfaces are trusted, for example physically protected, "it is for the PLMN-operator to decide whether to use cryptographic protection." So the standard makes TLS mandatory to support and the default to use, but leaves room for an operator to rely on network layer protection instead. In a cloud native core where many tenants and workloads share hosts, "physically protected" is a hard claim to make. CISA and NSA's Part I guidance goes further and says 5G networks should ensure all communication sessions on an NF's control, user and management planes, and through the cloud infrastructure, are authenticated using provisioned identities.

Layer 2: OAuth 2.0 tokens from the NRF

Clause 13.4.1 defines the authorisation framework. In the specification's words, it "uses the OAuth 2.0 framework as specified in RFC 6749. Grants shall be of the type Client Credentials Grant." Access tokens "shall be JSON Web Tokens as described in RFC 7519 and are secured with digital signatures or Message Authentication Codes (MAC) based on JSON Web Signature (JWS)". The NRF is the authorisation server, the consumer NF is the OAuth client and the producer NF is the resource server. The framework "is mandatory to support for NRF and NF."

The MAC option needs a pairwise pre-shared key between the NRF and each producer, and the specification says "MAC is not recommended" because of the key management burden. The signature option only needs the NRF's public key at each producer.

TS 29.510 defines the claims inside the token. The mandatory ones are:

Optional claims carry the consumer's and producer's PLMN or SNPN IDs for roaming cases. A decoded token payload looks like this (values are illustrative):

{
  "iss": "6faf1bbc-6e4a-4454-a507-a14ef8e1bc5a",
  "sub": "c2b6d7f0-1a2b-4c3d-9e8f-0a1b2c3d4e5f",
  "aud": "AMF",
  "scope": "namf-comm",
  "exp": 1792800000
}

TS 33.501 says the basic extent of a token is "at service level", and producers can require "additional scope" for specific operations or data sets. Without that, a token for a service grants every operation the service offers.

How the pieces fit in a request

A typical direct request, model B, runs like this:

1. The consumer (say an SMF) opens a mutually authenticated TLS connection to the NRF.
2. It sends a discovery request for the producer type it needs.
3. It sends a client credentials token request to the NRF token endpoint, naming its own instance ID, its NF type, the target NF type and the scope.
4. The NRF checks that this consumer type is allowed to use that service, then returns a signed JWT.
5. The consumer opens a mutually authenticated TLS connection to the producer and sends the API request with the token in the Authorization header.
6. The producer checks the TLS identity, the token signature, aud, scope and exp, then serves the request.

Indirect communication through an SCP has its own procedures in TS 33.501, including a "client credentials assertion" so a consumer can prove its identity when its transport layer peer is a proxy. Once a proxy sits in the middle, the producer cannot rely on the TLS peer identity alone, so token checks become the main control.

What does the SEPP do on N32, and why did 5G replace SS7 and Diameter trust?

The problem the SEPP solves

Roaming means your home network's UDM and AUSF must talk to a visited network's AMF and SMF. In 2G and 3G that signalling ran over SS7; in 4G it moved to Diameter. Both were designed for a closed club of operators connected through interconnect providers (IPX), and both largely assumed that anyone on the interconnect was a legitimate operator. ENISA's 2018 study on signalling security concluded there was "a medium to high level of risk in this area" and called for attention from all stakeholders. The problem is structural: if signalling from any interconnect peer is accepted at face value, anyone who gains access to the interconnect can query or redirect a subscriber. Our SIM swap and smishing explainer covers the consumer side of telecom fraud; signalling abuse is the network side.

Operators responded with signalling firewalls bolted on afterwards. For 5G, 3GPP designed the boundary in: all inter-PLMN control plane signalling goes through a SEPP on each side.

What the specification requires of a SEPP

TS 33.501 clause 5.9.3.2 lists the requirements. The SEPP "shall act as a non-transparent proxy node", "shall protect application layer control plane messages between two NFs belonging to different PLMNs", "shall perform mutual authentication with the SEPP in the other network", negotiates cipher suites, handles key management for N32, "shall perform topology hiding", and as a reverse proxy provides "a single point of access and control to internal NFs." The receiving SEPP must be able to verify that the sending SEPP is authorised to use the PLMN ID in the message. Communication may pass through up to two roaming intermediaries, and changes they make must be identifiable by the receiving SEPP.

TS 23.501 adds one subtle but important note: the SEPP "does not duplicate the Service Authorization applied by the Service Producers." In other words, the SEPP protects the connection; the home UDM still has to decide whether the visited AMF is allowed to ask what it is asking. Token based authorisation still applies across PLMNs, with the visited NRF and home NRF cooperating to issue tokens.

N32-c and N32-f

TS 33.501 and TS 29.573 split N32 into two parts:

• N32-c, the control connection. TS 29.573 says the N32 handshake is used "to mutually authenticate each other and negotiate the security mechanism to use over N32-f", over an HTTP/2 connection established "end to end over TLS." The handshake API (n32c-handshake) covers security capability negotiation, parameter exchange, N32-f context termination and error reporting.
• N32-f, the forwarding connection that carries the actual NF to NF messages.

The negotiated security capability takes one of three values in TS 29.573: TLS, PRINS (PRotocol for N32 INterconnect Security) or NONE, which applies only to a specific N32-f TLS termination feature.

TLS versus PRINS on N32-f

In PRINS, the sending SEPP "applies symmetric key based application layer protection", producing a JWE object. TS 33.501 explains that the SEPPs "independently export keying material associated with the first N32-c connection between them and use it as the pre-shared key" for N32-f protection. Intermediaries that need to modify a message, for example to support routing or value added services, cannot touch the encrypted parts; they append "digitally signed JWS objects which contain the desired changes." The receiving SEPP validates the JWE, extracts the original message, validates each intermediary's signature, checks the changes against the agreed modification policy and only then applies them.

The data type encryption policy tells the sending SEPP which kinds of information elements to encrypt. TS 29.573 defines IE types such as UEID, which covers subscriber identities like SUPI and GPSI, and LOCATION. That is the direct answer to the SS7 era problem: an intermediary can still route and mediate, but it cannot quietly read subscriber identities or rewrite a message without leaving a signed, policy checked record.

Topology hiding and telescopic FQDNs

The SEPP also hides internal names. When a discovery response from the home network lists internal NF FQDNs, the SEPP rewrites them into "telescopic FQDNs": a single label that uniquely represents the original name, followed by the SEPP's own domain. TS 33.501 says a telescopic FQDN "is an FQDN with a single label as the first element and the SEPP's domain as the trailer component." The visited network can address the producer without learning the home network's internal naming. TLS then works through a wildcard certificate for the SEPP's domain or, by operator policy, the custom header 3gpp-Sbi-Target-apiRoot.

SS7, Diameter and SEPP compared

A 5G SEPP does not retire SS7 and Diameter. Phones still fall back to older generations, and SMS and voice roaming often use older paths, so those interconnects still need their own filtering.

How do network slicing and its isolation work?

Slice identity

A network slice is a logical network with its own characteristics running on shared infrastructure. TS 23.501 clause 5.15 identifies a slice with an S-NSSAI, which is made of "A Slice/Service type (SST), which refers to the expected Network Slice behaviour in terms of features and services" and an optional "Slice Differentiator (SD)" that distinguishes multiple slices of the same type. The standardised SST values in Table 5.15.2.2-1 are:

A note in the specification says a network does not have to support all of them, and a GSMA document, NG.116, maps GSMA's generic slice templates to these values. A device can have at most eight S-NSSAIs in its Allowed and Requested NSSAI, and the UDM sends at most 16 subscribed S-NSSAIs to the AMF.

How a device gets onto a slice

When a device registers, it sends a Requested NSSAI. The AMF, with help from the NSSF, checks this against the subscription and what is available in the tracking area, then returns an Allowed NSSAI. When the device opens a PDU session, it names an S-NSSAI, and the SMF and UPF chosen for that session are ones that serve that slice. Slices can also require Network Slice Specific Authentication and Authorization (NSSAA): TS 33.501 describes the NSSAAF, which relays an extra EAP based authentication to an AAA server owned by the slice tenant, and supports re-authentication and revocation triggered by that server.

What isolation actually means

This is where expectations and the specification often diverge. The S-NSSAI is an identifier and a selection key; by itself it does not isolate anything. Isolation comes from deployment decisions:

• Dedicated or shared NFs. A slice can have its own SMF and UPF, or share them with other slices. TS 23.501 allows NRFs at PLMN, shared slice and slice specific levels.
• User plane separation. Separate UPFs, or separate network instances inside a UPF, keep traffic apart. TS 23.501 describes using the Network Instance attribute in N4 rules to keep different groups' traffic separate in the packet detection and forwarding process.
• Transport separation. VLANs, VRFs or overlay networks between the RAN, UPFs and data networks.
• Compute separation. Separate Kubernetes clusters, node pools, namespaces or hardware for sensitive slices.
• Management separation. Separate credentials and orchestration scopes so the operator of one slice cannot reconfigure another.

TS 23.501 itself makes the point in the private network context: if isolation for a non-public network is desired, the operator "can better support NPN isolation by deploying network slicing" with dedicated S-NSSAIs. Isolation is something you build with slicing, not something slicing gives you for free.

Security assumptions to test

1. Shared control plane functions enforce slice boundaries. If one AMF and NSSF serve several slices, a flaw there affects all of them.
2. Discovery does not leak across slices. A slice specific NRF should not answer for another slice's NFs unless intended.
3. Tokens are checked per slice. TS 29.510 lets token requests carry the requester's S-NSSAIs; producers serving several slices should use them.
4. Shared hosts do not become a bridge. CISA and NSA Part II warns that privileged pods, root processes and hostPath mounts can turn one compromised workload into access to the node.
5. One slice cannot starve another. Part II ties container hygiene to avoiding resource contention and denial of service.

What does a cloud native core mean for supply chain risk?

The shift

A modern 5G core is rarely a set of appliances. Each NF is typically one or more containers, deployed with Helm charts or operators onto Kubernetes, on commodity servers, sometimes in a public or shared cloud. That brings real benefits in scaling and upgrade speed, and it moves the core's security model much closer to an enterprise microservice platform.

CISA and NSA's Part I says it directly: 5G cloud deployments "rely on the secure coordination of multiple services built from heterogeneous software sources", and "5G clouds may deploy open source or specialized services to support network slicing, including third party applications that implement virtual network functionality. Vulnerabilities in any of this software could be exploited by an attacker to gain initial access." It splits vulnerabilities into those with a patch available, those publicly known without a patch, and those not publicly known, and says "patching publicly known vulnerabilities as quickly as possible significantly reduces the risk of exploitation."

Where the components come from

Even a single vendor core usually contains a base OS layer in every image; HTTP/2, TLS, JSON and YAML libraries and OpenAPI generated code; a database such as MongoDB, which Open5GS and free5GC both use for subscriber data; GTP kernel modules or fast packet frameworks for the user plane; and the orchestration layer of Kubernetes, network plugins, Helm charts and operators. Each has its own release cycle and advisories. A vulnerability in a widely used HTTP/2 or JSON library is a 5G core vulnerability if your NFs link it.

NESAS and SCAS: assurance for the equipment, not your deployment

GSMA's NESAS framework document says the scheme "defines security requirements and an assessment framework for secure product development and product lifecycle processes, as well as security test cases for the security evaluation of network equipment." The product test cases come from 3GPP's Security Assurance Specifications. 3GPP's SCAS overview lists TS 33.117, the general catalogue, and a SCAS per network product class, including TS 33.512 (AMF), TS 33.513 (UPF), TS 33.514 (UDM), TS 33.515 (SMF), TS 33.516 (AUSF), TS 33.517 (SEPP), TS 33.518 (NRF), TS 33.519 (NEF) and TS 33.522 (SCP).

These are valuable, and they have a defined scope. NESAS assesses a vendor's processes and a product release. It does not tell you whether the image you deployed last Tuesday has a newly disclosed library vulnerability, whether your Helm chart runs the UPF as privileged, or whether a sidecar you added pulled in a vulnerable dependency. The GSMA document itself says NESAS is "intended to be used alongside other mechanisms to ensure a network is secure." Continuous inventory and patching of what you actually run is one of those mechanisms.

A practical inventory habit

Keep an SBOM (CycloneDX or SPDX) and the image digest for every NF you run, track which NFs share the same HTTP/2, TLS and JSON libraries, and rebuild on a schedule so the path to production stays exercised. Treat Helm charts, operators and CI pipelines as part of the core's supply chain, because they decide privileges and network exposure.

What open source 5G cores exist for labs, and how do you stand one up safely?

The common choices

All three are excellent for learning and research. None is a production carrier core out of the box, and all three need deliberate hardening before you put them anywhere near a shared network.

Before you start: two warnings

Radio spectrum. Labs usually add a software radio, and transmitting on licensed mobile bands without authorisation is illegal in most countries. Use simulated RAN and UE software, a shielded enclosure, or a band you are licensed for. The Open5GS quickstart points out that 001/01 is the international test PLMN and 999/99 the private network PLMN, and that you should stick to these "unless you have been issued a PLMN by your national regulator."

Network exposure. Keep the lab on an isolated VM or host network. A 5G core listening on a routable address with default credentials is an open API to anyone who finds it.

Step by step: an isolated Open5GS 5G SA lab on Ubuntu

These steps follow the Open5GS quickstart, with hardening added. Run them on a disposable Ubuntu VM.

Step 1: install MongoDB and Open5GS from the project's package sources.

sudo apt update
sudo apt install -y gnupg curl
curl -fsSL https://pgp.mongodb.com/server-8.0.asc | \
  sudo gpg -o /usr/share/keyrings/mongodb-server-8.0.gpg --dearmor
# Add the MongoDB repository for your Ubuntu release, as shown in the Open5GS quickstart
sudo apt update && sudo apt install -y mongodb-org
sudo systemctl enable --now mongod

sudo add-apt-repository ppa:open5gs/latest
sudo apt update && sudo apt install -y open5gs

Step 2: confirm which addresses the NFs listen on. By default the Open5GS configs bind each NF to its own loopback address on port 7777 for the SBI, for example AMF on 127.0.0.5, SMF on 127.0.0.4, NRF on 127.0.0.10 and SCP on 127.0.0.200, with the SEPP's N32 interfaces on 127.0.0.251 and 127.0.0.252. Check that nothing SBI related is listening on an external interface:

sudo ss -tlnp | grep -E ':7777|:9999|:27017'
# Expect 127.0.0.x addresses only. Anything on 0.0.0.0 or a LAN address needs fixing.

The default configs use plain HTTP for the SBI on loopback (the AMF config points at http://127.0.0.200:7777 for the SCP). That is acceptable for a single host lab where loopback is the trust boundary. It is not acceptable once NFs span hosts.

Step 3: set the PLMN and slice in the NRF and AMF configs. Edit /etc/open5gs/nrf.yaml and /etc/open5gs/amf.yaml to use the test PLMN 001/01, set the TAC, and define the slice your simulated device will request:

# /etc/open5gs/amf.yaml (excerpt)
amf:
  ngap:
    server:
      - address: 127.0.0.5      # keep on loopback unless a real gNB must connect
  guami:
    - plmn_id:
        mcc: 001
        mnc: 01
      amf_id:
        region: 2
        set: 1
  tai:
    - plmn_id:
        mcc: 001
        mnc: 01
      tac: 1
  plmn_support:
    - plmn_id:
        mcc: 001
        mnc: 01
      s_nssai:
        - sst: 1                # eMBB, the standardised SST value 1

Restart the daemons you changed:

sudo systemctl restart open5gs-nrfd open5gs-amfd open5gs-upfd

Step 4: change the WebUI password immediately. The Open5GS docs say to log in to the WebUI on port 9999 with the username admin and password 1423, and that you can change the password in the Account menu. Do that before anything else, and keep the WebUI bound to loopback. Reach it through an SSH tunnel if you need it from another machine:

ssh -L 9999:localhost:9999 lab-vm

Step 5: route UE traffic without exposing the host. The quickstart enables forwarding and NAT for the UE subnet, and also lists optional rules that stop UEs from reaching the host that runs the UPF. Use those optional rules:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A POSTROUTING -s 10.45.0.0/16 ! -o ogstun -j MASQUERADE
# Accept traffic arriving on the tunnel interface, then stop UEs talking to the UPF host itself
sudo iptables -I INPUT -i ogstun -j ACCEPT
sudo iptables -I INPUT -s 10.45.0.0/16 -j DROP

The quickstart also suggests disabling ufw if it blocks traffic; prefer explicit allow rules instead.

Step 6: add a test subscriber with test credentials only. Use the WebUI or the command line tool to add a simulated subscriber. Never load real SIM keys (K and OPc) from production cards into a lab database.

Step by step: free5GC with docker compose and OAuth2 on the SBI

The free5GC docs recommend its compose project for normal testing. Its prerequisites are the gtp5g kernel module for the UPF, Docker Engine and Docker Compose v2. The docs are explicit about one trade off: "Because we need to create tunnel interface, we need to use privileged container with root permission." Treat that host as fully trusted by those containers.

git clone https://github.com/free5gc/free5gc-compose.git
cd free5gc-compose
docker compose pull
docker compose up -d
docker compose ps

To turn on OAuth2 for the service based interface, the free5GC guide sets oauth: true under the NRF's SBI configuration in nrfcfg.yaml and gives every NF the NRF certificate path:

# nrfcfg.yaml (excerpt)
configuration:
  sbi:
    oauth: true

# each NF config (excerpt)
configuration:
  nrfCertPem: cert/nrf.pem

The guide warns that the bundled certificates are generated by code and not signed by a known authority, so you will see certificate verification warnings. For anything beyond a single machine lab, generate your own CA, issue per NF certificates and turn on TLS on the SBI as well, so that tokens are not sent in clear text.

Moving a lab core onto Kubernetes

If you deploy an open source core with Helm, apply the CISA and NSA Part II controls to every NF except where the data plane genuinely needs more. The Kubernetes Pod Security Standards define three cumulative policies, Privileged, Baseline and Restricted. Put control plane NFs in a namespace that enforces Restricted:

apiVersion: v1
kind: Namespace
metadata:
  name: core-cp
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted
---
# Control plane NF pod spec excerpt (AMF, SMF, NRF, AUSF, UDM, PCF)
securityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault
containers:
  - name: amf
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]

Run the UPF in its own namespace and node pool, grant only the capabilities it needs (often NET_ADMIN and access to a tunnel device) instead of full privileged mode where the project allows it, and do not mount host paths other than what the data plane requires. Then restrict east to west traffic so that only expected NFs can reach the NRF and SCP:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: nrf-allow-core-only
  namespace: core-cp
spec:
  podSelector:
    matchLabels:
      app: nrf
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: core-nf
      ports:
        - protocol: TCP
          port: 7777

What did CISA, NSA and ENISA publish about 5G core and cloud security?

The ESF documents say the series grew from a 5G study group that met "over the course of eight weeks during the summer of 2020." CISA now files the cloud guidance page under archived content, but the documents remain available and their container and identity advice still applies. CISA describes the threat vectors paper as "the beginning of the ESF's research and not the culmination of it."

Common mistakes

1. Treating the core as a trusted internal zone. TS 33.501 makes TLS the default inside the PLMN. Shared clusters and many integrators make "internal" a weak boundary.
2. Turning on OAuth2 without checking tokens properly. Producers must check signature, aud, scope and exp, or one token opens every service.
3. Signing tokens with shared MAC keys. TS 33.501 calls this not recommended. Use NRF signatures and distribute the public key.
4. Leaving NRF registration open. A rogue NF profile poisons discovery. Authenticate registrations and alert on unexpected NF types.
5. Assuming a slice is isolated because it has its own S-NSSAI. Isolation comes from separate UPFs, transport, compute and management.
6. Running every NF as privileged because the UPF needs it. Separate the data plane and keep control plane NFs in a Restricted namespace.
7. Treating NESAS as a substitute for patching. It assesses vendor processes and a product release, not the images you run next month.
8. Assuming the SEPP fixes all roaming risk. SS7 and Diameter interconnects stay in service for older generations, SMS and voice, and still need their own filtering.

FAQ

What is the 5G core network?

The part of a mobile network behind the base stations that authenticates subscribers, manages mobility and sessions, applies policy and forwards user traffic. In 5G it is a set of software network functions that talk over HTTP/2 APIs.

What is the difference between the AMF and the SMF?

The AMF handles the device: registration, connection state, mobility and NAS signalling. The SMF handles each data session: creating PDU sessions, assigning IP addresses and programming the UPF.

What does the UPF do in 5G?

It forwards user data. It takes GTP-U tunnels from base stations on N3, applies the rules the SMF installed over N4, enforces QoS, counts usage and sends traffic out on N6 or to another UPF on N9.

What is service-based architecture in 5G?

3GPP's design in which control plane functions expose and consume services as APIs. TS 29.500 specifies HTTP/2 and JSON, with the APIs published as OpenAPI files.

What is the NRF in 5G?

The registry and token issuer. NFs register with it, discover producers through it and get OAuth 2.0 access tokens from its token endpoint.

How do 5G core network functions authenticate each other?

With mutually authenticated TLS using certificates that follow the 3GPP SBA profile, plus OAuth 2.0 client credentials tokens issued by the NRF as signed JSON Web Tokens.

What is a SEPP and why is it needed?

The proxy at each operator's edge on the N32 roaming link. It authenticates the peer SEPP, negotiates TLS or PRINS, filters messages, hides topology and checks the sender's PLMN ID, because SS7 and Diameter interconnects relied largely on trust.

What is PRINS in 5G?

The PRotocol for N32 INterconnect Security in TS 33.501. The sending SEPP encrypts sensitive parts of each message with JWE, intermediaries record allowed changes as JWS signed patches, and the receiving SEPP checks both before forwarding.

Does 5G network slicing provide security isolation?

Not by itself. The S-NSSAI identifies a slice and drives function selection; isolation comes from how the operator separates functions, user plane, transport and compute.

Which open source 5G core should I use for a lab?

Open5GS, free5GC and the OpenAirInterface core are all actively developed. Choose by language, licence and the RAN software you plan to pair it with, then harden it the same way.

Where Safeguard fits

Safeguard does not test 3GPP protocol conformance, run SCAS or NESAS evaluations, act as a SEPP or signalling firewall, or inspect radio or user plane traffic. It works on the software underneath a cloud native core: the open source dependencies and container images NFs are built from. You can scan a repository, an image or an SBOM file (safeguard scan --dir ., --image, --sbom), match components against vulnerability databases, use reachability analysis to see which vulnerable paths are actually called, and see which projects contain a given component and version. Policies and gates can stop a build that brings a known vulnerable library into an NF image, and autonomous remediation, off by default, can open fix pull requests. It does not replace your vendor's patches for code you do not build.

A cloud native 5G core, whether built from Open5GS or free5GC source or delivered as vendor container images, is assembled from open source libraries, base images and runtimes that get advisories like any other software. The fit here is indirect: none of the steps below touch 3GPP protocols, SEPP policy or radio, but they do apply to the dependencies and images that every NF is built from.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, image and remediation workflows, not 5G signalling, slicing or radio. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at a lab core's container images, such as the free5GC compose images, the same scan lists the packages and versions inside each NF image and their known vulnerabilities, so you know which images to rebuild when an advisory lands for a shared library.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same approve each step flow applies when you bump a vulnerable dependency in an NF you build from source, or in the tooling that renders your Helm charts.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version, such as a specific HTTP/2 or JSON library used across several NF images, and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• 3GPP TS 23.501 V20.3.0 (2026-09), System architecture for the 5G System, Stage 2 (archive)
• 3GPP TS 33.501 V20.3.0 (2026-09), Security architecture and procedures for 5G system (archive)
• 3GPP TS 29.500 V20.0.0 (2026-09), Technical Realization of Service Based Architecture (archive)
• 3GPP TS 29.510 V20.1.0 (2026-09), Network Function Repository Services (archive)
• 3GPP TS 29.573 V20.1.0 (2026-09), PLMN Interconnection, Stage 3 (archive)
• 3GPP TS 33.117 V20.2.0 (2026-09), Catalogue of general security assurance requirements (archive)
• 3GPP: Security Assurance (SCAS) specifications
• GSMA FS.13 v3.0, Network Equipment Security Assurance Scheme, Framework (20 February 2025)
• CISA: Security Guidance for 5G Cloud Infrastructures
• CISA and NSA: Security Guidance for 5G Cloud Infrastructures, Part I, Prevent and Detect Lateral Movement (PDF)
• CISA and NSA: Security Guidance for 5G Cloud Infrastructures, Part II, Securely Isolate Network Resources (PDF)
• CISA and NSA: Security Guidance for 5G Cloud Infrastructures, Part IV, Ensure Integrity of Cloud Infrastructure (PDF)
• CISA: 5G Security and Resilience
• CISA: 5G Potential Threat Vectors
• ENISA: threat report for 5G networks (14 December 2020)
• ENISA: Signalling Security in Telecom SS7/Diameter/5G (28 March 2018)
• European Commission: Cybersecurity of 5G networks, EU Toolbox of risk mitigating measures
• NIST CSRC: SP 1800-33 (Initial Public Draft), 5G Cybersecurity
• RFC 9113: HTTP/2 (June 2022)
• RFC 6749: The OAuth 2.0 Authorization Framework (October 2012)
• RFC 7516: JSON Web Encryption (May 2015)
• RFC 7519: JSON Web Token (May 2015)
• Open5GS: Quickstart
• Open5GS repository and releases
• free5GC: User Guide
• free5GC: free5GC compose
• free5GC: Enable OAuth2 on SBI
• free5GC repository and releases
• OpenAirInterface: oai-cn5g-fed repository
• Kubernetes: Pod Security Standards

Last reviewed: 23 October 2026. 3GPP publishes new versions of these specifications every quarter, and open source cores change defaults between releases; check the documents above for the versions you actually deploy.