Identification and Authentication (IA)¶

Domain: Identification and Authentication (IA)
Requirements in this domain: 11
Assessment Objectives in this domain: 25

IA.L2-3.5.1¶

IA.L2-3.5.1[a]¶

Assessment Objective

system users are identified.

Collection Approach: Document

Potential Evidence Examples

SSP, Account Management Policy, or SOP describing how each system user is uniquely identified, paired with a screen share of the AD/IAM directory showing unique usernames assigned to individuals (no shared human-user accounts).

Assessment Guide – Further Discussion

Are unique identifiers issued to individual users (e.g., usernames) [a]?

IA.L2-3.5.1[b]¶

Assessment Objective

processes acting on behalf of users are identified.

Collection Approach: Document

Potential Evidence Examples

SSP or Account Management SOP describing how processes acting on behalf of users (e.g., service accounts, scheduled jobs) are uniquely identified, paired with a screen share of the directory's service-account OU/group showing each is uniquely named and tracked.

Assessment Guide – Further Discussion

Are the processes and service accounts that an authorized user initiates identified (e.g., scripts, automatic updates, configuration updates, vulnerability scans) [b]?

IA.L2-3.5.1[c]¶

Assessment Objective

devices accessing the system are identified.

Collection Approach: Document

Potential Evidence Examples

SSP or Asset/Identity Management SOP describing how devices (workstations, servers, and network devices) are uniquely identified when accessing the system, paired with a screen share of domain-joined computer objects in AD and, for non-domain network devices, the mechanism used to uniquely identify them (e.g., NAC device profile, certificate, MAC binding).

Assessment Guide – Further Discussion

Are unique device identifiers used for devices that access the system identified [c]?

IA.L2-3.5.2¶

IA.L2-3.5.2[a]¶

Assessment Objective

the identity of each user is authenticated or verified as a prerequisite to system access.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share/log evidence showing the identity of a user is authenticated before access is granted — e.g., a successful login preceded by credential entry, plus an authentication-log entry showing both a successful login and a rejected login with invalid credentials.

Assessment Guide – Further Discussion

Are unique authenticators used to verify user identities (e.g., passwords) [a]?

IA.L2-3.5.2[b]¶

Assessment Objective

the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access.

Collection Approach: Screen Share

Potential Evidence Examples

Authentication log or screen share showing a service/process account (e.g., scheduled task, application service) must present valid credentials/certificates before it can access the system, with both a successful and unsuccessful attempt visible in the log.

Assessment Guide – Further Discussion

• An example of a process acting on behalf of users could be a script that logs in as a person or service account [b]. Can the contractor show that it maintains a record of all of those service accounts for use when reviewing log data or responding to an incident?
• Are user credentials authenticated in system processes (e.g., credentials binding, certificates, tokens) [b]?

IA.L2-3.5.2[c]¶

Assessment Objective

the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access.

Collection Approach: Screen Share

Potential Evidence Examples

Authentication log or screen share showing a device must authenticate (e.g., 802.1X, machine certificate, domain join) before being granted network/system access, including the device's MAC address/IP/hostname in the log entry.

Assessment Guide – Further Discussion

Are device identifiers used in authentication processes (e.g., MAC address, non-anonymous computer name, certificates) [c]?

IA.L2-3.5.3¶

IA.L2-3.5.3[a]¶

Assessment Objective

privileged accounts are identified.

Collection Approach: Document

Potential Evidence Examples

SSP or Privileged Account Policy defining what constitutes a privileged account, paired with a current export of privileged group membership from the directory (overlaps with AC.L2-3.1.5).

IA.L2-3.5.3[b]¶

Assessment Objective

multifactor authentication is implemented for local access to privileged accounts.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the MFA solution's policy configuration showing multifactor authentication is required for local (console/interactive) logon to privileged accounts, plus a live or recorded demonstration of an MFA challenge occurring at local privileged logon.

Assessment Guide – Further Discussion

Does the system uniquely identify and authenticate users, including privileged accounts [b,c,d]?

IA.L2-3.5.3[c]¶

Assessment Objective

multifactor authentication is implemented for network access to privileged accounts.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the MFA solution's policy configuration showing MFA is enforced for network-based access (e.g., RDP, VPN, application logon) to privileged accounts, with a demonstration of the MFA prompt during a network logon attempt.

Assessment Guide – Further Discussion

Does the system uniquely identify and authenticate users, including privileged accounts [b,c,d]?

IA.L2-3.5.3[d]¶

Assessment Objective

multifactor authentication is implemented for network access to non-privileged accounts.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the MFA solution's policy configuration showing MFA is enforced for network-based access to non-privileged (standard user) accounts, with a demonstration of the MFA prompt during a standard-user network logon.

Assessment Guide – Further Discussion

Does the system uniquely identify and authenticate users, including privileged accounts [b,c,d]?

IA.L2-3.5.4¶

IA.L2-3.5.4[a]¶

Assessment Objective

replay-resistant authentication mechanisms are implemented for all network account access to privileged and non-privileged accounts.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the GPO/Kerberos configuration enforcing replay-resistant authentication (e.g., Kerberos ticketing) for Windows network logons, and, for non-Windows systems or MFA solutions, the equivalent configuration (e.g., time-based OTP, challenge-response) demonstrating protection against authentication replay for both privileged and non-privileged network accounts.

Assessment Guide – Further Discussion

Are only anti-replay authentication mechanisms used [a]?

IA.L2-3.5.5¶

