IA-2 Identification and Authentication (Organizational Users)

Guidance: draftPolicy clause: draftWhat these mean

Baselines	Implementation level	Enhancements
Low, Moderate, High	Organization	8 (5 in a baseline)

Related controls: AC-2, AC-3, AC-4, AC-14, AC-17, AC-18, AU-1, AU-6, IA-4, IA-5, IA-8, IA-13, MA-4, MA-5, PE-2, PL-4, SA-4, SA-8

Control statement

Uniquely identify and authenticate organizational users and associate that unique identification with processes acting on behalf of those users.

NIST discussion

Organizations can satisfy the identification and authentication requirements by complying with the requirements in HSPD 12 . Organizational users include employees or individuals who organizations consider to have an equivalent status to employees (e.g., contractors and guest researchers). Unique identification and authentication of users applies to all accesses other than those that are explicitly identified in AC-14 and that occur through the authorized use of group authenticators without individual authentication. Since processes execute on behalf of groups and roles, organizations may require unique identification of individuals in group accounts or for detailed accountability of individual activity.

Organizations employ passwords, physical authenticators, or biometrics to authenticate user identities or, in the case of multi-factor authentication, some combination thereof. Access to organizational systems is defined as either local access or network access. Local access is any access to organizational systems by users or processes acting on behalf of users, where access is obtained through direct connections without the use of networks. Network access is access to organizational systems by users (or processes acting on behalf of users) where access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks. Internal networks include local area networks and wide area networks.

The use of encrypted virtual private networks for network connections between organization-controlled endpoints and non-organization-controlled endpoints may be treated as internal networks with respect to protecting the confidentiality and integrity of information traversing the network. Identification and authentication requirements for non-organizational users are described in IA-8.

Control enhancements

IA-2(1) Multi-factor Authentication to Privileged Accounts

Baselines: Low, Moderate, High

Implement multi-factor authentication for access to privileged accounts.

Discussion and assessment objectives for IA-2(1)

Multi-factor authentication requires the use of two or more different factors to achieve authentication. The authentication factors are defined as follows: something you know (e.g., a personal identification number [PIN]), something you have (e.g., a physical authenticator such as a cryptographic private key), or something you are (e.g., a biometric). Multi-factor authentication solutions that feature physical authenticators include hardware authenticators that provide time-based or challenge-response outputs and smart cards such as the U.S. Government Personal Identity Verification (PIV) card or the Department of Defense (DoD) Common Access Card (CAC). In addition to authenticating users at the system level (i.e., at logon), organizations may employ authentication mechanisms at the application level, at their discretion, to provide increased security. Regardless of the type of access (i.e., local, network, remote), privileged accounts are authenticated using multi-factor options appropriate for the level of risk. Organizations can add additional security measures, such as additional or more rigorous authentication mechanisms, for specific types of access.

Determine if multi-factor authentication is implemented for access to privileged accounts.

Examine: Identification and authentication policy; procedures addressing user identification and authentication; system security plan; system design documentation; system configuration settings and associated documentation; system audit records; list of system accounts; other relevant documents or records.

Interview: Organizational personnel with system operations responsibilities; organizational personnel with account management responsibilities; organizational personnel with information security responsibilities; system/network administrators; system developers.

Test: Mechanisms supporting and/or implementing a multi-factor authentication capability.

IA-2(2) Multi-factor Authentication to Non-privileged Accounts

Baselines: Low, Moderate, High

Implement multi-factor authentication for access to non-privileged accounts.

Discussion and assessment objectives for IA-2(2)

Multi-factor authentication requires the use of two or more different factors to achieve authentication. The authentication factors are defined as follows: something you know (e.g., a personal identification number [PIN]), something you have (e.g., a physical authenticator such as a cryptographic private key), or something you are (e.g., a biometric). Multi-factor authentication solutions that feature physical authenticators include hardware authenticators that provide time-based or challenge-response outputs and smart cards such as the U.S. Government Personal Identity Verification card or the DoD Common Access Card. In addition to authenticating users at the system level, organizations may also employ authentication mechanisms at the application level, at their discretion, to provide increased information security. Regardless of the type of access (i.e., local, network, remote), non-privileged accounts are authenticated using multi-factor options appropriate for the level of risk. Organizations can provide additional security measures, such as additional or more rigorous authentication mechanisms, for specific types of access.

Determine if multi-factor authentication for access to non-privileged accounts is implemented.

