Identification & Authentication

A username proves nothing. Treating that presented identifier as if it had authenticated someone is the single misread behind most wrong answers on this topic, because identification (claiming an identity) and authentication (proving the claim) are two ordered steps and the order is load-bearing. Everything downstream inherits the strength of that first proof: get authentication wrong and every authorization decision and every audit record is now confidently attributing actions to the wrong person.

Identification is the act of claiming an identity, presenting an identifier (a username, account number, employee ID) that the system already holds. It carries no trust on its own: an identifier is typically public, often guessable, and asserts nothing about who is really at the keyboard. Authentication is the act of proving that the claimed identity belongs to the subject, by presenting evidence the system can verify. The exam insists these are two ordered steps (you identify first, then authenticate) because a great deal of confusion in answer choices comes from treating a presented username as if it had authenticated anyone.

The AAA chain: who, what, and the record

Identification and authentication are the front of a longer sequence usually labeled AAA: authentication, authorization, and accounting. Authentication answers who the subject is. Authorization (owned by the Authorization Mechanisms subtopic) then decides what that proven subject may do, applying access-control models and least privilege. Accounting (also called auditing) is the logged record that ties each action back to the authenticated identity, which is what makes accountability, and ultimately non-repudiation, possible. The whole chain only holds if the first link is sound: if authentication is weak or an identifier is mistaken for proof, every downstream authorization decision and every audit record is attributing actions to the wrong person.

Keep the four verbs in order and distinct: identify (claim) → authenticate (prove) → authorize (permit) → account (record). Most trap answers on this topic swap two of these, offering an authorization concept when the stem is about proving identity, or calling a username an authentication step. The four verbs run left to right as one chain, each link inheriting the strength of the one before it.

This section covers the kinds of evidence authentication can use and the rule that decides when combining them counts as multi-factor. Read it before the biometrics and assurance-level sections, which build on these categories.

Three classic factors, two modern additions

Authentication evidence is grouped by the kind of thing it proves, and there are three classic categories:

• Something you know: a secret committed to memory: a password, PIN, or passphrase. NIST's neutral term is a memorized secret.
• Something you have: possession of a physical or cryptographic object: a smart card, an OTP token, a registered phone, or a FIDO2 security key (a possession factor).
• Something you are: a biometric, a physiological or behavioral trait: fingerprint, iris, face, or voice (an inherence factor).

Two further categories are commonly added but are weak as a sole factor: somewhere you are (geolocation or network context, useful as a risk signal in adaptive authentication, not as standalone proof) and something you do (behavioral biometrics such as keystroke dynamics or gait).

The category rule defines multi-factor, not the count of secrets

Multi-factor authentication (MFA) requires evidence drawn from two or more different categories above. This is the single most-tested distinction in the subtopic, and it is a frequent misread, so state it plainly: stacking two secrets of the same category is still single-factor. A password plus a security question is two pieces of "something you know", single-factor. A password plus a one-time code from a possession device is "know" + "have", genuinely two-factor. The exam dangles "two passwords" or "password + PIN" as a tempting MFA answer precisely because candidates count secrets instead of categories.

Why each factor fails differently

The categories matter because they fail in different ways, and a security leader chooses a combination so that one breach does not defeat the whole login. Knowledge factors are phished, guessed, reused across sites, and shared. Possession factors are lost, stolen, or (for weaker tokens) cloned. Inherence factors carry a unique liability: a biometric template, once compromised, cannot be revoked or reissued the way a password or token can, because you cannot change your fingerprint. That irrevocability is why biometrics are usually paired with a possession factor (e.g. a fingerprint that unlocks a key on a device) rather than used as the sole credential. The figure groups the three classic categories together and the two weaker modern ones apart, with the multi-factor rule stated beneath them.

This section explains how biometric systems are measured and which error a security professional treats as the dangerous one. It assumes the factor categories from the previous section.

Two error types that trade off against each other

A biometric matcher compares a presented sample to a stored template and decides match or no-match against a tunable threshold. It can be wrong in two opposite ways, and the CISSP labels both with a Type number and a rate:

