How does the AAA framework work?

How AAA fits together in practice

AAA is not three separate security ideas, it is a control chain. Authentication establishes the actor, authorisation decides what that actor may do, and accounting preserves an evidence trail of the action. The framework works best when the three parts are designed together, because strong authentication without good authorisation still permits excess access, and strong access rules without accounting leave weak investigation and auditability.

The practical value of AAA is that it turns identity proof, permission checks, and activity records into one operating model. Authentication answers who; authorisation answers what is allowed; accounting answers what happened. In mature environments, each step informs the next, so privilege decisions are based on identity assurance, and logs are detailed enough to reconstruct user and system behaviour after an incident.

AAA is often implemented through IAM, access policy, session control, and log collection rather than by a single product. For a good mental model, the first two A’s govern access in real time, while the third A creates the retrospective record used for audit, detection, and incident response. IAM and IGA Basics is a useful foundation for seeing how authentication, authorisation, and governance connect across people and machines.

What each A does differently

Authentication is about proving identity. That can mean passwords, MFA, certificates, federated login, tokens, or service credentials, depending on the system and the actor. The security question is not just whether a login succeeds, but whether the assurance level is appropriate for the access being requested.

Authorisation is a separate decision point. A correctly authenticated user can still be blocked from sensitive functions, data, or administrative actions. This is where least privilege, role design, policy checks, and contextual rules matter most. Good authorisation design reduces blast radius by making access narrow, explicit, and reviewable. NIST Cybersecurity Framework 2.0 and NIST SP 800-207 Zero Trust Architecture both reinforce the principle that access should be verified continuously and constrained to what is actually needed.

Accounting is the record-keeping layer. It captures logins, administrative changes, approvals, access to sensitive records, and other material actions so teams can answer who did what, when, and from where. Without accounting, a security team may still block abuse, but it will struggle to prove impact, investigate misuse, or meet audit and legal expectations. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference point for the control areas that typically support this kind of visibility.

Where AAA breaks down and why defenders care

AAA fails when one layer is treated as enough on its own. Strong authentication does not stop privilege creep. Tight authorisation does not help if a shared account cannot be attributed. Detailed accounting does not prevent misuse if alerts are missing or logs are not retained long enough to be useful. The most common weakness is imbalance: organisations harden the login step but leave permissions too broad or auditing too shallow.

The other recurring failure is poor separation between human and system access. Interactive user access, service access, and delegated administrative access have different assurance and logging needs, even if they all sit under the same AAA label. That distinction matters because investigations often fail when logs cannot tell whether an action came from a person, a service, or an automated process.

AAA also has a scaling problem. As accounts, services, and integrations grow, authorisation drift and log volume both increase. If reviews are not routine, old privileges remain active and the accounting trail becomes noisy rather than useful. MITRE ATT&CK Enterprise Matrix is relevant here because many post-compromise techniques rely on credential access, privilege escalation, and later activity that defenders can only see if authentication, authorisation, and accounting are working together.

Practitioner Guidance

What to prioritise: Treat authorisation and accounting as first-class controls, not as afterthoughts behind authentication. If the account can authenticate but still reach too much, or if the action cannot be traced, AAA is functionally incomplete.

What to verify: Confirm that privileged and sensitive actions require stronger identity assurance, that permissions are scoped to actual job function, and that logs capture enough context to support investigation without depending on memory or manual reconstruction.

Common mistake: Teams often overfocus on login security and underinvest in entitlement hygiene and audit trails. That creates a system that looks secure at the front door but is still easy to abuse once inside.

Practitioner takeaway: AAA is most effective when each A has a distinct job, and when the three layers are reviewed together whenever access, privilege, or auditability changes.

Related resources from NHI Mgmt Group

• How does User Account Control (UAC) work?
• How does Credential Manager (Windows) work?
• How does Windows Remote Management (WinRM) work?
• How does MDM Containerization work?