UDM / UDR / ARPF — Subscriber Data in 5G NR
Unified Data Management over the UDR — subscription data, the authentication credential repository (ARPF), and SUPI handling.
Somewhere in the home network there is a small block of secret bytes — the long-term key K burned into the SIM and stored in a hardened vault — and everything a subscriber can do on the network ultimately traces back to it. This page is about the functions that own that vault and the profile that hangs off it: the UDM and the database behind it, the ARPF that guards the key, the SIDF that alone can undo privacy concealment, and the services other network functions call to read and use all of it.
Introduction
The Unified Data Management function, the UDM, is the home network's authority on who a subscriber is and what they are entitled to. Every time a device registers, sets up a session, receives an SMS, or is authenticated, some network function eventually has to consult the master subscriber record — and that record, and the logic that serves it, lives in the UDM domain. It is a control-plane network function of the 5G Service-Based Architecture, defined in TS 23.501, with its security-critical parts specified in TS 33.501.
You meet the UDM at the very start of the UE lifecycle. During initial registration the serving AMF fetches the subscriber's access-and-mobility profile from it and registers itself as the serving node; during PDU session establishment the SMF fetches the session-management subscription; during primary authentication the AUSF comes to it for an authentication vector. It sits entirely in the home network (HPLMN), which is exactly why it can hold secrets a visited network must never see.
What makes the UDM worth studying is not one box but a deliberate split into four cooperating roles — the UDM logic, the UDR storage, the ARPF credential vault, and the SIDF de-concealer. Getting that split straight is the whole game, because it explains how 5G made subscriber management cloud-native and privacy-preserving at the same time.
On this page
- Why the UDM is needed
- UDM over UDR: logic separated from storage
- ARPF: the vault for the long-term key K
- SIDF: only the home network can de-conceal SUCI
- The Nudm services: SDM, UECM and UEAU
- Four functions, four roles — and where SUPI lives
- The LTE analogy: UDM + UDR + ARPF ≈ HSS
- Interfaces: N8, N10, N13 and Nudr
- Summary
- Quick Q&A
Why the UDM is needed
In plain words: think of a large company. The HR department knows what every employee is allowed to do but keeps nothing on its own desk — it pulls records from a central filing system whenever asked. The most sensitive item, the master key to the building, lives in a bolted safe that HR can ask to use but can never remove. And sealed identity envelopes can be opened by exactly one clerk who holds the only decoder. The UDM is HR, the UDR is the filing system, the ARPF is the safe, and the SIDF is that one clerk.
The concrete purpose is this: a mobile core cannot function without a single source of truth about its subscribers — their permanent identity, their allowed slices and data networks, their default QoS, and the credentials that let the network trust them. In 5G that source of truth has to satisfy three demands at once. It must be cloud-scalable (many stateless instances behind a load balancer), it must be secure (the long-term key must never leak, even to roaming partners), and it must be privacy-preserving (the permanent identity must never appear on the air). No single monolithic database satisfies all three cleanly — which is why 5G split the job across the UDM, UDR, ARPF and SIDF.
UDM over UDR: logic separated from storage
The Unified Data Management function, the UDM, is the 5G home of everything the network knows about a subscriber: who they are, what they are allowed to do, which slices and data networks they may use, and the identity and security anchors that make authentication possible. But the UDM is deliberately built as two things, not one, and internalising that split is the key to the whole page.
The UDM is stateless application logic. It implements the rules — how to assemble a subscription profile, how to authorise an access request, how to compute an authentication vector — but it does not itself durably hold the data.
Statelessness is what lets you run many UDM instances behind a load balancer, upgrade or scale them freely, and lose one without losing data. Any instance can serve any request because none of them owns the record.
The durable data lives in the Unified Data Repository, the UDR — an actual database. The UDM reads and writes it over the Nudr service-based interface, fetching a subscriber's record on demand and never keeping it.
This is the layered pattern you see in any well-built cloud service: a compute tier that holds no state sitting over a storage tier that holds all of it. In 3GPP terms (TS 23.501) the UDR is the data layer shared not just by the UDM but also by the PCF (policy data) and the NEF (structured data for exposure). Each of those front-end functions carries the logic for its domain; the UDR is the common, persistent truth beneath them. Separating storage from logic is precisely what makes the UDM stateless and horizontally scalable — the property that most sharply distinguishes it from the monolithic subscriber database it replaced.
One sentence to remember: the UDM is the brain, the UDR is the memory. The UDM decides; the UDR stores. Every subscriber record the UDM serves is fetched from the UDR over Nudr and held only for the life of the request.
ARPF: the vault for the long-term key K
Underneath subscriber management sits the most sensitive component in the entire system: the Authentication credential Repository and Processing Function, the ARPF. Its job is narrow and absolute — it holds the long-term subscriber key K and the associated authentication algorithms, and it uses them to generate authentication vectors. The ARPF is defined in the security architecture, TS 33.501, and it is conceptually a part of the UDM, though it is kept logically distinct precisely because of what it guards.
The key K is symmetric: the exact same value exists in two places and nowhere else — inside the tamper-resistant USIM on the device, and inside the ARPF in the home network. It never travels across any interface, ever. Instead, when authentication is needed, the ARPF takes K together with a fresh random challenge RAND and a sequence number SQN, runs the AKA cryptographic functions, and produces an authentication vector (AV): the expected response XRES*, the network authentication token AUTN, and the anchor key KAUSF that seeds the rest of the 5G key hierarchy. Those derived values leave the home network; the master key does not.
K never moves. The whole point of a symmetric long-term key is that it is pre-shared between USIM and ARPF and never transmitted. Authentication works by both sides independently computing values from K and comparing results — so possession of K is proven without K ever appearing on the wire.
Because the ARPF is where the crown jewels live, deployments isolate it aggressively — often in secure hardware or a physically separated element — and expose only the ability to request a vector, never to read a key. The AUSF (Authentication Server Function) drives authentication in the serving path, but it must come to the UDM/ARPF to actually get the vector, because only the home network holds K.
SIDF: only the home network can de-conceal SUCI
5G closed a long-standing privacy hole in cellular. In earlier generations a device would sometimes send its permanent identity — the IMSI — over the air in the clear, letting an eavesdropper with an IMSI catcher track subscribers. 5G forbids this. The permanent identity is now the Subscription Permanent Identifier, the SUPI, and it is never sent unprotected over the radio.
Instead the USIM encrypts the subscriber-identifying part of the SUPI using the home network's public key, producing the Subscription Concealed Identifier, the SUCI. The SUCI is what travels over the air during initial registration. Only the holder of the matching private key can reverse the concealment — and that holder is the Subscription Identifier De-concealing Function, the SIDF, a function of the UDM defined in TS 33.501.
The SIDF takes a SUCI and the home network private key and returns the SUPI — it undoes the ECIES concealment the USIM applied.
Concentrating de-concealment in one home-network function means the private key lives in exactly one trusted place. A visited network can carry a SUCI but can never resolve it to a permanent identity on its own.
During authentication the AUSF passes the SUCI to the UDM; the SIDF de-conceals it to the SUPI before the ARPF selects the method and generates the vector for that subscriber.
Home-network privilege: only the home network can de-conceal a SUCI, because only it holds the private key paired with the public key provisioned in the USIM. This is a deliberate trust boundary — roaming partners relay concealed identities they cannot read.
The Nudm services: SDM, UECM and UEAU
Like every control-plane function in the service-based core, the UDM does its work by exposing services on the bus under its own interface name, Nudm. Consumers — chiefly the AMF, the SMF and the AUSF — call these services over HTTP/2. Three of them carry almost all the traffic, and each answers a distinctly different question.
| Nudm service | Purpose | Typical consumer |
|---|---|---|
Nudm_SDM | Subscription Data Management — delivers subscription profile data (access and mobility subscription, session-management subscription, allowed S-NSSAIs, DNN lists) to serving NFs, and notifies them when that data changes. | AMF, SMF |
Nudm_UECM | UE Context Management — registers which serving NF currently holds the UE. The AMF registers itself as the UE's serving AMF; the SMF registers per-PDU-session serving-NF associations. This is how the home network knows where a subscriber is being served. | AMF, SMF |
Nudm_UEAU | UE Authentication — provides authentication material. The AUSF requests an authentication vector; the UDM (via SIDF and ARPF) de-conceals the SUCI, selects the method, and returns the vector. It also confirms authentication results back for storage. | AUSF |
The division is clean once you map each service to a question. Nudm_SDM answers "what is this subscriber allowed to do?" — it is the profile-delivery service, and it supports subscribe/notify so that a serving AMF or SMF is told when a profile changes rather than having to poll. Nudm_UECM answers "where is this subscriber being served right now?" — it is the registration bookkeeping that lets the home network locate the current serving AMF, which matters for things like reachability, SMS, and cleaning up a stale registration when the UE moves. Nudm_UEAU answers "prove who this subscriber is" — the authentication service that fronts the ARPF and SIDF. Every one of these is a thin logic layer that ultimately reads or writes the UDR underneath.
Mnemonic: SDM = what you may do (profile), UECM = where you are served (context), UEAU = who you are (authentication). Three questions, three services.
Four functions, four roles — and where SUPI lives
It is easy to blur the four names together because in many products they ship inside one logical UDM deployment. But 3GPP defines them as distinct roles for a reason: each sits at a different point on the spectrum from "pure logic" to "pure secret storage." Keep the roles crisp and you can answer any question about which one does what.
| Function | Nature | Role |
|---|---|---|
UDM | Stateless logic (front end) | Owns subscriber-management logic; exposes Nudm services (SDM/UECM/UEAU) to the AMF, SMF and AUSF; holds no durable state itself. |
UDR | Persistent database (back end) | Stores subscription data, and also policy data for the PCF and structured data for the NEF. Reached only over Nudr. This is where the SUPI and subscription profile physically live. |
ARPF | Secured credential store + crypto | Holds the long-term key K and AKA algorithms; generates authentication vectors. Never emits K. Logically part of the UDM, isolated for security. |
SIDF | Home-only crypto function | Holds the home-network private key; de-conceals a SUCI back into a SUPI. A function of the UDM; only the home network can do this. |
Where does the SUPI actually live? The permanent identifier and the subscription record that hangs off it are stored in the UDR, as ordinary (if sensitive) subscription data. The UDM retrieves them on demand. The ARPF's key material, by contrast, is treated as a different class of secret and kept in its hardened store rather than casually alongside profile data. So there are really two tiers of storage inside the subscriber domain: the general subscription store in the UDR, and the ultra-sensitive credential store in the ARPF.
⚠ Common pitfalls / gotchas
- Do not say "the
UDMstores the subscriber profile." It does not — theUDRdoes. TheUDMis stateless and fetches the record per request overNudr. Confusing the two is the single most common error. - The
SIDFis not the same as theARPF. TheSIDFundoesSUCIconcealment with the home private key; theARPFgenerates vectors with the long-term symmetric keyK. Different keys, different jobs. KandKAUSF are not interchangeable:Kis the permanent secret that never leaves theARPF/USIM;KAUSF is a derived anchor that is handed to theAUSF.- The
UDRis shared infrastructure — treating it as "the UDM's private database" misses that thePCFandNEFread and write it too.
The LTE analogy: UDM + UDR + ARPF ≈ HSS
If you already know 4G, the fastest route into all of this is a single equation. In the LTE Evolved Packet Core, one node did the whole subscriber job: the HSS (Home Subscriber Server). It stored subscription data, held the authentication credentials, and ran the authentication centre (AuC) functions that generated vectors from the key Ki. 5G took that monolith and pulled it apart along the seams that matter for cloud deployment.
LTE ↔ NR: the LTE HSS (with its AuC) was one box doing storage + logic + credentials. 5G splits it: the UDM takes the subscriber-management logic, the UDR takes the storage, and the ARPF takes the AuC's credential-and-vector role. The SIDF is genuinely new — LTE sent the IMSI in the clear and had nothing to de-conceal.
The equation: UDM + UDR + ARPF ≈ the LTE HSS. The UDM takes the subscriber-management logic, the UDR takes the stored data, and the ARPF takes the AuC's credential-and-vector role — with the SIDF added as a genuinely new 5G privacy function that has no LTE equivalent.
The comparison is instructive precisely because of what changed. The HSS mixed logic and storage in one box, so scaling and upgrading it meant scaling and upgrading everything at once. The 5G split lets the stateless UDM scale independently of the UDR, lets the same UDR serve policy and exposure data as well, and — the truly new part — introduces the SIDF because LTE had no equivalent of SUCI concealment at all. LTE's permanent identity, the IMSI, could appear on the air; 5G's SUPI may not, and the SIDF is the function that makes that privacy guarantee enforceable while still letting the home network resolve identities when it must.
UDM exposes Nudm services to the AMF (N8), SMF (N10) and AUSF (N13); inside it sit the SIDF and ARPF; all durable state, including the SUPI, lives in the UDR reached over Nudr.Interfaces: N8, N10, N13 and Nudr
The UDM is defined by a small, memorable set of interfaces. Three reference points connect it upward to the network functions that consume its services, and one connects it downward to its own storage. In service-based terms the upward links are all realised as calls to Nudm services, but the reference-point names are what appear in architecture diagrams and interview questions.
| Interface | Between | What it carries |
|---|---|---|
N8 | UDM ↔ AMF | Access-and-mobility subscription data and UE-context registration: the AMF fetches the mobility profile via Nudm_SDM and registers itself as serving AMF via Nudm_UECM. |
N10 | UDM ↔ SMF | Session-management subscription data (allowed DNNs, S-NSSAIs, default QoS) via Nudm_SDM, and per-PDU-session serving-NF registration via Nudm_UECM. |
N13 | UDM ↔ AUSF | Authentication material via Nudm_UEAU: the AUSF requests an authentication vector, the UDM de-conceals the SUCI and returns the vector generated by the ARPF. |
Nudr | UDM ↔ UDR | The data-access interface to persistent storage — the UDM reads and writes the subscriber record here. The same UDR and interface also back the PCF and NEF. |
A neat way to keep N8, N10 and N13 straight is to map each to its consumer's core concern. N8 serves the AMF, whose job is mobility, so it carries the access-and-mobility profile and the "who is serving this UE" registration. N10 serves the SMF, whose job is sessions, so it carries the session-management profile and per-session registration. N13 serves the AUSF, whose job is authentication, so it carries vectors. And beneath all three, Nudr is the one link that is not about serving a consumer at all — it is the UDM talking to its own database.
Summary
The subscriber domain in 5G is one job split into four roles. The UDM is stateless logic that decides; the UDR is the shared database that stores — including the SUPI and the whole subscription profile — reached only over Nudr and shared with the PCF and NEF. The ARPF is the hardened vault for the long-term symmetric key K, which never leaves it; it emits only derived authentication vectors (XRES*, AUTN, KAUSF). The SIDF is the only function that can de-conceal a SUCI into a SUPI, using the home private key — the enforcement point for 5G identity privacy.
Practically, remember the three Nudm services and the question each answers — SDM (what you may do), UECM (where you are served), UEAU (who you are) — and the three reference points that carry them: N8 to the AMF, N10 to the SMF, N13 to the AUSF. Anchor the whole picture on one equation: UDM + UDR + ARPF ≈ the LTE HSS, plus a brand-new SIDF for privacy.
Quick Q&A
These are the questions that separate reciting four acronyms from understanding why the subscriber domain is split the way it is.
Q. Why is the UDM split from the UDR at all?
A. To separate stateless logic from persistent storage. The UDM holds no durable state, so you can run many instances, scale and upgrade them freely, and lose one without losing data — every record is fetched from the UDR over Nudr per request. The UDR is the shared data layer, also serving the PCF and NEF.
Q. What does the ARPF hold, and does the key K ever leave it?
A. The ARPF holds the long-term symmetric key K and the AKA algorithms, and it generates authentication vectors (XRES*, AUTN, KAUSF). K never leaves — it exists only in the USIM and the ARPF. Only values derived from K cross any interface.
Q. Who can turn a SUCI back into a SUPI, and why only them?
A. Only the SIDF in the home network, because de-concealment needs the home private key that matches the public key provisioned in the USIM. A visited network can carry a SUCI but cannot resolve it — this is the 5G fix for IMSI-catcher tracking.
Q. Name the three Nudm services and the question each answers.
A. Nudm_SDM (Subscription Data Management) — what may this subscriber do; Nudm_UECM (UE Context Management) — where is this subscriber being served; Nudm_UEAU (UE Authentication) — prove who this subscriber is. Consumed by the AMF/SMF, the AMF/SMF, and the AUSF respectively.
Q. What is the LTE equivalent of the UDM/UDR/ARPF?
A. The HSS: UDM + UDR + ARPF ≈ HSS (with its AuC). 5G split the monolith into stateless logic, a shared database and an isolated credential store — and added the SIDF, which has no LTE counterpart because LTE never concealed the IMSI.
Q. Which interfaces connect the UDM to the AMF, SMF and AUSF?
A. N8 to the AMF (mobility subscription + serving-AMF registration), N10 to the SMF (session subscription + per-session registration), and N13 to the AUSF (authentication vectors). All are realised as Nudm service calls; Nudr connects the UDM down to the UDR.
Where to go next
You now know who owns the subscriber's identity, key and profile, and how the UDM serves them without ever storing them. The natural next step is to follow the credentials into an actual authentication run, and to see how the serving core consumes this data: