AAA Security Guide: Authentication, Authorisation and Accounting Explained

AAA stands for authentication, authorisation and accounting: proving who or what is asking for access, deciding what it may do, and recording what it actually did. In plain terms, it is the login, the permission check and the audit trail, and every access control system you run is some combination of the three. The term comes from network access protocols such as RADIUS, TACACS+ and Diameter, which still control logins to Wi-Fi, VPNs, routers and mobile networks, but the model applies equally to cloud consoles, APIs and machine identities. This guide explains each A in plain language, then goes into the protocols, ports and attributes, how AAA works for service accounts, API keys and workloads, how to roll out or modernise an AAA service, and how to measure it. It is written for network, identity and security engineers, and for anyone who needs a solid grounding in the concept.

Key takeaways

• Three separate questions sit behind every access decision: who are you (authentication), what may you do (authorisation), and what did you do (accounting). Weakness in any one undermines the other two.
• Accounting is audit logging with a session model: start, interim and stop records tied to one session ID. Without it you cannot investigate, bill or prove compliance.
• Legacy AAA protocols rely on MD5 and shared secrets. Classic RADIUS and TACACS+ obfuscate rather than encrypt, so they need protected transport: RADIUS over TLS (RADIUS/1.1) or TACACS+ over TLS 1.3 (RFC 9887).
• Machines need AAA too. Service accounts, API keys and workloads authenticate, get authorised and must be logged, but they rarely get MFA, reviews or session records unless you design for it.
• The AAA server is a crown jewel. Attackers who capture shared secrets or repoint devices to their own AAA server, as seen in the Salt Typhoon intrusions, control every login behind it.

What AAA means: the three As in plain language

Think of a building. Authentication is the badge check at the door, authorisation is which floors your badge opens, and accounting is the log of every door you went through and when. In IT the same three steps happen every time a person or a program asks for access.

Two points are often missed. First, identification (claiming a username) is not authentication (proving it). Second, authorisation should be evaluated on every request in modern systems, not only at login: the zero trust model depends on that. See the Authentication Guide and the Authorisation Models Guide for the deep dives on each.

How AAA works in a network: NAS, AAA server and identity store

Classic AAA has three roles. The network access server (NAS), also called the AAA client, is the device the user touches: a Wi-Fi controller, VPN concentrator, switch port or router. The AAA server receives the request, checks credentials and policy, and returns a decision. The identity store behind it holds the accounts: Active Directory, LDAP, an IdP or a local database. The NAS never needs to know passwords or policy; it asks and enforces.

1. Request: the user connects; the NAS sends an authentication request with the username and a protected credential, or relays an EAP conversation (802.1X).
2. Decision: the AAA server validates against the identity store and evaluates policy (group, device posture, time, location).
3. Enforcement: the response carries authorisation attributes, such as a VLAN, an access list, a session timeout or a privilege level for an administrator shell.
4. Accounting: the NAS sends a start record, optional interim updates and a stop record with duration, bytes and termination cause.

This split is what lets an organisation change policy in one place for thousands of devices. It also means the AAA server and the shared secrets between NAS and server are high-value targets. See the Network Access Control (NAC) Guide for 802.1X design.

AAA protocols compared: RADIUS, TACACS+ and Diameter

RADIUS details that matter in practice

• Packet codes: Access-Request (1), Access-Accept (2), Access-Reject (3), Access-Challenge (11), Accounting-Request (4), Accounting-Response (5).
• Shared secret: chosen by the server from the packet's source IP address; RFC 2865 recommends at least 16 octets and says it must never be empty. Use long, random, per-client secrets.
• Message-Authenticator: the 2024 Blast-RADIUS research showed that an attacker in the network path could forge an Access-Accept using an MD5 collision. RFC 9765 recommends clients include Message-Authenticator in Access-Requests over UDP and TCP; vendors issued updates that require it. Require it on every server and client that supports it, and move to TLS transport where you can.
• Accounting attributes: Acct-Status-Type (40) with Start (1), Stop (2), Interim-Update (3), Accounting-On (7) and Accounting-Off (8); Acct-Session-Id (44), which must be identical on start and stop records; Acct-Session-Time (46); and Acct-Terminate-Cause (49), for example 1 User Request, 4 Idle Timeout, 5 Session Timeout, 6 Admin Reset.

