What is AAA security? Authentication, authorization, accounting

AAA stands for authentication, authorization and accounting. Authentication proves who a user or device is. Authorization decides what that identity may do. Accounting records what it did. Keeping the three separate lets you change one without breaking the others, and it gives you a trail to audit.

What are the three parts?

RFC 2903, an experimental IETF memo on a generic AAA architecture, describes AAA functions as authenticating a user, authorizing a request and generating accounting information about the authorization decision and the session that follows. The accounting record represents the ongoing consumption of the services or resources.

In plain words:

• Authentication: are you really Dana from the network team?
• Authorization: may Dana change the firewall policy, or only read it?
• Accounting: Dana logged in at this time, ran these commands, and left.

Many failures come from blurring them. A team that authenticates well but gives every logged in admin full rights has no authorization. A team that grants fine rights but keeps no records cannot prove what happened.

How does it work on a real network?

RADIUS, defined in RFC 2865, is the best known protocol for this job. Its abstract describes it as carrying authentication, authorization and configuration information between a network access server and a shared authentication server.

Constructed example: an engineer connects to a switch to change a VLAN. The switch is the network access server. It sends an Access-Request to the RADIUS server with the user name and password. The server replies with Access-Accept or Access-Reject, or an Access-Challenge when more proof is needed. The Accept can carry attributes, such as which privilege level to grant. That reply is the authorization step. Later, accounting messages record the session.

RFC 2865 also notes that the client and the server authenticate each other through a shared secret that is never sent over the network, and that user passwords are sent encrypted between them. The shared secret is a real operational burden: if it leaks, anyone who can reach the server may forge requests, so rotate and scope it per device group.

Where does AAA show up outside network gear?

The same three questions apply to cloud consoles, databases, SSH bastions, APIs and AI agents. The mapping is loose:

1. Authentication: a sign in with a password plus a second factor, or a certificate, or a token.
2. Authorization: roles, policies and scopes.
3. Accounting: audit logs and access reports.

HIPAA's technical safeguards are a good example outside networking. The regulation lists person or entity authentication, access control and audit controls as separate standards, which is the AAA split written as law.

What goes wrong in practice?

• Shared accounts break authentication because the log cannot say who acted.
• Authorization granted once and never reviewed grows into broad standing access.
• Accounting data stored on the same device an attacker controls can be edited. Ship logs to a separate system.
• Local fallback accounts keep working when the AAA server is down, and attackers know it.

How to check or apply this

1. List the systems that administrators log into, and note how each one authenticates.
2. For each, write down what authorization model it uses. If the answer is one role for everyone, fix that.
3. Confirm every system sends accounting or audit records to a central place with its own access controls.
4. Remove shared accounts. Where a break glass account is needed, vault it and alert on use.
5. Review authorization quarterly and remove rights nobody uses.
6. Test the failure case: what happens when the AAA server is unreachable?

How does AAA connect to compliance?

Auditors rarely say AAA, but they ask its three questions: how do you know who accessed this system, what were they allowed to do, and where is the record. Frameworks and regulations phrase it as identity management, access control and audit logging. If you can show a central identity source, a documented role model and retained, protected logs for each system in scope, you have answered most of those questions with evidence rather than with promises.

Quick check

Sources

• RFC 2903, Generic AAA Architecture
• RFC 2865, Remote Authentication Dial In User Service (RADIUS)
• 45 CFR 164.312, Technical safeguards

Last reviewed: 18 October 2026.