- AUSF is a 3GPP-defined 5G SA network function that handles 5G-AKA and EAP-AKA’ authentication for 3GPP access, it does not replace legacy AAA for non-3GPP access (Wi-Fi, fixed broadband, enterprise).
- A carrier operating 5G SA with Wi-Fi calling, fixed broadband, or enterprise device admin still needs a dedicated AAA server running RADIUS and Diameter alongside AUSF.
- Alepo AAA handles RADIUS, Diameter (S6b, SWx, SWm, Sh, Gx, Gy, and more), TACACS+, and the full EAP family on one platform, with integration into 5G core functions including the Session Management Function (SMF), AUSF, and Unified Data Management (UDM).
- Alepo AAA is deployed by carriers across multiple continents, from Tier-1 operators in the Middle East to regional operators in the Americas, covering broadband, mobile, and VoWiFi authentication.
- The platform runs containerized on Kubernetes at carrier scale and is designed for 99.999% availability, fewer than six minutes of unplanned downtime annually.
Every time a subscriber tries to connect to your network, AAA server 5G infrastructure is the system that decides whether they get on and what they are permitted to do once they are. Get that decision wrong, or take too long making it, and the consequences cascade: failed sessions, revenue leakage, and subscribers hitting error screens at the moment they need connectivity most.
In 2026, as operators push into 5G Standalone (SA) architecture, the authentication question has become structurally more complicated. The 3GPP standards body introduced the Authentication Server Function (AUSF) as the native 5G auth function, and engineers migrating from 4G now face a question that is not answered cleanly anywhere in the vendor literature: does AUSF replace the legacy AAA server, or do both need to coexist?
This guide covers what AUSF actually is and how it fits in a 5G SA core, the specific differences between a legacy AAA server and AUSF across protocols and architecture, when a dedicated AAA server remains necessary even in a fully 5G SA network, and how Alepo’s platform bridges 4G and 5G authentication without forcing operators to choose one and abandon the other.
What Is AUSF? The 5G Native Auth Function
The Authentication Server Function is not just a renamed AAA server. It is a purpose-built 5G SA network function defined in 3GPP Release 15 (TS 33.501) that handles authentication specifically for the 5G System and it interacts with the rest of the 5G core in ways that a legacy AAA server was never designed to do.
Definition and Core Function
AUSF is the 3GPP-defined authentication anchor for 5G Standalone networks. It receives authentication requests from the Access and Mobility Management Function (AMF) over the Nausf interface, retrieves authentication credentials from the UDM function, and executes 5G-AKA or EAP-AKA’ authentication to issue the authentication vectors that allow a UE onto the 5G SA core. Every authenticated 5G SA mobile session passes through AUSF, it is the function that confirms subscriber identity before the SMF establishes a PDU session.
How It Works in Carrier Networks
When a 5G UE attempts to register on the network, the AMF sends a Nausf_UEAuthentication_Authenticate Request to the AUSF. The AUSF queries the UDM for authentication credentials via the Nudm_UEAuthentication_Get service retrieving the subscriber’s 5G-HE-AV (Home Environment Authentication Vector) from the Unified Data Repository (UDR). From there, AUSF executes either 5G-AKA (the standard mechanism defined in TS 33.501 Clause 6.1) or EAP-AKA’ (TS 33.501 Clause 6.2) depending on network configuration and UE capabilities. The result is an authentication vector passed back to the AMF to complete the registration procedure. AUSF also anchors the security context, it stores the Kausf key, which becomes the root of the 5G security key hierarchy.
Why It Matters for CSPs Today
If AUSF is misconfigured or unavailable, no subscriber can register on your 5G SA core, every attempted session fails before a PDU session is even established, which means no data service, no Voice over New Radio (VoNR), and no revenue from the 5G investment. Beyond availability, AUSF is where the 5G security architecture anchors itself: a misconfigured Kausf derivation or a missing 5G-HE-AV from UDM means authentication vectors are wrong, and subscriber sessions fall back or fail entirely.
For operators migrating from 4G, the subtler risk is this, AUSF only handles 3GPP access. The moment a subscriber picks up a Wi-Fi call, connects to a hotspot, or a NetOps engineer authenticates to a router via TACACS+, AUSF plays no role. Something else has to handle that.
AAA Server vs AUSF: Key Differences
AUSF and a legacy AAA server are not the same thing in a different container. They were built for different protocol families, different access types, and different operational models. Treating them as interchangeable leads to authentication gaps, typically discovered during integration testing, occasionally discovered in production.
| Dimension | Legacy AAA Server | AUSF (5G SA) |
|---|---|---|
| Standard | IETF RFC 2865 (RADIUS), RFC 6733 (Diameter) | 3GPP TS 33.501 (R15, R16, R17, R18) |
| Primary Interface | RADIUS UDP, Diameter TCP/SCTP | Nausf (HTTP/2 — 5G Service-Based Architecture) |
| Access Types Served | 3GPP and non-3GPP: fixed broadband, Wi-Fi, enterprise, mobile | 3GPP access only (5G SA gNB) |
| Auth Methods | PAP, CHAP, EAP-SIM, EAP-AKA, EAP-AKA’, EAP-TLS, EAP-TTLS, EAP-PEAP, certificate-based | 5G-AKA, EAP-AKA’ |
| Session Management | Full session lifecycle: accounting, CoA (RFC 5176), session teardown | Authentication only — session management lives in SMF/AMF |
| Deployment | Standalone server or containerized; connects to HSS/UDM, PCRF/PCF, OCS | Microservice in 5G core; tightly coupled with AMF and UDM |
| Policy Enforcement | Direct: RADIUS attributes, Diameter AVPs, CoA | Indirect: derives keys; policy lives in PCF |
The Most Operationally Important Distinction
The table above shows the architectural divide clearly: AUSF is a 5G SA core component operating over the Service-Based Architecture (SBA) using HTTP/2 and JSON, while a legacy AAA server operates over RADIUS (UDP, RFC 2865) or Diameter (TCP/SCTP, RFC 6733) and handles a far broader set of access types.
The most critical distinction is access scope. AUSF handles 3GPP access, mobile UEs connecting through a 5G gNB. Anything connecting over Wi-Fi (hotspots, VoWiFi via SWm/SWx), fixed broadband (BRAS/BNG via RADIUS), or enterprise networks (TACACS+ for device admin) sits entirely outside AUSF’s scope. A carrier cannot retire their AAA server simply because they have deployed 5G SA.
Which Should You Choose?
If you are a greenfield 5G SA operator with zero fixed broadband, no Wi-Fi calling, and no legacy device admin, and you are certain that will never change, AUSF handles your authentication needs as part of the 5G core. If you are any other type of operator, you need both: AUSF for 5G SA mobile authentication, and a dedicated AAA server for every access type that AUSF was not designed to reach. The migration question is not “AUSF or AAA” it is “how do these two coexist, and who owns each authentication path?”
When Legacy AAA Still Applies in 5G
The assumption that 5G SA renders the AAA server obsolete is wrong, and operators who plan infrastructure on that assumption discover the gap during integration. The reasons a dedicated AAA server remains necessary in a 5G network are architectural, not legacy, they are written into the 3GPP standards themselves.
5G SA Architecture Requirements for AAA
3GPP TS 23.501 defines the 5G System architecture. The non-3GPP interworking functions specifically, access via untrusted non-3GPP networks (the N3IWF, Clause 4.2.4) and trusted non-3GPP networks (the TNGF/TWIF) depend on EAP-based authentication that is typically served by an external AAA server, not by AUSF alone. The SWx interface (between AAA and the HSS/UDM) and the SWm interface (between ePDG and AAA) are explicitly defined for non-3GPP access scenarios in TS 23.501 and TS 23.402. These interfaces exist because 5G SA alone does not terminate non-3GPP access, an AAA server running Diameter does.
Similarly, an operator’s broadband subscribers authenticating via BRAS/BNG over RADIUS (RFC 2865) have no path through AUSF. The AAA server is the termination point for those sessions, and AUSF has no visibility into them.
AUSF, UDM, and Legacy AAA Coexistence
In a hybrid 4G/5G deployment which describes the majority of commercial operator networks in 2026, the UDM serves as the subscriber data source for both AUSF (via Nudm_UEAuthentication) and the legacy AAA (via Diameter S6a/S6b/SWx). An operator running EPC alongside 5G SA will have their HSS (often co-located with UDM in converged platforms) feeding authentication vectors to the legacy AAA for 4G EPC sessions, while the same UDM feeds AUSF for 5G SA sessions. The subscriber profile is shared; the authentication path differs by access type.
For a Tier-2 operator in the middle of a 4G-to-5G SA migration, this coexistence can persist for two to four years, long enough that the AAA server needs to be on a modern, supported platform rather than the legacy system it is currently replacing. An operator migrating off Cisco CPAR today is making a decision about what runs their authentication across the entire 4G-to-5G transition window.
Migration Path from 4G to 5G SA
A structured migration from 4G EPC (RADIUS/Diameter AAA) to 5G SA (AUSF + AAA coexistence) typically involves the following steps:
- Audit current authentication scope. Map every access type currently terminating on the legacy AAA: BRAS/BNG RADIUS sessions, Wi-Fi offload (STa/SWx), VoWiFi (SWm), EPC mobile (S6a), TACACS+ device admin. This determines what AUSF will cover post-migration versus what remains on the AAA.
- Export active subscriber sessions and RADIUS attributes from the existing AAA into a staging environment before any cutover begins. Session loss during cutover is the primary failure mode.
- Deploy the new AAA in active-standby mode alongside the legacy system. Run parallel authentication for a defined window, typically four to eight weeks, to validate that reject rates and latency match expectations before cutting traffic.
- Integrate AAA with UDM/HSS. Confirm Diameter SWx and S6b interfaces are live and that the UDM is serving authentication vectors to both AUSF and the AAA correctly for their respective access paths.
- Validate non-3GPP access paths independently. VoWiFi (SWm → SWx → S6b) and Wi-Fi offload (STa) need separate test plans, these are not automatically validated by 5G SA core testing.
- Cut legacy AAA traffic to the new platform in access-type segments, not as a single cutover broadband first, then Wi-Fi, then mobile, then device admin, so that a failure in one access type does not take down all authentication simultaneously.
Non-3GPP Access and the AAA Server’s Role
Non-3GPP access covers every connection that does not go through a 5G gNB or 4G eNB Wi-Fi, fixed broadband, enterprise LANs, and any other access network the 3GPP standards treat as external to the cellular core. This is where a dedicated AAA server is not just useful, it is the specified termination point in the standard.
Core Concepts and Definitions
Non-3GPP access in the context of 5G SA is defined in 3GPP TS 23.501 Section 4.2.8 and in TS 23.402. It splits into two categories: trusted non-3GPP access (where the access network is deemed secure by the operator, using the Trusted WLAN Access Gateway or TNGF) and untrusted non-3GPP access (where a Non-3GPP InterWorking Function, N3IWF, provides the security boundary). In both cases, subscriber authentication ultimately relies on EAP methods EAP-AKA, EAP-AKA’, or EAP-TLS and on an AAA server that terminates the EAP exchange, queries the HSS/UDM for credentials, and returns authentication results to the access network. AUSF is not in this path. The Nausf interface is only invoked for 3GPP radio access via AMF.
How This Applies to Your Network
For a carrier operating Wi-Fi calling (VoWiFi), the authentication path is: UE → ePDG → AAA (over SWm) → HSS/UDM (over SWx) → credential validation → authentication result back to ePDG → IMS session establishment.
Alepo AAA handles this path in production across multiple live VoWiFi deployments, including Tier-1 operators running the full SWm → SWx → S6b Diameter interface chain at carrier scale. If that AAA is unavailable, VoWiFi fails completely. Every subscriber who walks indoors and loses cellular coverage loses their call. The AAA server in a Wi-Fi calling deployment is not a legacy dependency to be removed when 5G SA arrives; it is an active, subscriber-facing component of the voice service.
Alepo’s Implementation Approach
Alepo AAA terminates the full Diameter interface set required for non-3GPP access: SWx (HSS/UDM integration), SWm (ePDG for untrusted Wi-Fi), S6b (PGW integration), SWa (untrusted non-3GPP), and STa (trusted non-3GPP). These interfaces are production-deployed across Alepo’s operator base. The platform also integrates with the 5G SMF, enabling AAA policy decisions to propagate into 5G SA session handling, the point where the AAA and the 5G core move from running in parallel to running in coordination.
Legacy-to-5G Migration Paths
Migration risk in AAA concentrates in two places: session state and protocol coverage. An operator migrating from a legacy AAA whether Cisco CPAR/CNR, a Bridgewater/Lucent system, or a DIY FreeRADIUS deployment at scale is not just changing software. They are changing the platform that terminates authentication for every subscriber session on the network. Done in a single cutover, that is an outage waiting to happen. Done in stages, with parallel operation and careful monitoring, it is a manageable program.
Pre-Migration Assessment Checklist
Before any migration work begins, an operator should complete the following:
- Catalogue every active AAA realm and APN. Unknown realms are the most common source of post-migration authentication failures. Run a live report from the current system, do not rely on documentation, which is frequently out of date.
- Document all custom RADIUS attributes and vendor-specific attributes (VSAs) in use. Every VSA must be mapped to the target platform before migration starts.
- Identify all EAP method types currently in use (EAP-SIM, EAP-AKA, EAP-AKA’, EAP-TLS, etc.) and confirm the target AAA platform terminates all of them natively.
- Map integration dependencies. For each access type, document the downstream systems the AAA communicates with: HSS/UDM, PCRF/PCF, OCS, BSS/CRM, BRAS/BNG vendors, WLC vendors.
- Establish a baseline for current reject rates and authentication latency. You need pre-migration numbers to validate that the new platform performs equivalently before cutting traffic.
- Confirm redundancy topology on the target platform. Active-active geo-redundant deployment should be validated in staging before any production traffic is moved.
Step-by-Step Migration Process
- Deploy the new AAA in parallel (active-standby). Route a shadow copy of authentication traffic to the new system and compare outcomes, accept/reject decisions, latency, and accounting record generation, against the legacy system.
- Migrate low-risk access types first. Fixed broadband BRAS/BNG RADIUS sessions typically have the cleanest data model and the lowest blast radius if something goes wrong.
- Migrate Wi-Fi and non-3GPP access next. SWm/SWx/STa/S6b Diameter interfaces should be validated access type by access type, not as a group.
- Migrate 4G EPC (S6a/S6b) mobile authentication. This is the highest-stakes cutover, execute in off-peak windows with rapid rollback capability confirmed and tested.
- Migrate TACACS+ device admin last. TACACS+ failure means network engineers lose privileged access to infrastructure, this is the access type where rollback must be fastest.
- Decommission the legacy system only after 30+ days of clean operation on the new platform with no unresolved incidents tied to the migration.
Avoiding Common Migration Pitfalls
- Do not migrate all realms simultaneously. Realm-by-realm migration, even if it takes longer, dramatically reduces the blast radius of any single misconfiguration.
- Do not assume VSA compatibility is automatic. Vendor-specific RADIUS attributes from Cisco NAS devices, for example, must be explicitly mapped on the new platform. Test every VSA in staging.
- Do not skip the parallel operation window. Two to four weeks of parallel operation with shadow traffic is not optional overhead, it is how you catch the edge cases that unit testing does not surface: specific subscriber profiles, unusual realm combinations, time zone-sensitive accounting windows.
- Do not cut over TACACS+ without a manual access fallback. If TACACS+ authentication fails during a cutover, engineers need an out-of-band path to reach network devices. Confirm local fallback credentials are active on all managed devices before the cutover window opens.
- Do not underestimate session state. If the legacy system holds active session state that the new platform does not inherit, subscribers will be re-prompted for authentication or logged as duplicate sessions. Coordinate session-state transfer with the cutover timing explicitly.
Alepo AAA: Bridging 4G and 5G Auth
Alepo AAA is in production across more than 100 operator deployments globally, with 50+ operators migrated from legacy systems and over 20 years of carrier-grade AAA deployment experience. The platform runs containerized on Kubernetes at carrier scale, including Tier-1 operators who have moved their authentication infrastructure to public cloud environments. This is not a cloud-native pitch with a legacy codebase underneath.
Key Technical Differentiators
Protocol breadth on one platform. Alepo AAA terminates RADIUS (RFC 2865, CoA via RFC 5176), Diameter (S6a, S6b, SWx, SWm, Sh, Gx, Gy, Sd, STa, SWa, SWd), and TACACS+ on a single stack. Operators consolidating authentication for fixed broadband, mobile, Wi-Fi, and enterprise device admin do not need three separate systems, one platform serves all four access types with one management interface, one provisioning API, and one support relationship.
Active-active geo-redundant architecture. The platform runs active-active redundant pairs across regions, meaning authentication continues without interruption even if a node fails. Alepo AAA is designed for 99.999% availability, fewer than six minutes of unplanned downtime annually, a figure that lands differently on an operations team that has lived through a two-hour AAA outage.
Containerised on Kubernetes, with full carrier-grade session state. Alepo runs carrier-grade, stateful AAA on Kubernetes in production at Tier-1 scale. The containerized deployment is production, not beta, Alepo’s engineering team has addressed the AAA session state challenge on Kubernetes that prevents many vendors from offering a genuine cloud-native AAA without sacrificing session persistence.
AI control plane built in, not integrated. The Alepo AI Agent for AAA sits directly on top of the AAA infrastructure, converting RADIUS, Diameter, and TACACS+ logs into real-time threat detection, anomaly detection, capacity trend analysis, and operational intelligence. It is part of the AAA stack not a separate product to purchase, integrate, and maintain.
Deployment and Integration Approach
Alepo AAA deploys as containers on Kubernetes (GCP, AWS, Azure, private cloud, on-prem K8s), as virtual machines on VMware or OpenStack, or on bare-metal for latency-sensitive packet-core workloads. The managed service option means Alepo runs and operates the platform, people, process, and software, for operators who want AAA as a service rather than as infrastructure to manage.
Integration with 5G core functions uses the full Diameter interface set for non-3GPP access paths, with direct SMF integration for session-aware 5G policy enforcement. Provisioning integrates with BSS/CRM systems over REST APIs, with bulk tooling and web console for operational management.
Deployed at Carrier Scale
Alepo AAA serves operators across the Middle East, LATAM, Africa, Asia, and North America covering DSL/broadband AAA, carrier mobile AAA, and VoWiFi with the full SWm/SWx/S6b Diameter interface chain running at carrier scale. Alepo has migrated 50+ operators from legacy AAA systems including Cisco CPAR/CNR, Bridgewater/Lucent platforms, and DIY FreeRADIUS deployments, accumulating carrier-grade AAA deployment experience across every major access type and geography.
Frequently Asked Questions
What is AAA server 5G authentication and why does it matter for telecom operators?
AAA server 5G authentication refers to the Authentication, Authorization, and Accounting infrastructure that controls subscriber and device access across a carrier’s networks, including 5G SA, 4G EPC, fixed broadband, Wi-Fi, and enterprise. For telecom operators, AAA is the gatekeeper for every network session: if it fails, subscribers cannot connect, sessions drop, and revenue stops. In a 5G environment, the AAA server handles the authentication paths that AUSF does not cover, non-3GPP access, fixed broadband, Wi-Fi calling, and device administration.
How does 5G change AAA server requirements?
5G SA introduces AUSF as the authentication function for 3GPP radio access but it does not eliminate the need for a traditional AAA server. Operators running 5G SA alongside fixed broadband, Wi-Fi calling (VoWiFi), or enterprise networks still need a RADIUS and Diameter-capable AAA to handle authentication on those access paths. Additionally, 5G increases pressure on AAA throughput and session capacity as operators converge multiple access types onto a single network. The AAA platform needs to be carrier-grade, cloud-deployable on Kubernetes, and capable of integrating with 5G core functions including UDM, SMF, and PCF.
Does a carrier still need a dedicated AAA server in a 5G Standalone core?
Yes — unless the operator has zero non-3GPP access of any kind. Any carrier running Wi-Fi calling, fixed broadband BRAS/BNG authentication, hotspot access, or TACACS+-based device administration still requires a dedicated AAA server. AUSF only handles authentication for subscribers connecting via 5G SA radio access. All other access types require RADIUS or Diameter termination on an external AAA server, as defined in 3GPP TS 23.501 and TS 23.402.
How long does it take to deploy AAA server 5G authentication?
Deployment timelines depend on the number of access types in scope, the complexity of existing realm and VSA configurations, and whether the deployment is net-new or a migration. A greenfield AAA deployment serving a single access type (broadband RADIUS, for example) can reach production in six to twelve weeks. A full migration from a legacy AAA system, covering multiple access types, custom VSAs, and live session state, typically runs three to six months when executed in the staged, parallel-operation approach that avoids cutover risk.
What integrations does AAA server 5G authentication need with existing telecom systems?
A carrier-grade AAA server integrates with HSS/UDM (Diameter S6a, S6b, SWx for subscriber credential lookup and IMS auth), PCRF/PCF (Diameter Gx for policy and QoS enforcement), OCS/Charging (Diameter Gy for real-time credit control), BSS/CRM (REST APIs for subscriber provisioning and account sync), and the network edge (BRAS/BNG vendors — Cisco, Nokia, Juniper for broadband RADIUS, and WLC/AP vendors for Wi-Fi). For 5G-specific integration, the AAA also connects to the SMF for session-aware 5G policy propagation.
What support model does an operator need for AAA server 5G authentication?
Carrier-grade AAA is mission-critical infrastructure, the support model needs to match. At minimum, this means 24/7 support coverage with defined response and resolution SLAs, a named technical point of contact for escalations, and a quarterly review process to align the platform with network changes and software updates. Alepo’s Platinum Support tier provides enhanced SLAs and priority escalation; the Technical Account Manager option adds a named senior engineer who participates in quarterly business reviews and roadmap planning.
Conclusion
AUSF is not a replacement for the AAA server, it is an addition to the authentication architecture. Operators deploying 5G SA get AUSF for mobile subscriber authentication on the 5G radio access network. They still need a carrier-grade AAA server for every other authentication path on the network: fixed broadband, Wi-Fi calling, enterprise device admin, and any non-3GPP access type.
The practical migration question is not which one to choose, but how to run both correctly, at scale, on a platform that can grow as the 5G footprint grows.
Alepo AAA serves operators globally, runs in production on Kubernetes at Tier-1 carrier scale, and is designed for 99.999% availability. If you are in the middle of a CPAR migration, planning a 5G SA launch, or consolidating multiple access types onto one authentication platform, the next step is a technical conversation not a sales call.
Download the AAA datasheet here.