TACACS+ details that matter in practice

• Packet flow: authentication uses START, REPLY and CONTINUE; authorisation and accounting each use one REQUEST and REPLY pair. Because authorisation is separate, a device can ask the server before every command an administrator types.
• Accounting flags: START (0x02), STOP (0x04) and WATCHDOG (0x08) for long-running tasks. Command accounting gives you a per-command record of who changed a device configuration.
• Secrets and obfuscation: RFC 8907 requires implementations to support shared secrets of at least 32 characters and requires servers to reject connections with the unencrypted flag set. With TLS (RFC 9887) obfuscation is obsoleted and TLS 1.3 is the minimum.
• Break-glass: devices fall back to local accounts when the AAA server is unreachable. Those local accounts are the most common weak point in network device estates.

Where the protocols are not the answer

For web applications, SaaS and APIs, AAA is delivered by different standards: SAML and OpenID Connect for authentication, OAuth 2.0 scopes and policy engines for authorisation, and application or cloud audit logs for accounting. The concepts are identical; only the wire protocols change. Kerberos plays the authentication role inside Windows domains. See the Kerberos Security Guide.

AAA for humans versus machines

Most AAA programmes were designed for people at keyboards. Today machine identities, such as service accounts, API keys, OAuth clients, CI/CD tokens, workloads and AI agents, usually outnumber employees, and each A works differently for them.

• Prefer identity over secrets: replace long-lived API keys and service account passwords with short-lived tokens issued to a verified workload. See the Workload Identity Federation Guide.
• One identity per workload: shared service accounts destroy accounting, because you can no longer tell which system did what. See the Service Account Security Guide.
• Treat keys as authenticators: an API key is a bearer credential; whoever holds it is authenticated. Inventory, scope, rotate and log its use. See the API Key Management Guide and the NHI Authentication Guide.
• Network devices are machines too: SNMP community strings and the RADIUS or TACACS+ shared secrets themselves are non-human credentials that need storage in a vault and rotation.

Accounting: turning AAA records into audit evidence

Accounting is the A most often treated as optional, and the one investigators need most. In security terms it is audit logging with an identity and a session attached. A useful accounting record answers who, what, when, where (source address and NAS), how (method, such as EAP-TLS or password) and outcome (accept, reject, termination cause).

• Log rejects as well as accepts: Access-Reject and failed TACACS+ authentication are the raw material for brute-force and password spraying detection (MITRE ATT&CK T1110 Brute Force).
• Correlate by session ID: join Acct-Session-Id start and stop records to compute duration and to spot sessions that never stop.
• Enable command accounting on all network devices, so every configuration change is recorded against a named administrator.
• Ship off-box quickly: forward to a SIEM or log platform that the device administrators cannot modify (NIST SP 800-53 AU-9 Protection of Audit Information). Attackers clear local logs.
• Record changes to AAA itself: changes to AAA server addresses, shared secrets and local accounts on devices are among the highest-value events you can alert on (ATT&CK T1556 Modify Authentication Process).

See the Log Management and Retention Guide, the SIEM Guide and the Cloud Logging and Audit Trail Guide.

Choosing an AAA approach: decision guidance

• Network access for users and devices (Wi-Fi, wired 802.1X, VPN): RADIUS with EAP-TLS certificates is the default choice. Use RADIUS over TLS between sites or to cloud RADIUS services rather than raw UDP across untrusted networks.
• Administrative access to network devices: TACACS+, because command-level authorisation and accounting are what you need for change control. Where your devices support RFC 9887, plan to move to TACACS+ over TLS.
• Carrier and mobile core: Diameter, always over TLS, DTLS or IPsec.
• Applications, SaaS and APIs: federated SSO with OIDC or SAML, OAuth for delegated access, and a policy engine for fine-grained authorisation. See the Policy-as-Code for Authorisation Guide.
• Small organisations: a managed cloud RADIUS or the IdP's built-in network access service, plus SSO for SaaS, usually beats running servers. Focus on MFA, unique admin accounts and keeping logs for at least the period your regulator or insurer requires.
• Large organisations: run redundant AAA servers in at least two locations, segment the AAA management network, put shared secrets in a vault, and integrate accounting with the SIEM and with identity governance so access reviews can use real usage data.

