NRF

Overview

The NRF — Network Repository Function — is the service registry at the heart of the 5G Service Based Architecture. Every network function that wants to offer services to other NFs must register its profile with the NRF: its NF type, instance ID, supported services, PLMN ID, slice information, and IP endpoints. Every NF that needs to call another NF must first query the NRF to discover which instances are available and where they can be reached.

This centralised registration and discovery model is what makes the SBA dynamic. In 4G EPC, a node like the MME had static Diameter peer relationships with fixed HSS and PCRF addresses — relationships that required manual configuration and operator action to change. In 5G, if a new SMF instance is spun up to handle a load spike, it registers itself in the NRF and is immediately discoverable by AMF instances routing new sessions to it. Scale-in and scale-out are orchestration events, not configuration changes.

Beyond registration and discovery, the NRF serves a second critical function in 5G Release 15 and later: OAuth2 authorization server. When NF-A wants to call NF-B's API, it requests an access token from the NRF, specifying the target NF type and service. The NRF verifies the requester's identity (via mTLS) and issues a signed JWT bearing the authorised scope. NF-B validates this token before serving the request. This token-based model provides the access control layer that prevents any NF from calling any other NF's API without explicit authorisation.

The NRF's centrality makes it simultaneously the most valuable and most dangerous function in the SBA. It is valuable because it provides dynamic, scalable NF mesh management. It is dangerous because corrupting the NRF's registry — through a rogue NF registration or a manipulated discovery response — potentially affects every NF-to-NF interaction in the entire core network.

---

How it works

NF registration

When an NF instance starts, its first action is to register with the NRF.

1. The NF sends an HTTP PUT request to the NRF Nnrf_NFManagement_NFRegister endpoint, providing its NF profile: NF type, NF instance ID (a UUID), FQDN or IP address, supported services with their endpoints, PLMN ID, S-NSSAIs (slices), and any additional type-specific attributes (e.g., for an SMF: supported DNNs, TAI list).
2. The NRF validates the profile against the operator's provisioning policy — checking that the NF type is permitted, the IP address falls within allowed ranges, and the certificate presented in the mTLS handshake corresponds to the NF instance ID claimed.
3. If validation passes, the NRF stores the profile and returns a 201 Created response. The NF profile is now discoverable by other NFs.
4. The NF periodically sends heartbeat requests (Nnrf_NFManagement_NFHeartbeat) to indicate it is still alive. If heartbeats stop, the NRF marks the instance as deregistered after a configurable timeout.

NF discovery

When NF-A needs to call NF-B:

1. NF-A sends an HTTP GET request to Nnrf_NFDiscovery_Request, specifying the target NF type, PLMN ID, and any additional filters (S-NSSAI, DNN, TAI).
2. The NRF queries its registry and returns a list of matching NF instances with their endpoints, supported services, and capacity/priority attributes.
3. NF-A selects an NF instance (based on load balancing policy or locality) and caches the discovery result for a configurable validity period.
4. Subsequent calls to the same NF type use the cached result until it expires, at which point a fresh discovery query is issued.

The NRF also supports subscription-based notification: NF-A can subscribe to Nnrf_NFManagement_NFStatusNotify for a specific NF type, receiving push notifications when new instances register or existing instances deregister. This enables proactive re-routing without waiting for a cached discovery result to expire.

OAuth2 token issuance

5G Release 15 defines the NRF as the OAuth2 Authorization Server for the SBA.

