AUSF — Authentication Server Function in 5G NR
Runs primary authentication for the home network — 5G-AKA / EAP-AKA′ and the KAUSF / KSEAF key output to the serving network.
When a UE powers on and tries to join a 5G network, someone has to prove the device is genuine and, just as importantly, prove to the device that the network is genuine. That job belongs to the home network, and inside the home network it belongs to one function: the AUSF. This page follows a primary authentication run end to end — who asks, who computes, who compares, and which keys fall out at the bottom.
Introduction
The Authentication Server Function, the AUSF, is the 5G core's authentication server. It is a control-plane network function of the Service-Based Architecture, specified in the 5G security architecture TS 33.501, and it exists only in the home network (the HPLMN). Its one responsibility is to run primary authentication — the mutual authentication between subscriber and network that must succeed before anything else can.
You meet the AUSF at the earliest security-relevant moment of the UE lifecycle: right after a device sends its Registration Request and before any NAS security, registration acceptance, or PDU session can proceed. The serving network's SEAF (inside the AMF) asks the AUSF to authenticate the subscriber; the AUSF fetches the credential material from the UDM/ARPF, drives the challenge, makes the authoritative verdict, and hands the serving network an anchor key. If it says no, the UE gets nowhere.
It matters because 5G deliberately moved the authentication decision back home. In earlier generations a visited network could effectively vouch for a subscriber on its own; in 5G it cannot. That single architectural choice — decision in the HPLMN, only derived keys handed out — is what the whole page unpacks, along with the two methods the AUSF runs and the key material it produces.
On this page
- Why the AUSF is needed
- What the AUSF is and where it sits
- The two interfaces: N12 down, N13 up
- Two methods: 5G-AKA and EAP-AKA′
- The RES*/HRES* split: who checks what
- A 5G-AKA run, message by message
- What the AUSF produces: KAUSF, KSEAF and beyond
- Beyond authentication: SoR and UPU protection
- Summary
- Quick Q&A
Why the AUSF is needed
In plain words: imagine a bank customer walking into a branch in a foreign country. The local branch (the visited network) can glance at the customer's card and do a quick sanity check, but it is not allowed to declare the account valid on its own — it phones the customer's home bank's verification desk (the AUSF), which alone holds the records that prove identity and issues the official "yes." The local branch never gets the master credentials; it only gets a one-time approval token to work with. The AUSF is that home-bank verification desk.
The concrete purpose is to make authentication mutual and home-anchored. Mutual, because both parties must be convinced: the network confirms the UE holds the right key, and the UE confirms — via the AUTN token — that it is talking to its real home network and not an impostor base station. Home-anchored, because the decision and the sensitive credentials stay in the HPLMN, so a compromised or malicious visited network can neither forge a "success" nor extract the long-term secret. The AUSF is the function that enforces both properties: it runs the method, makes the binding verdict, and releases only derived key material to the serving side.
What the AUSF is and where it sits
The Authentication Server Function (AUSF) is the 5G core's authentication server, and it lives only in the home network (the HPLMN). Its single responsibility is to run primary authentication — the mutual authentication between a subscriber and the network that gates every later step of registration. If primary authentication fails, nothing else happens: no NAS security, no registration, no PDU session. The AUSF is therefore one of the most security-critical NFs in the system, and 3GPP specifies it in TS 33.501, the 5G security architecture.
A home-network NF that executes the authentication method — 5G-AKA or EAP-AKA' — decides whether authentication succeeds, and derives the anchor key material handed to the serving network.
5G deliberately moves the authentication decision home. In a roaming case the visited network can no longer authenticate a subscriber on its own; the home network must be involved and must confirm the outcome. This closes attacks where a visited or fake network claimed a UE was authenticated when it was not.
The AUSF talks "down" to the serving network's SEAF (co-located in the AMF) over the Nausf_UEAuthentication service on N12, and "up" to the UDM/ARPF over the Nudm_UEAuthentication service on N13.
It helps to fix the three security roles before we trace any messages. The SEAF (Security Anchor Function) lives in the serving network, co-located with the AMF; it is the network's local anchor for the UE's security and the endpoint the UE's air-interface security is ultimately tied to. The AUSF lives in the home network and makes the authentication decision. The ARPF (Authentication credential Repository and Processing Function) sits behind the UDM and is where the long-term key K never leaves — it is the vault that computes authentication vectors from that key. The AUSF is the middle party: trusted by the home network to run the method, and trusted by the serving network to return a verdict.
Home-network-only: the AUSF exists exclusively in the HPLMN. A visited network cannot authenticate a subscriber by itself in 5G — it relays the request home, and the home AUSF confirms the result. This is a defining change from earlier generations.
The two interfaces: N12 down, N13 up
Everything the AUSF does happens between two service-based interfaces, and keeping them straight makes the whole flow legible. Below is the message-to-interface map you will see referenced throughout the rest of this page.
| Message / service operation | Between | Interface | Direction |
|---|---|---|---|
Nausf_UEAuthentication_Authenticate Request | SEAF/AMF → AUSF | N12 | into home net |
Nudm_UEAuthentication_Get Request | AUSF → UDM/ARPF | N13 | inside home net |
Nudm_UEAuthentication_Get Response | UDM/ARPF → AUSF | N13 | inside home net |
Nausf_UEAuthentication_Authenticate Response (5G-AKA challenge) | AUSF → SEAF/AMF | N12 | out to serving net |
Nausf_UEAuthentication_Authenticate Request (RES* return) | SEAF/AMF → AUSF | N12 | into home net |
Nausf_UEAuthentication_Authenticate Response (result + KSEAF) | AUSF → SEAF/AMF | N12 | out to serving net |
Two things are worth noticing in that table. First, the AUSF never talks to the UE directly — the UE's authentication challenge and response are carried inside NAS between the UE and the SEAF/AMF, and only the network-side parts cross N12. Second, the N13 conversation with the UDM/ARPF stays entirely inside the home network, which is exactly why the long-term key material never has to leave home.
SUPI vs SUCI: the serving network sends the concealed identity SUCI (or a 5G-GUTI) toward the home network. It is the home network — the UDM/SIDF — that de-conceals the SUCI back to the permanent SUPI. The serving network never needs to see the permanent identifier to get a subscriber authenticated.
Two methods: 5G-AKA and EAP-AKA′
The AUSF supports two primary authentication methods, and the UDM/ARPF chooses which one to run for a given subscriber. Both rest on the same shared symmetric key K on the SIM and in the ARPF, and both achieve mutual authentication; they differ in where the final verification of the UE happens and in how the exchange is framed.
| Aspect | 5G-AKA | EAP-AKA′ |
|---|---|---|
| Framing | Native 5G challenge/response inside NAS | Full EAP exchange (RFC 5448 / RFC 9048) tunnelled in NAS |
| Who verifies the UE's answer | Split: SEAF checks HRES* vs HXRES*; AUSF checks RES* vs XRES* | The AUSF acts as EAP server and verifies RES itself |
| Vector from UDM/ARPF | 5G HE AV: RAND, AUTN, XRES*, KAUSF | Transformed AV: RAND, AUTN, XRES, CK', IK' |
Round trips over N12 | Two (challenge, then RES* return) | Several EAP request/response pairs relayed by SEAF |
| Anchor key output | KAUSF → KSEAF | KAUSF (from EMSK) → KSEAF |
| Typical use | Default for USIM-based 3GPP subscribers | Mandatory to support; common where an EAP framework is preferred |
The key practical contrast is verification location. In EAP-AKA' the AUSF is a full EAP authentication server: the SEAF is a pass-through authenticator, and the UE's RES is checked at the AUSF. In 5G-AKA, verification is deliberately split across the two networks — a design we unpack next, because it is the most-tested detail about the AUSF.
The RES*/HRES* split: who checks what
In a 5G-AKA run, the UE's answer to the challenge is a value called RES*. There are two comparisons made against it, in two different places, and confusing them is the classic mistake.
The rule in one line: the SEAF checks HRES* against HXRES* (a fast, local sanity check in the serving network); the AUSF checks RES* against XRES* (the authoritative check in the home network). Both must pass.
Here is the mechanism. The UDM/ARPF computes the expected response XRES* and sends it to the AUSF inside the authentication vector. The AUSF does not forward XRES* to the serving network. Instead it hashes it into HXRES* and sends only that, together with RAND and AUTN, down to the SEAF. When the UE answers with RES*, the SEAF hashes it the same way into HRES* and compares to the HXRES* it holds. If they match, the SEAF is satisfied enough to proceed locally — but that is only a first gate. The SEAF then forwards the raw RES* back to the AUSF, which compares it to the real XRES*. Only the AUSF's check is authoritative, and only the AUSF confirms authentication success to the serving network.
Why two checks? The HXRES*/HRES* comparison lets the serving network fail fast and locally on an obviously wrong answer without a round trip home, while withholding the real XRES* from the serving network so it cannot fabricate a "success" without the home network's blessing. That is the whole point of moving authentication home: the visited network gets a quick local filter but never the authority to declare a subscriber authenticated. The home network, holding XRES*, is the only party that can.
Freshness and SQN: AUTN carries a sequence number that lets the UE detect replayed challenges. If the UE reports a synchronization failure (AUTS), the AUSF relays it to the UDM/ARPF for re-synchronization and a fresh vector — the AUSF does not resolve SQN itself.
A 5G-AKA run, message by message
Now put it together. The diagram below traces a full 5G-AKA authentication across the UE, the SEAF/AMF in the serving network, the AUSF and the UDM/ARPF in the home network. Watch the two N12 round trips and the single N13 fetch, and note where each of the two comparisons happens.
5G-AKA run. The AUSF fetches the vector over N13, keeps XRES* and sends only HXRES* down; the SEAF filters with HRES*, the AUSF makes the authoritative RES* check and returns KSEAF.Read top to bottom: the UE presents its concealed identity in the Registration Request; the SEAF asks the AUSF to authenticate; the AUSF pulls a fresh 5G Home Environment Authentication Vector (5G HE AV) from the UDM/ARPF; the challenge (RAND, AUTN, HXRES*) comes back down to the SEAF, which passes only RAND and AUTN to the UE inside a NAS Authentication Request. The UE validates AUTN (authenticating the network), computes RES*, and returns it. The SEAF does its local HRES* gate, then hands RES* to the AUSF for the decisive comparison against XRES*. On success the AUSF returns the result plus the anchor key.
What the AUSF produces: KAUSF, KSEAF and beyond
Authentication is not only a yes/no verdict — its real product is key material. This is where the AUSF plugs into the wider 5G key hierarchy, so it is worth cross-linking to the key-hierarchy page and stating the chain precisely.
Two keys are the AUSF's direct concern. KAUSF is derived and kept in the home network at the AUSF; it never leaves home. From it the AUSF derives KSEAF, the anchor key for the serving network, and that is the key handed down to the SEAF in the final Authenticate Response. The SEAF then derives KAMF from KSEAF, and from KAMF flow the NAS protection keys and, ultimately via KgNB, the access-stratum keys on the air interface.
The division of trust in one sentence: the home network keeps KAUSF, gives the serving network only KSEAF, and the serving network builds everything below KAMF from there. Compromise of a serving network never exposes the key that stays home.
Keeping KAUSF resident at the AUSF also enables the home network to protect certain messages to the UE directly, independent of the serving network — which is exactly what the next section is about.
Beyond authentication: SoR and UPU protection
Because the AUSF holds KAUSF — a key the UE can also derive but the serving network cannot — the home network can use it to cryptographically protect two kinds of home-controlled information that transit an untrusted visited network.
Steering of Roaming. The home network sends the UE a preferred list of PLMN/access-technology combinations so the device roams onto partner networks the operator actually wants. The AUSF computes a SoR-MAC-IAUSF over the list so the UE can verify it was not tampered with by the visited network.
UE Parameter Update. The home network updates on-device parameters (for example the Routing Indicator or default configured NSSAI) after registration. The AUSF computes a UPU-MAC-IAUSF so the UE trusts the update genuinely came from home.
In both cases the UDM assembles the payload, asks the AUSF to protect it with a MAC keyed from KAUSF, and the UE — deriving the same key — verifies (and for SoR, can return an acknowledgement MAC). The visited network only relays; it cannot forge or alter.
The lesson generalizes: the AUSF is not merely a login checker that goes quiet after registration. By anchoring KAUSF in the home network, it becomes the home network's trusted agent for any control-plane information that must reach the UE with integrity even while the subscriber is roaming on someone else's infrastructure.
LTE ↔ NR: in LTE (EPS-AKA) the visited MME received full authentication vectors from the HSS/AuC and ran the check itself — there was no separate home authentication server making the final call. 5G inserts the AUSF as a home-only decision point, withholds XRES* from the serving network, and keeps KAUSF resident at home so it can protect SoR/UPU too. LTE had no equivalent home-anchored key or these home-controlled update protections.
Summary
The AUSF is the home network's authentication server, defined in TS 33.501 and present only in the HPLMN. It sits between the serving network's SEAF/AMF (over N12, the Nausf_UEAuthentication service) and the UDM/ARPF (over N13, the Nudm_UEAuthentication service), and it runs one of two methods chosen by the UDM/ARPF: 5G-AKA or EAP-AKA'. It never speaks to the UE directly.
In 5G-AKA the verification is split: the SEAF does a fast local HRES*-vs-HXRES* filter, but only the AUSF's RES*-vs-XRES* comparison is authoritative — the serving network never receives XRES* and so can never fabricate success. The AUSF's real output is key material: it keeps KAUSF at home and hands only the anchor key KSEAF to the serving network, which then derives KAMF and everything below it. Because KAUSF stays home, the AUSF also protects SoR and UPU messages to the UE with KAUSF-keyed MACs. The through-line: decision and secrets stay home; only derived keys go out.
Quick Q&A
These are the questions that separate reciting the acronym from understanding what the AUSF actually does.
Q. Can a visited network authenticate a subscriber on its own in 5G?
A. No. The AUSF exists only in the home network, and only the home network holds XRES* and confirms the result. The visited SEAF can do a fast local HRES* filter, but authentication is not declared successful until the home AUSF checks RES* against XRES*.
Q. In 5G-AKA, who checks HXRES* and who checks XRES*?
A. The SEAF hashes the UE's RES* into HRES* and compares to HXRES* locally. The AUSF compares the raw RES* to XRES*. Only the AUSF's check is authoritative.
Q. Which interfaces does the AUSF use, and for what?
A. N12 (Nausf_UEAuthentication) to the SEAF/AMF in the serving network, and N13 (Nudm_UEAuthentication) to the UDM/ARPF in the home network to fetch the authentication vector.
Q. What keys does the AUSF derive, and which one leaves the home network?
A. It derives KAUSF, which stays at the AUSF, and from it KSEAF, which is the anchor key sent to the SEAF. The SEAF then produces KAMF. Only KSEAF crosses to the serving network.
Q. How do 5G-AKA and EAP-AKA′ differ from the AUSF's point of view?
A. In 5G-AKA verification is split (SEAF on HXRES*, AUSF on XRES*). In EAP-AKA' the AUSF is a full EAP server and verifies the UE's RES itself while the SEAF merely passes EAP messages through. The UDM/ARPF picks the method.
Q. What does the AUSF do after authentication is over?
A. It uses the resident KAUSF to protect home-network messages to the UE: it computes SoR-MAC-IAUSF for Steering of Roaming and UPU-MAC-IAUSF for UE Parameter Update, so the UE can trust those came from home untouched by the visited network.
Where to go next
You have followed a primary authentication run from the SEAF's request to the anchor key it receives back. Next, see where KSEAF goes as it becomes KAMF and the air-interface keys, and meet the home-network functions that supplied the vector and the identity: