5G Authentication: how 5G-AKA and EAP-AKA actually work
A SUCI hides who's asking. It doesn't prove they're telling the truth, and it doesn't stop a fake base station answering back. That's a separate exchange — SEAF, AUSF, and the five shapes an Authentication Vector can take.
Getting a SUCI onto the air safely, which we covered in the last article, solves exactly one problem: hiding who is asking to connect. It does not prove the phone is telling the truth, and it does not stop a fake base station from impersonating the network back at the phone. That is a different job, done by a different exchange, and it happens immediately after the SUCI is sent — before the network has agreed to do anything else for the device.
That exchange is AKA — Authentication and Key Agreement. This article is the procedure end to end: which network function does what, what a 5G Authentication Vector actually contains, the two mandatory methods side by side, what happens when it fails, how it survives roaming across an operator boundary neither side trusts, and where the published attacks actually land.
What authentication has to achieve, and why it is mutual
Two separate claims need proving, in both directions.
The network needs to know the SIM is genuine — not a cloned card, not a device replaying an old session. That part is intuitive; it is why SIM cards exist.
The phone needs to know the network is genuine too, and this half is the one people forget. Without it, nothing stops a radio in a van from broadcasting a strong signal, calling itself your operator, and having every phone nearby camp on it. AKA is deliberately mutual: the network authenticates the subscriber, and the subscriber authenticates the network, in the same exchange.
3GPP defines two flavours. Primary authentication happens with the home operator, every time a device attaches, and produces the keys everything else is built from. Secondary authentication is optional and happens afterward, between the device and an external data network — a factory's own authentication server, for instance — layered on top of primary authentication rather than replacing it. This article is about primary authentication, because it is the one every device goes through, every time.
The functions involved, and who trusts whom
5G split authentication across more network functions than 4G did, and the split is not bureaucratic — each boundary is a trust boundary.
SEAF — Security Anchor Function. The first point of contact in the serving network. As of Release 17 it is co-located with the AMF, so in practice "SEAF" and "AMF" are the same box, but the specs keep them conceptually separate because in a roaming call the AMF belongs to the network you are visiting, while SEAF's anchor role is what lets a security context survive you moving between cells and even between AMFs without re-running the whole exchange from scratch.
AUSF — Authentication Server Function. Lives in the home network. This is the function that actually decides whether authentication succeeded — not SEAF, which only knows what the home network tells it.
UDM — Unified Data Management, with two functions co-located inside it that matter here:
ARPF — Authentication Credential Repository and Processing Function. Holds the long-term secret key K, shared with the SIM and never transmitted anywhere. Computes the authentication vector.
SIDF — Subscription Identifier De-concealing Function. Turns a SUCI back into a SUPI, covered in full in the previous article.
The shape that falls out of this: AMF and SEAF sit in the serving network — the one you're camped on right now, which may not be your home operator. AUSF and UDM sit in the home network — the one that issued your SIM and is the only place your long-term key exists. Every authentication design decision in 5G traces back to that one asymmetry: the serving network is not trusted with your key, ever, under any circumstances, including when it is the network authenticating you.
The four methods, and the two that matter
3GPP defines four AKA methods. A UE and serving network are required to support the first two; the other two exist for specific deployments.
5G-AKA — the default. A symmetric challenge-response built on the shared secret K, extending the AKA used in 3G and 4G. Mandatory.
EAP-AKA' — the same underlying cryptography, wrapped in the EAP framework (RFC 9048) instead of 3GPP's native messages. Mandatory. The point of wrapping it in EAP is reuse: EAP is the same framework Wi-Fi authentication uses, so a 5G core can authenticate a device over non-3GPP access — a Wi-Fi hotspot, for instance — using the identical method it uses over the radio. That convergence is one of the genuine architectural improvements in 5G over 4G, which had separate, incompatible flows for cellular and untrusted Wi-Fi.
EAP-TLS — certificate-based, no SIM at all. Optional, aimed at private networks where devices carry certificates instead of operator SIMs — an industrial sensor, for example.
EAP-TTLS — added in Release 17, for a standalone non-public network where the entity holding the device's credentials sits entirely outside the 5G core. A specific enterprise scenario.
This article covers 5G-AKA and EAP-AKA' in depth, because between them they cover essentially every consumer device on every commercial network.
The five-second version, before the detail
Both methods share one shape, worth holding in your head before the message-by-message detail:
The home network's ARPF and your SIM both know K. ARPF generates a random challenge, RAND, and computes what the correct response should be, XRES, plus an authenticity token, AUTN, that proves the challenge really came from home. RAND and AUTN travel to the phone. The phone's SIM checks AUTN — this is the network authenticating itself to the phone — computes its own response using RAND and K, and sends that response back. The network compares it to XRES. Match means the SIM is genuine.
Crucially, the serving network never sees K, and in 5G-AKA it never even sees the raw response the SIM computed — only a hashed version. Only AUSF, in the home network, does the real comparison. This is the design that lets you roam onto a network your operator does not fully trust with your secrets, and still be authenticated correctly.
The 5G Authentication Vector: what's actually in the box
An Authentication Vector, or AV, is the bundle ARPF computes and hands upward. There isn't one AV shape — there are five, and confusing them is the single most common source of confusion when reading a trace, because two of them look nearly identical but travel over completely different links. 
5G HE AV (Home Environment) — RAND, AUTN, XRES*, K_AUSF. Computed by ARPF, handed to AUSF. Never leaves the home network. This is the one with the actual expected answer in it.
5G AV — RAND, AUTN, HXRES*, K_SEAF. Computed by AUSF from the HE AV, handed to SEAF. Notice XRES* has become HXRES* — a hash — and K_AUSF has become K_SEAF, a key derived from it. This vector is explicitly forbidden from crossing a SEPP or from being sent from a 5G core to a legacy EPC. It is serving-network-only.
5G SE AV (Serving Environment) — RAND, AUTN, HXRES*. What SEAF actually forwards toward the radio side of the exchange — notice K_SEAF is not in it; SEAF keeps that back until authentication has actually succeeded.
AV (legacy shape) — RAND, AUTN, XRES, CK, IK. The old 3G/4G vector shape, still produced internally and run through the f1–f5 algorithm family to derive the 5G HE AV. Legacy, but it's where the arithmetic actually happens.
AV′ (transformed) — same idea as AV, but CK and IK are replaced with CK′ and IK′, generated specifically when EAP-AKA′ is the method in use.
Hold onto one fact from that list: HXRES* is only a hash of XRES*, and it's the sole response value SEAF ever gets to compare against directly. SEAF authenticating you and AUSF authenticating you are two separate comparisons, on two different values, and only one of them — AUSF's — is the one that actually counts.
5G-AKA, message by message
This is the default method, and the one worth being able to draw from memory.
1. UE sends its identity — SUCI if this is a fresh registration, 5G-GUTI if it has one from before — over an N1 NAS message to SEAF, along with the Serving Network Name (SNN).
2. SEAF sends an authentication request to AUSF: the SUCI (or SUPI, if it derived one from the GUTI) plus the SNN.
3. AUSF forwards the request to UDM.
4. Inside UDM: SIDF decrypts the SUCI to a SUPI if needed. ARPF selects the authentication method for this subscriber and generates the 5G HE AV. UDM sends the 5G HE AV and the SUPI back to AUSF. Nothing has been authenticated yet — this whole step is preparation.
5. AUSF computes HXRES* from XRES* and RAND, derives K_SEAF from K_AUSF, and sends the 5G SE AV — RAND, AUTN, HXRES* — to SEAF. K_SEAF is deliberately withheld at this point.
6. SEAF forwards RAND and AUTN to the UE.
7. The UE's SIM verifies AUTN — checking the network is genuine and the challenge is fresh — computes RES* from RAND and K, and returns it to SEAF.
8. SEAF computes HRES* by hashing the UE's RES* the same way AUSF hashed XRES*, and compares HRES* to the HXRES* it already holds. If they match, the serving network is satisfied — but this is not the authoritative check. SEAF forwards RES* on to AUSF regardless.
9. AUSF compares RES* against the real XRES* — the actual answer, which only AUSF has, and which has an expiry. Match means authentication has genuinely succeeded.
10. Only now does AUSF send SUPI and K_SEAF to SEAF. SEAF is not permitted to serve the UE until it knows the SUPI — the serving network is not allowed to keep a subscriber connected anonymously past this point.
11. SEAF derives K_AMF from K_SEAF and hands it to AMF along with an ngKSI (key set identifier). This is the moment the NAS Security Mode Command procedure kicks off, encrypting and integrity-protecting everything that follows.
Read steps 8 and 9 again, because they're the entire point of the design: there are two comparisons, at two different places, and they exist for two different reasons. SEAF's check is a fast, local sanity check the serving network can perform without trusting anyone. AUSF's check is the one with legal and billing weight — it's performed by the home operator, on a value the serving network never even got to see un-hashed, and it's the only one that actually releases your SUPI and your keys.
EAP-AKA′, message by message
Same cryptography underneath, different envelope. EAP defines three roles: peer (the UE), pass-through authenticator (SEAF, which does not interpret the EAP payload, only relays it), and backend authentication server (AUSF, which does).
1. UDM/ARPF generates a legacy AV and transforms it into AV′ — CK′ and IK′ replacing CK and IK — and sends it to AUSF, flagged for EAP-AKA′.
2. AUSF sends an EAP-Request/AKA′-Challenge to SEAF.
3. SEAF does not open this message. It wraps it in a NAS message, adds an ngKSI and an ABBA parameter, and forwards it to the UE untouched. This is what "pass-through" means concretely.
4. The UE's ME hands AUTN and RAND to the USIM. The USIM verifies AUTN.
5. On success, UE sends back an EAP-Response/AKA′-Challenge. SEAF relays it to AUSF without inspecting it, exactly as before.
6. AUSF and the UE may exchange EAP-Notification messages at this point — again purely relayed by SEAF.
7. AUSF compares the UE's RES to its own XRES. Notice there is no SEAF-side hash comparison here at all — unlike 5G-AKA, EAP-AKA′ gives the serving network no interim check; SEAF is genuinely just a wire.
8. On success, AUSF derives EMSK, K_AUSF and K_SEAF from CK′ and IK′, and sends an EAP-Success to SEAF along with K_SEAF and, optionally, the SUPI.
9. SEAF derives K_AMF from K_SEAF exactly as in 5G-AKA, hands it to AMF, and forwards the EAP-Success on to the UE, which now derives its own copy of the same key hierarchy.
The practical difference to remember: 5G-AKA gives the serving network its own fast local check via HXRES* — EAP-AKA′ does not. In EAP-AKA′, SEAF is a pure relay throughout, and the only comparison that happens anywhere is AUSF's.
Why authentication fails, and who decides
Failure is not one event — it's four different events at four different places, and knowing which one you hit tells you what actually went wrong.
Synchronisation failure, caught by the USIM itself. AUTN carries a sequence number, and if the USIM's own counter has drifted too far from what AUTN claims — commonly from a SIM having been used elsewhere, or clock skew after being idle a long time — the USIM refuses AUTN and returns an AUTS token instead of RES*, routed back through the ME to SEAF to UDM/ARPF, which uses it to resynchronise before trying again. This is a legitimate, expected event, not an attack, and it happens more than most people assume.
Subscription-level rejection at UDM. Independent of the cryptography — a roaming restriction, a barred subscription, a suspended account. The maths could work perfectly and the answer would still be no.
Rejection at AUSF for a network-level reason. The specific case worth knowing: the serving network is not authorised to use the SNN it submitted. This stops one network from authenticating a subscriber while impersonating a different, more trusted network's name.
The comparison itself fails, in one of three ways: SEAF gets no reply from the UE at all; HRES* fails to match HXRES* at SEAF; or, decisively, RES* fails to match XRES* at AUSF, or the 5G AV had already expired by the time AUSF checked it.
In every case, AUSF is the function that informs everyone else of the outcome — SEAF does not get to unilaterally decide a subscriber failed and act on that alone; the home network has the final word, which is exactly the same design principle that governs success.
Authentication across a roaming boundary you don't trust
This is where the architecture earns its complexity, because a vPLMN — the network you're visiting abroad — is, from your home operator's point of view, a network it does business with but does not fully trust with secrets.
A Security Edge Protection Proxy (SEPP) sits at the edge of both networks as the mandatory gateway for inter-PLMN control-plane signalling — that part is non-negotiable, and it's a real change from 4G, which let Diameter interconnect messages pass through with far less scrutiny of who along the path had touched them. What sits between the two SEPPs is more flexible than people assume: an IPX (IP eXchange) carrier is the common case and the one worth understanding, but 3GPP and GSMA also permit a direct SEPP-to-SEPP connection with no IPX in the path at all. Either way, the SEPP itself cannot be bypassed. N32 connects the two SEPPs and is deliberately confined to control-plane signalling. N9 connects the two UPFs and carries user-plane traffic.
For the authentication exchange specifically: the visited network's SEAF calls the home network's AUSF as an API, routed through vSEPP and hSEPP. That link is not just TLS between the two proxies — it uses PRINS (Protocol for N32 Interconnect Security), which lets the sending operator declare exactly which fields of a message an IPX carrier is legitimately allowed to modify in transit, and requires any such modification to be signed so the receiving operator can see precisely who changed what. IPX abuse was a real, documented category of exploit in 4G Diameter interconnects; PRINS is 5G's specific answer to it, and it applies whether or not an IPX actually sits in the path.
RES* still travels from SEAF up to AUSF for the real comparison, exactly as it would if you were on your home network, and AUSF still compares it against XRES* generated at home. Roaming does not change who authenticates you — the home network always does — it only changes how many hops and how much cryptographic wrapping that comparison has to survive to get there safely. The N9 link between user-plane functions gets its own separate protection, IPUPS (Inter-PLMN User Plane Security), because encrypted signalling and encrypted bearer traffic are different problems solved by different mechanisms.
What's actually broken, and what isn't
Worth being specific here, because "5G security" gets discussed as though it's one monolithic claim, and it isn't.
Pre-authentication messages are unencrypted, by necessity. The very first exchange — the one that sets up authentication in the first place — cannot itself be encrypted, because no shared key exists yet. That gap is exactly why the SUCI mechanism exists: it's the fix for the one identity value that genuinely needed protecting inside that unavoidable gap. But other pre-authentication signalling, including the temporary RNTI a phone is assigned, remains observable, and academic work has shown that observable metadata is enough to support device tracking and Denial-of-Service attacks even without ever learning the SUPI.
Fake base stations remain a live threat below the RRC layer. AKA authenticates the core network to the phone. It does not, on its own, prevent a fake gNB from completing enough of the radio-layer procedure to trigger a DoS, and in some documented configurations a rogue gNB that gets far enough can obtain a K_gNB, exposing user-plane traffic that lacks its own end-to-end encryption on top of the radio-layer protection.
Formal analysis found the specification under-specified, not merely the implementation. Basin, Dreier, Hirschi, Radomirovic, Sasse and Stettler's 2018 analysis using the Tamarin prover — work that predates commercial 5G but whose findings 3GPP has never fully closed out — modelled the AKA agreement properties formally and found the specification itself left security goals looser than commonly assumed, including a class of finding around sequence-number monitoring that could let an attacker infer information about the true SQN over repeated observations, undermining part of the freshness guarantee the whole mechanism depends on.
Session key reuse across concurrent runs is a real, documented failure mode. If K_SEAF from one authentication run gets bound to the correct UE but, due to a race in concurrent AKA procedures, the wrong SUPI, the result is a session that authenticates as one subscriber while billing or attributing traffic to another — a fraud vector, not merely a privacy one.
None of this is 3GPP's blind spot — it's an acknowledged, live area of work. Key management specifics are deliberately left to individual operators rather than mandated, which is defensible engineering flexibility and also means market pressure during an early, competitive rollout can and does produce weaker deployments than the specification permits. The most concrete recent response is RFC 9678, published in March 2025, adding an optional forward-secrecy extension to EAP-AKA′: an ephemeral ECDH exchange folded into the derivation of the session keys, so that even a future compromise of the long-term key K cannot be used to retroactively decrypt a session captured today. It changes no existing message count, keeps the legacy MAC field untouched for backward compatibility, and is explicitly optional — which means whether any given network actually deploys it is, once again, entirely an operator decision.
Where to see it in a trace
For 5G-AKA specifically, the sequence to look for:
Authentication Request from AMF/SEAF to the UE, carrying RAND and AUTN — this is the SE AV arriving at the radio side.
Authentication Response, carrying RES* — check whether the call flow shows a distinct SEAF-side comparison before this response is relayed onward, versus EAP-AKA′ traces, where you will see no such intermediate step at all.
Authentication Result, the point where SUPI and keys actually change hands — this is the message that matters most when you're trying to determine exactly when a subscriber became "known" to the serving network, because it is later than most people assume; SEAF's earlier HXRES* match is not that moment.
If the trace instead shows an Authentication Failure with a synchronisation-failure cause and an AUTS parameter, that's the USIM rejecting a stale sequence number — a normal resync, not an intrusion attempt, and worth ruling out before escalating anything as an attack.
We cover the full 5G security architecture — SUCI, AKA, SEPP and roaming, and how to read every one of these messages out of a real trace — in our 5G Core (SA) course.