Implementing or modernising AAA: a phased approach

1. Inventory: list every NAS and AAA client (controllers, VPNs, switches, firewalls, routers), the protocol and port each uses, its shared secret age, and every local account on each device.
2. Fix the basics first: unique, long, random shared secrets per client (at least 32 characters for TACACS+); require Message-Authenticator on RADIUS; remove default and shared local accounts; restrict AAA traffic to known client addresses.
3. Define authorisation policy: map groups to privilege levels and command sets; give read-only by default and elevate per change. For network access, map device and user types to VLANs or access lists.
4. Turn on full accounting: start, interim and stop for network sessions; command and exec accounting for administrators; forward everything to central logging.
5. Pilot: move one site or one device class at a time. Keep a tested local break-glass account in a vault, with alerting on any use.
6. Protect transport: migrate to RADIUS/TLS or RADIUS/1.1 and TACACS+ over TLS as device support allows, disabling plaintext fallback once all clients are migrated.
7. Extend to machines: apply the same three questions to service accounts and API keys, replacing static secrets with federated workload identity.
8. Rollback plan: keep the previous AAA configuration and server addresses documented, test that devices fail to local authentication safely, and roll back one site at a time if authentication failures exceed your threshold.

Detection and measurement

Monitor: bursts of Access-Reject or TACACS+ authentication failures per user or source; successful logins from new source addresses; any use of local break-glass accounts; configuration changes to AAA server addresses or keys on devices; sessions with no stop record; and machine credentials used from unexpected networks (ATT&CK T1078 Valid Accounts).

Framework mapping

Common failure patterns

• AAA server and secrets treated as plumbing: in the Salt Typhoon telecom intrusions, the attackers captured TACACS and RADIUS shared keys to harvest more credentials and changed AAA and TACACS+ server addresses on devices to point at their own infrastructure. Alert on AAA configuration changes and keep secrets out of device configs that are backed up in clear.
• Weak local fallback accounts: the same intrusions decrypted weakly protected local passwords from exfiltrated configurations. Use strong hashing for local passwords and keep only a vaulted break-glass account.
• Authentication without MFA on remote access: the Change Healthcare breach began with stolen credentials on a Citrix portal that did not require MFA. If the VPN or portal authenticates through RADIUS, enforce MFA in the AAA policy, not only in the application.
• Accounting switched off or local only: logs that live on the device can be cleared, and many estates never enable interim or command accounting.
• Shared machine accounts: one service account used by many systems makes accounting useless and authorisation over-broad.
• Raw RADIUS across untrusted networks: MD5-protected UDP sent over the internet to a cloud or partner server, without TLS or IPsec.

Practitioner checklist

• Inventory every AAA client, protocol, port, shared secret and local account.
• Replace shared or short secrets with unique random secrets per client, stored in a vault.
• Require Message-Authenticator on all RADIUS exchanges that support it.
• Use TACACS+ with per-command authorisation and accounting for network device administration.
• Plan migration to RADIUS over TLS and TACACS+ over TLS 1.3, then disable plaintext fallback.
• Enforce MFA for remote access and administrative logins in the AAA policy.
• Forward all accounting to a central log store administrators cannot alter, and alert on AAA configuration changes.
• Give every service account, API key and workload a unique identity, an owner and a scoped permission set.
• Test break-glass and rollback procedures at least annually.

Standards and references

• IETF: RFC 2865 Remote Authentication Dial In User Service (RADIUS)
• IETF: RFC 2866 RADIUS Accounting
• IETF: RFC 8907 The TACACS+ Protocol
• IETF: RFC 9887 TACACS+ over TLS 1.3
• IETF: RFC 6733 Diameter Base Protocol
• IETF: RFC 9765 RADIUS/1.1, Leveraging ALPN to Remove MD5
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Authentication Guide · Authorisation Models Guide · Log Management and Retention Guide · Core Security Principles Guide · NHI Authentication Guide