• A false accept (an impostor is matched to someone else's template and let in). This is the Type II error, measured as the False Acceptance Rate (FAR). NIST's modern equivalent term is the false match rate (FMR), "the proportion of zero-effort impostor attempt samples falsely declared to match the compared non-self template" (NIST SP 800-140E, via CSRC glossary^[1]).
• A false reject (a legitimate enrolled user is wrongly denied). This is the Type I error, measured as the False Rejection Rate (FRR) (NIST: false non-match rate).

The two are linked by the threshold and move in opposite directions: tighten the matcher and FAR falls but FRR rises (more legitimate users are turned away); loosen it and FRR falls but FAR rises (more impostors slip in). You cannot minimize both at once on a fixed system: you choose where on the curve to sit.

The crossover error rate is the single comparison number

Because FAR and FRR depend on the threshold you pick, you cannot compare two systems by quoting one rate. The comparison metric is the Crossover Error Rate (CER), also called the Equal Error Rate (EER): the threshold setting at which FAR and FRR are equal. The lower a system's CER, the more accurate it is overall, independent of how any one deployment is tuned. When a question asks which of two biometric systems is more accurate, the answer is the one with the lower CER.

Which error matters for security

The two errors are not equally serious. A false reject (Type I/FRR) is an inconvenience: a valid user retries or falls back to a help desk. A false accept (Type II/FAR) is a security breach: an impostor has been authenticated as someone else. So when a deployment is tuned, a security-conscious setting accepts a somewhat higher FRR to keep FAR low; tuning the system to stop annoying users (driving FRR to zero) by loosening the threshold raises FAR and is the wrong call for a high-security gate. A separate enrollment metric, the failure-to-enroll rate (FER), measures users whose trait cannot be captured well enough to enroll at all (e.g. worn fingerprints), a usability and inclusivity concern distinct from the two matching errors.

This section covers what happens before a credential exists and what governs its strength, drawing on the NIST SP 800-63 digital-identity model. Read it after the factor types, because assurance levels are expressed in terms of factors.

Identity proofing comes first, and is graded as IAL

Before any authenticator is bound to a person, the identity must be established. Identity proofing (the establishment step within enrollment, and loosely called registration) is that establishment, and NIST SP 800-63A breaks it into three steps: resolution ("uniquely distinguish an individual within a given population or context"); validation (collect appropriate identity evidence and "determine its authenticity, validity, and accuracy" against the issuing or an authoritative source); and verification ("confirm and establish a linkage between the claimed identity and the real-life existence of the subject presenting the evidence," e.g. by biometric or physical comparison) (NIST SP 800-63A^[2]). The rigor of proofing is the Identity Assurance Level (IAL): IAL1 attributes are self-asserted with no evidence; IAL2 requires validated evidence collected remotely or in person; IAL3 requires in-person (or supervised-remote) proofing by an authorized representative (NIST SP 800-63-3^[3]).

Authentication strength is graded separately as AAL

How strongly the login proves possession of the authenticator is the Authenticator Assurance Level (AAL), defined in NIST SP 800-63B. AAL1 permits single-factor authentication; AAL2 requires two distinct factors and approved cryptography; AAL3 requires a hardware-based authenticator and verifier-impersonation (phishing) resistance, demonstrated by proof of possession of a key through a cryptographic protocol (NIST SP 800-63B^[4]). The exam-critical point, and a deliberate trap, is that IAL and AAL are independent: a self-asserted IAL1 account can still require AAL2 login, and an IAL3-proofed identity can be issued an AAL1 credential. A security leader sets each from the risk of the transaction, never assuming one implies the other.

Modern NIST guidance overturns two old password habits

Two legacy "best practices" are now explicitly discouraged by NIST, and the exam has begun to reflect this. First, do not force periodic password expiry: verifiers "SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)," but SHALL force a change on evidence of compromise. Second, do not impose composition rules (mandatory mixed character classes); instead, check candidate passwords against lists of known-compromised secrets and allow long passphrases (NIST SP 800-63B^[4]). NIST also classifies SMS / PSTN-delivered one-time codes as a RESTRICTED authenticator because of SIM-swap and number-porting risk: usable, but the verifier must warn subscribers and offer a non-restricted alternative.

Credential management and just-in-time issuance

A credential management system governs the full lifecycle of authenticators: issuance, binding to a proofed identity, renewal, rotation, suspension, and revocation. The lifecycle principle a leader applies is to minimize standing credentials: just-in-time (JIT) provisioning grants access only at the moment of need and for a bounded time, so there is no long-lived privileged credential sitting idle to be stolen. JIT is most valuable for privileged or rarely-used access, where a standing administrator credential is a high-value, always-available target. The proofing steps run in order (resolution, then validation, then verification) before any authenticator is bound, as the figure shows.

This section covers what happens after a successful authentication (how a single proof is reused and how long it stays valid) plus the passwordless model that is reshaping the factor mix. It assumes the AAL levels from the previous section.

Single sign-on: one authentication, many systems

Single sign-on (SSO) lets a user authenticate once to a central authority and then reach many connected applications without re-presenting credentials. Its benefits are real: less password fatigue (so fewer reused or written-down passwords), one place to enforce MFA, and one switch to disable an account everywhere on termination. Its risk is concentration of blast radius: a stolen SSO session is access to every connected system at once. That single trade-off is why SSO is always paired with strong authentication at the identity provider and with disciplined session controls: it raises the value of compromising that one login. (The protocols that carry SSO assertions, SAML, OIDC/OAuth, and the cross-organization trust they enable belong to the Authentication Systems and Federated Identity subtopics; this subtopic owns the strategy, not the wire format.)

Session management bounds how long a proof lasts

A successful authentication produces a session, and a session must not live forever: a long-lived session is an authentication that can be hijacked long after the user walked away. NIST SP 800-63B sets concrete bounds tied to AAL: at AAL2, reauthenticate at least every 12 hours regardless of activity and after 30 minutes of inactivity (a single factor MAY be used to resume); at AAL3, the inactivity limit tightens to 15 minutes and resuming the session SHALL use both factors (NIST SP 800-63B^[4]). Beyond timeouts, sound session management means binding the session to the authenticated subject, regenerating the session identifier on privilege change, and invalidating the session server-side on logout, so that ending a session actually ends it.

Passwordless and FIDO2 remove the most-attacked factor

Passwordless authentication eliminates the memorized secret, replacing it with a possession factor: a cryptographic key in a hardware authenticator or device secure element, typically unlocked locally by a biometric or PIN (so the biometric authorizes local use of the key and never travels). The canonical standard is FIDO2 / WebAuthn: the authenticator holds a private key that never leaves it, and each credential is bound to a specific relying-party origin. Because the signature only validates for the real origin, a credential captured on a look-alike phishing site cannot be replayed against the genuine site: this origin-binding is exactly the verifier-impersonation resistance NIST requires at AAL3. The decision a leader weighs is removing the reusable password (the factor behind most credential-theft and phishing breaches) against the operational cost of provisioning hardware authenticators and handling their loss and recovery.

This section maps question shapes to the right answer. Read the others first; this is the pattern layer.

Pattern 1: "Is this multi-factor?" Count categories, not secrets. Password + security question, or password + PIN, are both "something you know" → single-factor (the classic trap answer dressed up as MFA). Password + OTP token, or PIN + smart card, cross categories → genuine MFA. The distractor always offers two same-category secrets and calls them two factors.

Pattern 2: "Which biometric error / which is more accurate?" A false accept (impostor admitted) is the Type II error / FAR and is the security-critical one; a false reject is Type I / FRR, merely an inconvenience. "Which system is more accurate?" → the one with the lower CER (Crossover/Equal Error Rate) (NIST glossary^[1]). Traps: swapping Type I/II, or claiming a low FRR alone proves accuracy (it doesn't; only CER compares systems independent of tuning).

Pattern 3: "Identification vs authentication vs authorization." A presented username/ID is identification (a claim), not authentication; proving the claim is authentication; deciding what the proven subject may do is authorization. Stems describing "the user entered their username" and asking what just happened → identification. The trap calls the username step authentication.

Pattern 4: IAL vs AAL independence. Proofing rigor = IAL (SP 800-63A); login strength = AAL (SP 800-63B); they are set independently (NIST SP 800-63-3^[3]). A stem implying that strong login (AAL3) guarantees a well-proofed identity (IAL3), or vice versa, is the trap: strong authentication of a weakly-proofed account just confidently authenticates the wrong person.

Pattern 5: phishing-resistant / AAL3. A requirement for resistance to credential phishing or verifier impersonation points to a hardware authenticator with FIDO2/WebAuthn origin-binding, the AAL3 profile (NIST SP 800-63B^[4]). SMS one-time codes are the wrong answer here: NIST classifies PSTN/SMS delivery as a RESTRICTED authenticator (SIM-swap risk), and it offers no phishing resistance.

Pattern 6: modern password policy. When a stem asks for the BEST password practice, the NIST-aligned answer is to screen against breached-password lists and stop forcing periodic expiry / composition rules (NIST SP 800-63B^[4]). The trap is the old habit, "require 90-day rotation" or "mandate mixed character classes," which NIST now advises against absent evidence of compromise.

Pattern 7: SSO benefit vs risk. SSO's benefit is centralized authentication and reduced password fatigue; its risk is a single compromised session reaching every connected system. A stem listing SSO's downside is testing that concentration-of-risk idea, not a protocol detail (those belong to Authentication Systems).