Authentication, Authorisation & Accountability (AAA)

CyBOK Knowledge Area 14 · Level N2 (all Cyber Security students, both studios)

How you can use this topic (learning outcomes)

This topic supports the following learning outcomes, with example products you could deliver in your project:

Analysing & Advising — an advisory report for your project client on which authentication approach (passwords, MFA, "log in with...") fits their application and its risks.
Designing & Realising — a role-based access model designed and implemented in your project application, with MFA enabled and authorisation checked on every request.
Managing & Collaborating — an access-rights and logging agreement for your project team: who can change what in your repository, pipeline and cloud environment, and how you keep that traceable.

What is AAA and why should you care?

Every secure system has to answer three questions, in this order: Who are you? (authentication), What are you allowed to do? (authorisation), and What did you do? (accountability). Think of a hotel: you show your passport at the desk (authentication), your key card opens your room and the gym but not the manager's office (authorisation), and the system records which card opened which door at what time (accountability).

These three form a chain, and the chain is only as strong as its weakest link. If authentication fails, the system grants rights to the wrong person and the logs point to the wrong name. Almost every attack you will study later — from stolen credentials to privilege escalation — is an attack on this chain. AAA is foundational: the SOC monitoring and SIEM analysis you will meet in the Security Operations topics (BOKSA 8.x) are, at their core, organisations doing accountability at scale.

One warning about the acronym: outside CyBOK, "AAA" often means Authentication, Authorisation and Accounting (for example in network protocols such as RADIUS). In this topic, the third A is Accountability.

The three A's at a glance

Identification and authentication: claim, then prove

Identification is claiming who you are (typing your username); authentication is proving that claim (your password, your fingerprint). Proof comes in categories — something you know, something you have, something you are, or something you do — and real multi-factor authentication (MFA) combines factors from different categories: a password plus an authenticator app is MFA; a password plus a security question is not (both are things you know, and one phishing attack captures both). In modern applications you rarely build authentication yourself: protocols such as OAuth 2.0 / OpenID Connect, SAML and Kerberos let a trusted identity provider do the proving — this is why "Log in with Google" works on a site that never sees your password. Finally, identities have a lifecycle: they are created, they change, and — the step most often forgotten — they must be removed when someone leaves. Managing that lifecycle is called identity management.

Authorisation: least privilege, enforced on every request

Being logged in says nothing about what you may do. Authorisation is the policy (who may perform which action on which resource) plus the mechanism that enforces it. The golden rule is least privilege: grant exactly the rights a task needs, nothing more, and revoke rights that are no longer needed. In practice you organise rights with models such as RBAC (rights attached to roles, people assigned to roles) or ABAC (decisions based on attributes and context, such as time, location or department), and you enforce them through one central, unavoidable checkpoint — the reference monitor idea. The classic failure is checking whether someone is logged in but not what they may access: "Broken Access Control" has been the number-one risk in the OWASP Top 10 for web applications for four editions running.

Accountability: actions leave a trace

Accountability means actions can be traced back to a responsible identity. It rests on three things: an audit policy (decide beforehand what to log — logging everything drowns you in noise, logging nothing leaves you blind), protected evidence (attackers delete their tracks, so logs must be stored where a compromised system cannot reach them) and actual analysis (a log nobody reads proves nothing). Accountability is also in tension with privacy: the more you record about attackers, the more you record about your own legitimate users. At this level you need to understand these principles; building and analysing logging at scale is covered in the SOC/SIEM topics (BOKSA 8.x), and deeper techniques are in "Going deeper" below.

Starting points

Read — CyBOK Knowledge Area 14: Authentication, Authorisation & Accountability (Gollmann, v1.0.2) — the authoritative source this topic is based on.
Watch — CyBOK AAA webinar — the KA explained by the CyBOK team.
Listen — CyBOK AAA podcast — the same ground in audio form.
Read — NIST SP 800-63 Digital Identity Guidelines, Revision 4 (2025) — the current standard for password, MFA and identity-proofing policy; use this when you design or advise on authentication.
Read — OWASP Top 10:2025, A01 Broken Access Control — what authorisation failure looks like in real web applications, with prevention guidance you can apply directly in your project.
Study material in the knowledgebase — [TODO — !!!! Hier knowledgebase links neerzetten !!!]

Points of attention (check your own work)

Use these questions to check the quality of AAA in your project work:

Least privilege — Can every user, service account and API key in your project do only what it needs? Which rights did you consciously revoke or never grant?
Authorisation on every request — Does your application check server-side what this user may access on every request, not just whether someone is logged in? Test it: can user A reach user B's data by changing an ID in the URL?
Real MFA — If you offer multi-factor authentication, do the factors come from different categories (know / have / are / do)?
Don't build your own — Did you use a proven identity solution (OAuth 2.0/OpenID Connect, your platform's identity provider) instead of storing passwords yourself? If you must store passwords, do you follow NIST SP 800-63?
Identity lifecycle — What happens to accounts and rights when a team member leaves or a test account is no longer needed?
Traceability — If something went wrong in your application yesterday, could you tell who did what, and when? Are those logs stored out of reach of the account that caused the problem?
Assurance matches risk — Is the strength of your authentication proportional to what the application protects, and can you justify that choice to your client?

Going deeper (advanced)

Formal security models — Bell-LaPadula (confidentiality: no read up, no write down), Biba (integrity: no read down, no write up) and Clark-Wilson (well-formed transactions). The Harrison-Ruzzo-Ullman result shows that deciding whether a right can ever "leak" is undecidable in general — a warning about complex, dynamic policies.
Tamper-resistant logging — hash chains (altering one entry breaks the chain) and write-once, read-many (WORM) storage; how organisations make evidence hold up.
Biometrics trade-offs — the False Accept Rate vs. False Reject Rate balance, and why liveness detection matters.
Attribute-Based Encryption — enforcing access control directly on encrypted data in the cloud, and its efficiency limits when attributes change frequently.
Assurance levels — NIST SP 800-63-4 defines separate assurance levels for identity proofing (IAL), authentication (AAL) and federation (FAL); useful vocabulary when you advise on "how strong is strong enough".

Sources and attribution

Gollmann, D. (2021). Authentication, Authorisation & Accountability. CyBOK Knowledge Area v1.0.2.