Examine: Identification and authentication policy; system security plan; procedures addressing user identification and authentication; system design documentation; system configuration settings and associated documentation; system audit records; list of system accounts; other relevant documents or records.

Interview: Organizational personnel with system operations responsibilities; organizational personnel with account management responsibilities; organizational personnel with information security responsibilities; system/network administrators; system developers.

Test: Mechanisms supporting and/or implementing a multi-factor authentication capability.

IA-2(5) Individual Authentication with Group Authentication

Baselines: High

When shared accounts or authenticators are employed, require users to be individually authenticated before granting access to the shared accounts or resources.

Discussion and assessment objectives for IA-2(5)

Individual authentication prior to shared group authentication mitigates the risk of using group accounts or authenticators.

Determine if users are required to be individually authenticated before granting access to the shared accounts or resources when shared accounts or authenticators are employed.

Examine: Identification and authentication policy; system security plan; procedures addressing user identification and authentication; system design documentation; system configuration settings and associated documentation; system audit records; list of system accounts; other relevant documents or records.

Interview: Organizational personnel with system operations responsibilities; organizational personnel with account management responsibilities; organizational personnel with information security responsibilities; system/network administrators; system developers.

Test: Mechanisms supporting and/or implementing an authentication capability for group accounts.

IA-2(6) Access to Accounts —separate Device

Baselines: Not in a baseline

Implement multi-factor authentication for [Selection (one or more): local; network; remote] access to [Selection (one or more): privileged accounts; non-privileged accounts] such that:

• (a) One of the factors is provided by a device separate from the system gaining access; and
• (b) The device meets [Assignment: organization-defined strength of mechanism requirements].

Discussion and assessment objectives for IA-2(6)

The purpose of requiring a device that is separate from the system to which the user is attempting to gain access for one of the factors during multi-factor authentication is to reduce the likelihood of compromising authenticators or credentials stored on the system. Adversaries may be able to compromise such authenticators or credentials and subsequently impersonate authorized users. Implementing one of the factors on a separate device (e.g., a hardware token), provides a greater strength of mechanism and an increased level of assurance in the authentication process.

Determine if:

• IA-02(06)(a) multi-factor authentication is implemented for [Selection (one or more): local; network; remote] access to [Selection (one or more): privileged accounts; non-privileged accounts] such that one of the factors is provided by a device separate from the system gaining access;
• IA-02(06)(b) multi-factor authentication is implemented for [Selection (one or more): local; network; remote] access to [Selection (one or more): privileged accounts; non-privileged accounts] such that the device meets [Assignment: organization-defined strength of mechanism requirements].

Examine: Identification and authentication policy; system security plan; procedures addressing user identification and authentication; system design documentation; system configuration settings and associated documentation; system audit records; list of system accounts; other relevant documents or records.

Interview: Organizational personnel with system operations responsibilities; organizational personnel with account management responsibilities; organizational personnel with information security responsibilities; system/network administrators; system developers.

Test: Mechanisms supporting and/or implementing multi-factor authentication capability.

IA-2(8) Access to Accounts — Replay Resistant

Baselines: Low, Moderate, High

Implement replay-resistant authentication mechanisms for access to [Selection (one or more): privileged accounts; non-privileged accounts].

Discussion and assessment objectives for IA-2(8)

Authentication processes resist replay attacks if it is impractical to achieve successful authentications by replaying previous authentication messages. Replay-resistant techniques include protocols that use nonces or challenges such as time synchronous or cryptographic authenticators.

Determine if replay-resistant authentication mechanisms for access to [Selection (one or more): privileged accounts; non-privileged accounts] are implemented.

Examine: Identification and authentication policy; system security plan; procedures addressing user identification and authentication; system design documentation; system configuration settings and associated documentation; system audit records; list of privileged system accounts; other relevant documents or records.

Interview: Organizational personnel with system operations responsibilities; organizational personnel with account management responsibilities; organizational personnel with information security responsibilities; system/network administrators; system developers.

Test: Mechanisms supporting and/or implementing identification and authentication capabilities; Mechanisms supporting and/or implementing replay-resistant authentication mechanisms.

IA-2(10) Single Sign-on

Baselines: Not in a baseline

Provide a single sign-on capability for [Assignment: organization-defined system accounts and services].

Discussion and assessment objectives for IA-2(10)

Single sign-on enables users to log in once and gain access to multiple system resources. Organizations consider the operational efficiencies provided by single sign-on capabilities with the risk introduced by allowing access to multiple systems via a single authentication event. Single sign-on can present opportunities to improve system security, for example by providing the ability to add multi-factor authentication for applications and systems (existing and new) that may not be able to natively support multi-factor authentication.

Determine if a single sign-on capability is provided for [Assignment: organization-defined system accounts and services].

Examine: Identification and authentication policy; system security plan; procedures addressing single sign-on capability for system accounts and services; procedures addressing identification and authentication; system design documentation; system configuration settings and associated documentation; system audit records; list of system accounts and services requiring single sign-on capability; other relevant documents or records.

Interview: Organizational personnel with system operations responsibilities; organizational personnel with account management responsibilities; organizational personnel with information security responsibilities; system/network administrators; system developers.

Test: Mechanisms supporting and/or implementing identification and authentication capabilities; mechanisms supporting and/or implementing single sign-on capability for system accounts and services.

IA-2(12) Acceptance of PIV Credentials

Baselines: Low, Moderate, High

Accept and electronically verify Personal Identity Verification-compliant credentials.

Discussion and assessment objectives for IA-2(12)

Acceptance of Personal Identity Verification (PIV)-compliant credentials applies to organizations implementing logical access control and physical access control systems. PIV-compliant credentials are those credentials issued by federal agencies that conform to FIPS Publication 201 and supporting guidance documents. The adequacy and reliability of PIV card issuers are authorized using SP 800-79-2 . Acceptance of PIV-compliant credentials includes derived PIV credentials, the use of which is addressed in SP 800-166 . The DOD Common Access Card (CAC) is an example of a PIV credential.

Determine if Personal Identity Verification-compliant credentials are accepted and electronically verified.

Examine: Identification and authentication policy; system security plan; procedures addressing user identification and authentication; system design documentation; system configuration settings and associated documentation; system audit records; PIV verification records; evidence of PIV credentials; PIV credential authorizations; other relevant documents or records.

Interview: Organizational personnel with system operations responsibilities; organizational personnel with account management responsibilities; organizational personnel with information security responsibilities; system/network administrators; system developers.

Test: Mechanisms supporting and/or implementing acceptance and verification of PIV credentials.

IA-2(13) Out-of-band Authentication

Baselines: Not in a baseline

Implement the following out-of-band authentication mechanisms under [Assignment: organization-defined conditions]: [Assignment: organization-defined out-of-band authentication].

Discussion and assessment objectives for IA-2(13)

Out-of-band authentication refers to the use of two separate communication paths to identify and authenticate users or devices to an information system. The first path (i.e., the in-band path) is used to identify and authenticate users or devices and is generally the path through which information flows. The second path (i.e., the out-of-band path) is used to independently verify the authentication and/or requested action. For example, a user authenticates via a notebook computer to a remote server to which the user desires access and requests some action of the server via that communication path. Subsequently, the server contacts the user via the user’s cell phone to verify that the requested action originated from the user. The user may confirm the intended action to an individual on the telephone or provide an authentication code via the telephone. Out-of-band authentication can be used to mitigate actual or suspected “man-in the-middle” attacks. The conditions or criteria for activation include suspicious activities, new threat indicators, elevated threat levels, or the impact or classification level of information in requested transactions.

Determine if [Assignment: organization-defined out-of-band authentication] mechanisms are implemented under [Assignment: organization-defined conditions].

Examine: Identification and authentication policy; system security plan; procedures addressing user identification and authentication; system design documentation; system configuration settings and associated documentation; system audit records; system-generated list of out-of-band authentication paths; other relevant documents or records.

Interview: Organizational personnel with system operations responsibilities; organizational personnel with account management responsibilities; organizational personnel with information security responsibilities; system/network administrators; system developers.

Test: Mechanisms supporting and/or implementing out-of-band authentication capability.

Withdrawn enhancements: IA-2(3), IA-2(4), IA-2(7), IA-2(9), IA-2(11).

Assessment objectives (SP 800-53A)

Objectives and methods for IA-2

Determine if:

• IA-02[01] organizational users are uniquely identified and authenticated;
• IA-02[02] the unique identification of authenticated organizational users is associated with processes acting on behalf of those users.

Examine: Identification and authentication policy; procedures addressing user identification and authentication; system security plan, system design documentation; system configuration settings and associated documentation; system audit records; list of system accounts; other relevant documents or records.

