Authentication, Authorization, Accountability, and Non-Repudiation

Identity Concepts in Order

Access decisions get easier when you keep four ideas separate: identification, authentication, authorization, and accountability. They happen together in one login flow but do different jobs.

Identification is the claim of identity. A username, employee ID, email address, or badge number says who the subject claims to be. Identification proves nothing on its own.

Authentication proves that claim using one or more of five factor categories. Memorize them, because the CC exam tests them directly:

Multifactor authentication (MFA) combines factors from DIFFERENT categories. A password plus an authenticator app code is true MFA. Two passwords, or a password plus a security question, are both "something you know" and therefore still single-factor. This is the most common MFA trap on the exam.

Authorization and Accountability

Authorization happens after identity is established. It answers "what is this user, service, or device allowed to do?" A payroll clerk may authenticate successfully yet still must not administer firewalls. Authorization should follow least privilege (grant only what the role needs), use role-based access control (RBAC) where appropriate, and be reviewed periodically. A key principle is separation of duties: a system administrator should not approve their own privileged-access request.

Accountability means actions can be traced to the responsible subject. It rests on four pillars: unique user accounts, comprehensive logging, accurate and synchronized timestamps, and a review process. Synchronized time matters because logs from different systems must line up during an investigation; the Network Time Protocol (NTP) keeps clocks aligned. Shared administrator accounts destroy accountability because no one can prove who acted.

Non-repudiation provides evidence that an action or message truly came from a specific party and was not altered, so the party cannot credibly deny it. A digital signature is the classic example: a user signs a transaction with their private key, and anyone can validate it with the matching public key. Note the exam distinction: logs support accountability, but non-repudiation needs cryptographic strength tied to a unique identity. "We have logs" is weaker than "we have a validated digital signature."

Scenario: The Shared Admin Password

A small company keeps one administrator password in a notebook, and the whole IT team uses it during outages. It feels efficient but breaks several principles at once.

The better recommendation: use named administrative accounts, grant only needed privileges, require MFA, log privileged actions, and protect emergency access through a controlled break-glass process (a sealed, monitored, single-use credential).

Access Decision Examples

The CC exam uses ordinary workplace requests to test identity control. The fastest answer is rarely the best. The best answer proves identity, limits permissions to need, and leaves a reviewable record. When two options both "work," pick the one that preserves unique accountability.

AAA, Provisioning, and Common Traps

The industry often bundles three of these ideas as AAA: Authentication, Authorization, and Accounting (accounting is the logging side of accountability). The CC exam expects you to keep the boundaries crisp.

Provisioning identities has a lifecycle the exam references: an account is provisioned on hire, modified when a role changes, and deprovisioned promptly on termination. A frequent trap is the forgotten account, when an employee transfers departments but keeps old permissions, building up privilege creep that violates least privilege. Periodic access reviews catch this.

Two more distinctions worth memorizing. First, authentication is not the same as encryption: a password proves identity but does not by itself protect data in transit. Second, biometrics are convenient but probabilistic; they have false acceptance and false rejection rates, so they are best used as one factor in MFA, not as a sole gate to high-risk systems. When a scenario offers "add a second different factor" versus "make the password longer," the second-factor answer is stronger because it changes the factor category rather than hardening one already-compromised category.