IA.L2-3.5.5[a]¶

Assessment Objective

a period within which identifiers cannot be reused is defined.

Collection Approach: Document

Potential Evidence Examples

SSP or Account Management Policy defining the minimum period during which a previously used identifier/username cannot be reassigned to a new user.

IA.L2-3.5.5[b]¶

Assessment Objective

reuse of identifiers is prevented within the defined period.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share or documented procedure (manual or scripted) showing the defined identifier non-reuse period is enforced when provisioning new accounts (e.g., naming-convention safeguard, historical username table check).

Assessment Guide – Further Discussion

• Are accounts uniquely assigned to employees, contractors, and subcontractors [b]?
• Are account identifiers reused [b]?

IA.L2-3.5.6¶

IA.L2-3.5.6[a]¶

Assessment Objective

a period of inactivity after which an identifier is disabled is defined.

Collection Approach: Document

Potential Evidence Examples

SSP or Account Management Policy defining the period of account inactivity after which an identifier/account is automatically disabled (e.g., 90 days without logon).

IA.L2-3.5.6[b]¶

Assessment Objective

identifiers are disabled after the defined period of inactivity.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of AD/IAM automated task, script, or GPO enforcing the defined inactivity threshold, or a report showing accounts disabled after exceeding the defined inactivity period.

Assessment Guide – Further Discussion

Are user accounts or identifiers monitored for inactivity [b]?

IA.L2-3.5.7¶

IA.L2-3.5.7[a]¶

Assessment Objective

password complexity requirements are defined.

Collection Approach: Document

Potential Evidence Examples

SSP or Password Policy defining minimum password complexity requirements (e.g., minimum length, character-type mix).

Assessment Guide – Further Discussion

Is a degree of complexity specified for passwords, (e.g., are account passwords a minimum of 12 characters and a mix of upper/lower case, numbers, and special characters), including minimum requirements for each type [a,b,c]?

IA.L2-3.5.7[b]¶

Assessment Objective

password change of character requirements are defined.

Collection Approach: Document

Potential Evidence Examples

SSP or Password Policy defining the minimum number of characters that must change between the old and new password.

Assessment Guide – Further Discussion

Is a degree of complexity specified for passwords, (e.g., are account passwords a minimum of 12 characters and a mix of upper/lower case, numbers, and special characters), including minimum requirements for each type [a,b,c]?

IA.L2-3.5.7[c]¶

Assessment Objective

minimum password complexity requirements as defined are enforced when new passwords are created.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the AD Default/Fine-Grained Password Policy (or equivalent directory/application setting) enforcing the defined complexity requirements at password creation.

Assessment Guide – Further Discussion

Is a degree of complexity specified for passwords, (e.g., are account passwords a minimum of 12 characters and a mix of upper/lower case, numbers, and special characters), including minimum requirements for each type [a,b,c]?

IA.L2-3.5.7[d]¶

Assessment Objective

minimum password change of character requirements as defined are enforced when new passwords are created.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the Group Policy/password-filter configuration enforcing the minimum-character-change requirement at password creation.

Assessment Guide – Further Discussion

Is a change of characters required when new passwords are created [d]?

IA.L2-3.5.8¶

IA.L2-3.5.8[a]¶

Assessment Objective

the number of generations during which a password cannot be reused is specified.

Collection Approach: Document

Potential Evidence Examples

SSP or Password Policy specifying the minimum password history (number of prior generations a password cannot be reused).

Assessment Guide – Further Discussion

How many generations of password changes need to take place before a password can be reused [a]?

IA.L2-3.5.8[b]¶

Assessment Objective

reuse of passwords is prohibited during the specified number of generations.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the AD Password Policy "Enforce Password History" setting (or equivalent) configured to the defined number of generations.

IA.L2-3.5.9¶

IA.L2-3.5.9[a]¶

Assessment Objective

an immediate change to a permanent password is required when a temporary password is used for system logon.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the "User must change password at next logon" setting (or equivalent) in AD/IAM showing temporary passwords force an immediate change to a permanent password at first logon.

Assessment Guide – Further Discussion

• Are temporary passwords only valid to allow a user to perform a password reset [a]?
• Does the system enforce an immediate password change after logon when a temporary password is issued [a]?

IA.L2-3.5.10¶

IA.L2-3.5.10[a]¶

Assessment Objective

passwords are cryptographically protected in storage.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the authentication protocol configuration (e.g., Kerberos enabled/enforced, NTLM disabled or restricted) showing passwords are cryptographically protected — hashed/encrypted, never stored in cleartext — at rest.

Assessment Guide – Further Discussion

• Are passwords prevented from being stored in reversible encryption form in any company systems [a]?
• Are passwords stored as one-way hashes constructed from passwords [a]?

IA.L2-3.5.10[b]¶

Assessment Objective

passwords are cryptographically protected in transit.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the authentication protocol/transport configuration (e.g., Kerberos, TLS-protected LDAP/LDAPS) showing passwords are cryptographically protected in transit rather than transmitted in cleartext.

IA.L2-3.5.11¶

IA.L2-3.5.11[a]¶

Assessment Objective

authentication information is obscured during the authentication process.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share/live demonstration of a login prompt showing password characters are masked/obscured (e.g., displayed as dots or asterisks) as they are typed.

Assessment Guide – Further Discussion

Is the feedback immediately obscured when the authentication is presented on a larger display (e.g., desktop or notebook computers with relatively large monitors) [a]?