Authentication and Key Management for Applications (AKMA) is a 5G feature that lets an application reuse the credentials already stored on the SIM or USIM, instead of provisioning its own separate secret. It is specified by 3GPP SA3 in TS 33.535, with the anchor function services and APIs defined in TS 29.535 and the original study captured in TR 33.835. If you build or secure applications that ride on a mobile subscription, AKMA is the mechanism that turns the operator's primary authentication into an application layer key. This post explains how AKMA works end to end and where its security properties actually depend on correct configuration.
What AKMA is, in one paragraph
AKMA is a delegated key distribution service. When a device performs 5G primary authentication, both the device and the network derive a set of keys. AKMA takes one of those keys and uses it to produce an application specific key that a device and an Application Function (AF) can share, without the application ever seeing the long term SIM secret. The result is that an application server can authenticate a device on the strength of its cellular subscription, and the two ends can protect their traffic with a key that is bound to that subscription. This is particularly useful for IoT devices and headless endpoints that have a SIM but no practical way to manage separate application credentials.
Why AKMA exists: from GBA to AKMA
The idea of bootstrapping application security from cellular credentials is not new. The Generic Bootstrapping Architecture (GBA), specified in TS 33.220, did the same thing for earlier generations using a Bootstrapping Server Function. GBA saw limited deployment, partly because of complexity and partly because it predated the modern service based 5G core. AKMA is the 5G native successor. It is designed around the Service Based Architecture (SBA), introduces a purpose built network function, and lets the application layer protocol be chosen per service rather than fixed. If you already understand the 5G Authentication and Key Agreement (AKA) flow, AKMA is the layer that extends that trust to applications.
How AKMA works: the key hierarchy
AKMA reuses the output of 5G primary authentication and derives a chain of keys from it. Getting this hierarchy right is the core of AKMA security, so it is worth walking through step by step.
Primary authentication and KAUSF
When the device attaches and completes primary authentication, the device and the Authentication Server Function (AUSF) both hold an anchor key called KAUSF. This is the same primary authentication used across the 5G system, so any weakness in that step, for example the linkability issues discussed in our post on 5G-AKA linkability attacks, propagates upward into everything derived from it, including AKMA.
KAKMA and the A-KID
From KAUSF, an AKMA specific key called KAKMA is derived, together with an identifier known as the AKMA Key Identifier (A-KID). The AKMA Anchor Function (AAnF) stores KAKMA and indexes it by the A-KID. The A-KID is structured so that the network can route a later key request back to the correct home network and the correct anchor key. That routing information is convenient operationally, but it also means the identifier is not opaque, which matters for the privacy discussion below.
KAF and the Application Function
When the device wants to talk to a specific application, it presents the A-KID to the Application Function (AF). The AF then asks the AAnF for an application specific key, KAF, referencing that A-KID. The AAnF derives KAF from KAKMA, scoped to that particular AF, and returns it along with an expiry time. The device derives the same KAF locally. Neither side has to exchange the key itself, and the AF never learns KAKMA or KAUSF. This scoping is what limits the blast radius: a KAF issued to one application should not be usable against another.
The Ua* interface
The protocol between the device and the AF is called the Ua* interface. AKMA deliberately leaves the choice of Ua* protocol to the application, with Transport Layer Security (TLS) recommended as the default, using the KAF as a pre shared key. That flexibility is a strength, but it also moves a large part of AKMA's real world security onto the AF and its TLS configuration. A weak or misconfigured TLS deployment on the application side undermines the key material that AKMA worked to protect.
The AKMA trust model inside the 5G core
AKMA introduces the AAnF as a new network function on the 5G Service Based Architecture. The AAnF exposes services that other functions and application functions call to obtain KAF. There are two paths for an AF to reach the AAnF. An AF that the operator trusts and hosts internally can call the AAnF directly over the SBA. An external, third party AF instead goes through the Network Exposure Function (NEF), which acts as the controlled boundary between the operator core and outside application providers. This split is important: the NEF is where the operator decides which external application may request keys for which subscribers, and that authorization decision is a security control, not a formality.
Where AKMA security actually concentrates
AKMA inherits the strengths of primary authentication, but its practical security depends on a handful of decisions. These are the areas worth scrutinising in any deployment.
Anchor key lifetime and freshness
KAUSF, and therefore KAKMA, is refreshed on primary re-authentication. If a network re-authenticates devices infrequently, the anchor key and the keys derived from it can remain valid for a long time. Formal security analyses of AKMA have highlighted that the freshness of derived keys is tied to how often primary authentication runs, and that the architecture does not, on its own, provide perfect forward secrecy at the anchor. Operators should think about re-authentication cadence and KAF lifetime together rather than in isolation.
Application Function authorization and the NEF boundary
For external applications, the NEF is the gate. The core question is whether an AF is authorized to obtain a KAF for a given subscriber and a given purpose. If AF authorization at the NEF or AAnF is weak, permissive, or misconfigured, an application could obtain key material it was never meant to have. Treat the AAnF key request APIs with the same rigour as any other sensitive SBA service, applying the transport and token protections defined in TS 33.501.
The A-KID and subscriber privacy
Because the A-KID carries routing information about the home network, it is not a random opaque token. If the same identifier is observable across different application functions, it introduces a correlation surface that can link a subscriber's activity across services. This is a design consideration rather than a break, but it deserves attention wherever AKMA is used for privacy sensitive applications. It connects directly to the broader identity privacy questions covered in our post on SUPI and SUCI.
Dependence on the SBA and primary authentication
AKMA is only as strong as the two things it stands on: the 5G primary authentication that produces KAUSF, and the SBA that carries AAnF traffic. If service based interfaces are not properly protected, the key distribution that AKMA performs becomes a target. This is the same class of concern we describe for other core functions, and it reinforces why data management and authentication functions have to be hardened as a set rather than one at a time.
What to check before relying on AKMA
For operators, confirm that the AAnF is deployed as a first class SBA function with the same TLS and authorization controls as the rest of the core, that NEF based AF authorization is explicit and least privilege, and that re-authentication cadence and KAF lifetimes are set deliberately. For application owners, remember that the Ua* protocol carries much of the real protection: use a current TLS configuration, treat KAF as sensitive key material with a defined lifetime, and never assume the identifier presented by a device is anonymous. AKMA is a genuinely useful way to extend cellular grade authentication to applications and IoT, but like most of the 5G core, its security is a property of how it is configured, not just of the specification.
If your team is evaluating AKMA, the AAnF, or the wider authentication and key management surface of your 5G core, we are happy to help you review it. Reach out at [email protected].