Interview: Organizational personnel with system operations responsibilities; organizational personnel with information security responsibilities; system/network administrators; organizational personnel with account management responsibilities; system developers.

Test: Organizational processes for uniquely identifying and authenticating users; mechanisms supporting and/or implementing identification and authentication capabilities.

Policy statement

• The System owner shall ensure the system uniquely identifies and authenticates organizational users. (IA-2)
• The System owner shall ensure the system associates that unique identification with processes acting on behalf of those users. (IA-2)

IA-2(1) Multi-factor authentication to privileged accounts

• The System owner shall implement multi-factor authentication for access to privileged accounts. (IA-2(1))

IA-2(2) Multi-factor authentication to non-privileged accounts

• The System owner shall implement multi-factor authentication for access to non-privileged accounts. (IA-2(2))

IA-2(5) Individual authentication with group authentication

• Where shared accounts or authenticators are used, the System owner shall require users to authenticate individually before granting access to the shared account or resource. (IA-2(5))

IA-2(8) Access to accounts: replay resistant

• The System owner shall implement replay-resistant authentication mechanisms for access to Select one or more: privileged accounts; non-privileged accounts Typical: privileged accounts and non-privileged accounts. (IA-2(8))

IA-2(12) Acceptance of PIV credentials

• Where the organization issues or relies on Personal Identity Verification (PIV)-compliant credentials, the System owner shall ensure the system accepts and electronically verifies them. (IA-2(12))

Federal systems

Federal employees and contractors are issued PIV credentials under Homeland Security Presidential Directive 12 (HSPD-12) and FIPS 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors (January 2022).

• The System owner shall ensure the system accepts and electronically verifies PIV credentials for organizational users. (IA-2(12))

From the Identification and Authentication Policy template (draft). Highlighted fields are values your organization sets.

How to apply it

IA-2 asks that every organizational user has a unique identity and proves it before using the system, and that anything running on a user’s behalf carries that identity. In practice, the baseline enhancements do most of the work: multi-factor authentication for every account, privileged or not, at every impact level.

Common implementations. A central identity provider (for example Microsoft Entra ID, Okta or Active Directory) issues one account per person and handles single sign-on to applications, so each application logs the same identity. Multi-factor authentication is enforced at the identity provider, preferably with phishing-resistant authenticators such as PIV smart cards or FIDO2 security keys and passkeys, which are also replay resistant (IA-2(8)). Service and batch processes run under their own named accounts, and administrators use a separate privileged account. The identification and authentication standard lists the approved authenticators, sets which are required for privileged and non-privileged access, and has each system record its authentication methods.

Organization-defined parameters. The base control has none. The one baseline parameter is in IA-2(8). Typical value, which your organization may set differently:

Parameter	Typical value
Accounts needing replay-resistant authentication (IA-2(8))	Privileged accounts and non-privileged accounts

Evidence assessors ask for.

• The identity provider’s authentication policy, showing multi-factor authentication required for all users
• A list of accounts showing each maps to one person, with shared accounts justified under IA-2(5) where used
• Sign-in logs showing the authentication method used, drawn by the assessor
• The list of applications that bypass the identity provider, and how each authenticates users

Inheritance. The enterprise identity provider and its multi-factor settings are usually common controls. The system owns any application that authenticates on its own, local and emergency accounts, and exceptions to multi-factor authentication.

Common findings.

• Local application or database accounts that skip multi-factor authentication.
• Exceptions (legacy protocols, conditional access exclusions) nobody reviews.
• Shared administrator accounts with no way to tie an action to a person.
• Command-line, API or remote administration paths that accept a password alone while the web sign-in requires multi-factor authentication.

Enhancements in the Moderate baseline. IA-2(1) multi-factor authentication for privileged accounts, IA-2(2) for non-privileged accounts, IA-2(8) replay-resistant authentication and IA-2(12) acceptance of PIV credentials, all also in Low. High adds IA-2(5) individual authentication before group authentication.

Federal systems. Federal employees and contractors hold PIV credentials under HSPD-12 and FIPS 201-3 (January 2022), so IA-2(12) applies in full. Authenticator assurance levels come from NIST SP 800-63B-4 (July 2025).

Artifacts

• Identification and Authentication Decision Worksheet
• Identification and Authentication Policy
• Identification and Authentication Standard