Authentication, authorisation, and accounting is an access-control model where a user proves identity, receives permitted access, and has activity recorded. Authentication checks who they are, authorisation decides what they can do, and accounting logs what they did. Defenders use it to enforce least privilege, support auditing, and investigate misuse through reliable session records.
How the AAA model separates login, permission, and logging
AAA is easiest to understand as a sequence, not as one single control. Authentication establishes that the caller is legitimate, authorisation narrows what that caller can do, and accounting records the resulting actions so they can be reviewed later. The model is common in network access, remote access, and administrative systems because it supports both enforcement and traceability.
The three parts solve different problems, and they fail differently. Authentication is about proof of identity, usually through a password, certificate, token, or federated assertion. Authorisation turns that identity into allowed actions, often through roles, policies, scopes, or entitlements. Accounting creates records of access, commands, data changes, and session events so defenders can investigate abnormal use and reconstruct what happened.
In practice, the value of AAA comes from the handoff between those steps. A strong login mechanism is weak if the session is over-permissioned. Tight permissions are weak if the system cannot record who did what and when. Good accounting is also not enough if authentication is flawed, because a recorded session may still belong to an attacker using valid access. The model is therefore as much about control boundaries as it is about individual mechanisms.
Where AAA is usually implemented and how the layers interact
AAA appears in VPNs, wireless access, privileged admin portals, identity providers, application gateways, and API access layers. In some environments the authentication step is centralised, while authorisation is evaluated inside the application or against a policy engine. Accounting may be written to a SIEM, a log platform, or an audit trail that supports incident response and compliance review.
The interaction matters because each layer can be distributed differently. A user may authenticate once through SSO, receive a token, and then hit several downstream services that each apply their own authorisation checks. If those services do not keep reliable logs, defenders can lose the ability to distinguish legitimate use from abuse. That is why IAM and IGA Basics is useful background for the broader access-governance side of the model, especially where roles, entitlements, and reviews determine what authorisation really means.
Because AAA is often embedded in remote access and operational tooling, its security impact can be larger than the interface it sits on. A weak authentication control on an admin path can expose the whole environment, while a weak accounting trail can hide misuse long enough for privilege escalation or lateral movement. That is why the model is usually treated as an access-control pattern, not just a login feature.
What reliable AAA looks like in a real environment
A useful implementation has clear separation between identity verification, permission decision, and audit logging. Authentication should be resistant to password guessing, phishing, or token replay where the risk justifies stronger methods. Authorisation should be narrowly scoped and rechecked when context changes. Accounting should produce logs that are complete enough to support incident analysis, not merely to satisfy checkbox compliance.
Good practice also means keeping the records useful after the fact. Logs should include the authenticated subject, the resource accessed, the decision outcome, and the action taken. Where possible, defenders should preserve enough detail to answer who, what, when, and from where without relying on fragile memory or manual reconstruction. For teams dealing with stronger sign-in controls, Workforce Identity Security Guide and the NIST SP 800-63 Digital Identity Guidelines both help frame the authentication side of the problem.
Risk and Threat Considerations
AAA fails most often when organisations assume the login step proves enough. Attackers frequently try to reuse valid credentials, hijack sessions, or abuse overbroad permissions after they get in. If accounting is weak, those actions may blend into normal usage and delay detection.
Failure mechanism: Authentication can be bypassed or abused, authorisation can be too broad or inconsistently enforced, and accounting can miss the trail that proves misuse or scope of access.
Impact: The result is account takeover, unauthorised actions, poor incident reconstruction, and a larger blast radius when one identity or session is compromised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Authentication assurance and session trust are central to AAA. |
| Recommendation — Apply NIST 800-63 to strengthen authentication and session assurance for access decisions. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | AAA depends on verifying organizational users before access is granted. |
| AC-6 — Least Privilege | Authorisation in AAA should restrict what authenticated users can do. | |
| AU-2 — Event Logging | Accounting in AAA requires audit events that capture use and misuse. | |
| Recommendation — Use IA-2 to authenticate users before granting access. Apply AC-6 to limit each identity to the minimum required privilege. Use AU-2 to define audit events that must be recorded. | ||
| OWASP ASVS | V6 — Authentication | AAA includes authentication requirements for applications and web services. |
| V8 — Authorization | AAA relies on enforcing access decisions after authentication. | |
| V16 — Security Logging and Error Handling | AAA accounting depends on usable logs and audit trails. | |
| Recommendation — Use V6 to verify authentication strength and resistance to abuse. Use V8 to verify that authorisation checks are enforced consistently. Use V16 to verify that security-relevant actions are logged reliably. | ||
Practitioner Guidance
What to verify: Check that authentication, authorisation, and accounting are implemented as separate controls, not as one blended login workflow. If the same session token is trusted everywhere, confirm where it is revalidated and where permission checks actually occur.
Decision rule: If a system can perform sensitive actions after a single sign-in, treat authorisation depth and logging quality as first-order controls, not secondary features. If the session can be replayed or reused across services, prioritise session protection and audit fidelity before expanding functionality.
Practitioner takeaway: AAA is only effective when each layer stands on its own, authentication proves the actor, authorisation constrains the action, and accounting leaves a trustworthy record when either of the first two fails.
Related resources from NHI Mgmt Group
- Why is it crucial to adopt new authentication methods in MCP usage?
- How do OAuth 2.0 and OpenID Connect authentication and authorisation flows work?
- What is the difference between agent authentication and agent authorisation?
- Why do identity verification and passwordless authentication need to work together?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org