1. NF-A requests an access token: HTTP POST to Nnrf_AccessToken_Get, providing the target NF type, target NF instance ID (if known), and the requested service name and operation.
2. The NRF authenticates NF-A via the mTLS certificate, checks that NF-A is authorised to call the requested service (based on operator policy), and issues a signed JWT. The JWT contains: issuer (NRF), subject (NF-A instance), audience (NF-B instance or type), expiry, and scope (the specific service and operation authorised).
3. NF-A includes the JWT as a Bearer token in the Authorization header of its API call to NF-B.
4. NF-B validates the JWT signature (using the NRF's public key), checks expiry, and verifies that the scope matches the operation being called. If any check fails, NF-B rejects the request with 401.

---

Architecture role

The NRF is the architectural backbone of the 5G SBA — without it, no NF can discover its peers at runtime and the entire dynamic service mesh collapses. It has no direct subscriber signalling role; it does not handle authentication, session management, or user plane traffic. Its role is entirely infrastructure: registry, discovery, and authorisation.

In 5G SA: The NRF is the first function every newly started NF contacts and the function every NF queries before calling a peer. It underpins the service mesh that connects AMF, SMF, AUSF, PCF, UDM, and NEF.

No 4G equivalent: The NRF has no direct predecessor in 4G EPC. The equivalent function in 4G was static configuration — operators manually provisioned Diameter peer relationships in each node's configuration files. The NRF replaces operator configuration with a runtime discovery protocol.

Because the NRF is a critical shared infrastructure, it is typically deployed in a highly available configuration: multiple NRF instances active simultaneously, geographic redundancy, and persistent storage for NF profiles that survives individual NRF instance failures. Many operators run separate NRF instances per network slice or per PLMN to limit blast radius from a single NRF outage.

---

Key interfaces

---

Security posture

The NRF is the trust anchor of the entire 5G SBA. In a correctly deployed network, nothing talks to anything else without the NRF having registered both parties and issued tokens authorising the interaction. This makes the NRF both the strongest single defence in the SBA and the highest-value target for an attacker who wants to subvert the entire core at once.

The threat model has two primary dimensions. First, integrity of the NF registry: if an attacker can register a rogue NF profile — claiming to be an AMF, SMF, or AUSF — they can receive legitimate NF traffic, impersonate legitimate functions, or redirect traffic to attacker-controlled endpoints. Second, integrity of OAuth2 tokens: if the NRF issues over-privileged tokens or tokens to unauthorised NFs, the token-based access control model fails and any NF with a valid certificate can call any API in the SBA.

Unlike most 5G NFs, the NRF has no subscriber-specific state — it holds infrastructure state. Its compromise does not expose a single subscriber's data; it exposes the architecture of the entire network and enables attacks against all subscribers simultaneously.

---

Attack surface

Rogue NF registration

The most impactful attack against the NRF is registering a fake NF profile. If an attacker obtains a valid operator certificate (e.g., by compromising a VM host or misusing a certificate issued for a decommissioned NF), they can register a rogue NF profile claiming to be an AMF, SMF, or AUSF. The NRF stores this profile, and subsequent discovery queries by legitimate NFs may return the rogue endpoint alongside — or instead of — legitimate instances.

Impact: Traffic from legitimate NFs is routed to the attacker. Depending on the impersonated NF type, this enables authentication bypass (rogue AUSF), session hijacking (rogue SMF), or subscriber data exfiltration (rogue UDM).
Difficulty: High. Requires a valid operator certificate. Certificate hygiene and rapid revocation are the primary controls.

NF profile poisoning via registration update

A registered NF can update its own profile via Nnrf_NFManagement_NFUpdate. If access control on profile updates is insufficiently granular — allowing a registered NF to modify fields beyond its own profile — an attacker who has registered any NF could potentially modify another NF's profile to change its advertised IP endpoints, redirect discovery results, or deregister a legitimate instance.

Impact: Discovery results corrupted for specific NF types; legitimate NF instances shadowed by attacker-controlled endpoints.
Difficulty: Medium. Depends on NRF implementation — whether profile update operations are scoped to the requesting NF's own instance.

OAuth2 token over-privilege

If the NRF issues access tokens with overly broad scopes — granting access to entire NF types rather than specific service operations — a legitimate NF with a valid token can call APIs it has no business invoking. For example, a token issued to an SMF that grants access to all UDM services (rather than only Nudm_SDM_Get for session management) allows the SMF to invoke subscriber data modification APIs that should be restricted.

Impact: Lateral movement within the SBA — a compromised NF with an over-privileged token gains access beyond its intended scope.
Difficulty: Low if operator has not configured fine-grained scopes. Exploiting an existing token requires only knowledge of the target API endpoints.

NRF availability disruption

Because all NF discovery and token issuance flows through the NRF, its unavailability prevents any NF from reaching peers it has not already cached. A targeted denial-of-service attack — whether volumetric (flooding the Nnrf API) or resource-exhaustion (submitting malformed registration requests that consume NRF processing resources) — can prevent new sessions from being established and cause cached discovery entries to expire without refresh.

Impact: New subscriber sessions cannot be established; NFs with expired discovery caches cannot route to peers. Existing sessions (with already-established NF connections) continue until they are released or modified.
Difficulty: Medium. Requires network access to the NRF's SBI interface.

---

Mitigations

The NRF requires defence-in-depth: strong admission control on registration, minimal token scope, high availability, and continuous monitoring of registration events.

• mTLS with operator PKI for all registrations: Require all NF registrations to present a valid X.509 certificate issued by the operator's NF PKI CA. The certificate CN or SAN must match the NF instance ID claimed in the profile. Implement CRL or OCSP checking on every registration — not just at TLS handshake time, since certificates may be revoked post-registration.

• NF profile validation against provisioned allowlist: Before accepting any NF registration, validate the profile against operator-provisioned configuration: expected NF types, permitted IP address ranges, authorised slice/DNN combinations. Reject profiles that do not match the operator's deployment plan, even if the certificate is valid.

• Minimum-scope OAuth2 tokens: Configure the NRF to issue tokens scoped to the specific service name and operation requested — not the entire NF type. An AMF requesting a token to call Nsmf_PDUSession_CreateSMContext should receive a token scoped to exactly that operation, not to all Nsmf services.

• NRF high availability: Deploy a minimum of two active NRF instances in separate failure domains. Use a synchronised profile store (distributed database) so any instance can serve any registration or discovery query. Implement a local discovery cache in each NF to survive brief NRF outages.

• Registration anomaly monitoring: Alert on: NF registrations from IP addresses not in the expected operator IP range, duplicate NF instance IDs registered from different IPs simultaneously, NF type changes (an NF re-registering with a different NF type is always suspicious), and high rates of token issuance for sensitive NF types (AUSF, UDM).

---

Spec references

• 3GPP TS 23.501 — 5G system architecture. Section 6.2.6 defines the NRF's role in the SBA; Section 6.3 defines the SBA principles that make the NRF necessary.

• 3GPP TS 29.510 — The normative Nnrf service specification. Defines NF registration, heartbeat, deregistration, discovery, and OAuth2 token issuance API endpoints and OpenAPI schemas. The primary implementation reference.

• 3GPP TS 33.501 — 5G security architecture. Section 13 covers the NRF-based OAuth2 access control model for the SBA, including token structure, scope semantics, and NF certificate requirements.

• RFC 6749 — The OAuth 2.0 Authorization Framework. The 3GPP NRF token model is a profile of OAuth 2.0 Client Credentials flow. Understanding RFC 6749 is prerequisite for implementing or auditing the NRF token issuance mechanism.

---

Related topics

The NRF enables every NF-to-NF interaction in the 5G SBA. Its consumers include AMF (for SMF and AUSF discovery), SMF (for UPF and PCF discovery), NEF (for all internal NF discovery), and SEPP (for roaming NF profile exchange). Every NF that participates in the SBA is both a producer (registering itself) and a consumer (querying for peers) of the NRF.

The NRF's OAuth2 function directly affects the AUSF, since the AMF must obtain an NRF token before invoking the AUSF on N12. A compromised NRF that issues tokens to rogue NFs undermines the AUSF's access controls.

The SEPP carries NRF-related signalling between PLMNs in the roaming case — when the visited network's AMF needs to discover the home network's AUSF or UDM, that discovery traverses the N32 inter-PLMN interface through the SEPP pair.

For the architecture context, see 5G SA.