9.1 Identification, Authentication, Authorization, and Accountability

The Four-Step Access Model

The ISC2 Certified in Cybersecurity (CC) exam draws the Access Controls Concepts domain (22 percent of the exam) heavily from one mental model: identification, authentication, authorization, and accountability (IAAA). These four steps happen in a fixed order, and the exam frequently hands you a one-sentence scenario and asks which step occurred. Memorize the order and the trigger words.

Identification is the act of claiming an identity. A user types a username, scans a badge number, enters an email address, or presents a smart-card certificate. The system has only heard a claim — nothing is proven. Because anyone can type a username, identification alone never grants access. The key phrase is "who you say you are."

Authentication verifies the claim by demanding evidence. That evidence falls into factor categories: something you know (password, PIN), something you have (token, smart card, authenticator app), and something you are (fingerprint, face). The phrase is "prove it." A failed identification is impossible — you can always type a name — but authentication is the gate that can reject you.

Authorization decides what the now-authenticated subject may do. It answers "what are you allowed to access?" A payroll clerk and a payroll supervisor may both authenticate, yet the clerk only enters timecard corrections while the supervisor approves the payroll batch. Authorization is enforced through permissions, roles, and access control models (DAC, MAC, RBAC, ABAC).

Accountability and Non-Repudiation

Accountability means an action can be traced to the responsible subject. It is not a single control but the result of several: unique user IDs, accurate and synchronized time stamps (NTP), tamper-resistant logs, monitoring, and non-repudiation — the inability of a subject to credibly deny having performed a logged action. Digital signatures and detailed audit trails support non-repudiation.

Shared accounts destroy accountability. If five administrators all sign in as root with one password, a log may show that "root" changed a firewall rule, but not which human did it. The fix is a unique account per person plus privileged-access tooling that records elevation.

A worked incident example

A terminated employee's account downloads files after their last day. Identification tells you which account was used. Authentication logs show whether a valid credential or live session was accepted. Authorization reveals what access that account still held. Accountability logs reconstruct what was touched, from where, and when. The root-cause control failure is usually delayed deprovisioning, excessive standing permissions, missing MFA, or weak monitoring.

Nonhuman subjects count too

A service account or an AI bot querying an internal knowledge base is also a subject requiring all four steps. It needs a clear owner, a documented purpose, least-privilege authorization, protected credentials, and logs. It must never run as an unnamed superuser. The current CC outline is effective October 1, 2025 (with a refreshed Job Task Analysis outline effective September 1, 2026). The exam moved to Computerized Adaptive Testing (CAT) on October 1, 2025: 100-125 items, 2 hours, 700 of 1000 to pass, five domains weighted 26 / 10 / 22 / 24 / 18 percent.

Ignore unofficial pass-rate claims; focus on recognizing the IAAA step in a scenario.

Subjects, Objects, and Why Order Matters

CC borrows two more terms from access control that pair with IAAA. A subject is the active entity requesting access — a user, process, service account, or bot. An object is the passive resource being accessed — a file, database row, API, or printer. IAAA is the lifecycle that connects a subject to the objects it is permitted to use. Reading a scenario, label the subject and object first; the question almost always hinges on whether the control acting between them is authentication (proving the subject) or authorization (limiting what it touches).

The ordering is strictly enforced and the exam exploits confusion about it. You cannot authorize before you authenticate, and you cannot meaningfully authenticate a claim that was never identified. A common distractor presents a permission decision and labels it "authentication," or presents a login prompt and labels it "authorization." Use these anchors:

• Username typed, badge tapped, certificate presented → identification.
• Password checked, MFA push approved, fingerprint matched → authentication.
• Role granted, file permission applied, firewall ACL evaluated → authorization.
• Log written, timestamp recorded, action attributed to a person → accountability.

Common traps the CC writers use

First, "identification = authentication" confusion. Entering a username is not authentication; only the proof step is. Second, single-factor masquerading as MFA: a password plus a security question is two knowledge items, so it is still one factor — covered in 9.2 but seeded here. Third, shared accounts and accountability: any scenario with "generic admin account" or "team mailbox" is steering you toward an accountability failure.

Fourth, logging without sync: logs from systems with unsynchronized clocks cannot be correlated during an investigation, so Network Time Protocol (NTP) synchronization is part of accountability, not a separate networking topic.

Finally, remember that IAAA is the backbone of the 22-percent Access Controls Concepts domain and threads into Security Operations (18 percent) through logging and monitoring. Mastering these four words and their order earns disproportionate points across the whole exam, because the same model reappears in physical access (badge = identification, PIN pad = authentication), network access, and data access scenarios alike.