IA-2: Identification and Authentication (Organizational Users)

Quick-reference card

What this control requires

IA-02 requires organizations to uniquely identify and authenticate every organizational user before granting system access. This control covers employees, contractors, guest researchers, and any individual with equivalent organizational status.

In practice, that requirement breaks down into two assessment objectives. First, every organizational user must authenticate through a unique identifier tied to their individual identity. Second, any process acting on behalf of an authenticated user must be traceable back to that user’s unique identifier, so audit trails remain intact and accountability stays enforceable.

In practice, organizations can satisfy identification and authentication (I&A) requirements through several mechanisms, including passwords, physical authenticators such as smart cards, biometrics, or multi-factor authentication combinations. Homeland Security Presidential Directive 12 provides federal agencies with a foundational policy framework for these requirements. The control applies to both local access, where users connect directly to a system, and network access, which includes remote connections through external networks. Organizations may treat VPN connections between organization-controlled endpoints and non-organization endpoints as internal networks. Exceptions exist only where AC-14 explicitly permits actions without identification or authentication, or where authorized group authenticators are in use. Requirements for non-organizational users fall under a separate control, IA-08.

Why it matters

Most organizations treat user authentication as a checkbox item, configuring it once and moving on. That assumption ignores the operational reality that authentication gaps compound over time as systems proliferate, acquisitions introduce unvetted infrastructure, and remote access expands. A single portal running without multi-factor authentication (MFA) can give an attacker the same standing as a trusted employee.

The consequences of failing IA-02 aren’t theoretical. On February 12, 2024, the ALPHV/BlackCat ransomware group accessed Change Healthcare’s network through a Citrix remote desktop portal that lacked MFA. CEO Andrew Witty confirmed the MFA absence under oath before the Senate Finance Committee and the House Energy and Commerce Committee on May 1, 2024. The Citrix portal had been acquired as part of UnitedHealth Group’s 2022 acquisition of Change Healthcare and hadn’t been brought into UHG’s security standards, despite company policy requiring MFA on all external-facing systems.

Specifically, the attackers moved laterally through the network for nine days before deploying ransomware. UnitedHealth Group paid a $22 million ransom to ALPHV/BlackCat.

The downstream impact was systemic. Change Healthcare processes roughly one-third of all US healthcare transactions, and the resulting outage disrupted prescriptions, insurance claims, and provider payments for weeks. Up to 100 million individuals were affected, making this the largest healthcare data breach in US history, with recovery costs exceeding $2.8 billion.

Where this control breaks down is at the intersection of identity governance and infrastructure sprawl. Inherited systems, shadow IT, and third-party integrations create authentication blind spots that standard compliance audits rarely catch.

What attackers exploit

• Credentials reused across multiple systems without unique identifiers tying each session to an individual user
• Remote access portals and Citrix gateways deployed without MFA enforcement
• Service accounts and shared credentials that bypass unique user identification requirements
• Acquired infrastructure that hasn’t been integrated into the organization’s authentication standards
• Legacy systems where authentication mechanisms can’t support modern I&A requirements

How to implement

First-party implementation

You need to ensure every user accessing your systems authenticates through a unique identifier and a mechanism strong enough to match the risk. Start by inventorying all system access points, including remote access portals, VPN endpoints, cloud consoles, and local terminals. Map each access point to the authentication mechanism it supports.

The result is a mandate to enforce MFA on every external-facing system and every system processing sensitive data. Your identity and access management program should enforce unique user IDs across all environments, prohibit shared accounts except where explicitly authorized under group authenticator policies, and maintain a current list of all system accounts with their associated authentication methods.

But the harder work is sustaining compliance across organizational change. Build authentication requirements into your acquisition integration playbooks so inherited systems don’t become blind spots. Require periodic access reviews that verify each account maps to an active, authorized user, and that the authentication mechanism assigned to each access point meets your policy requirements.

Third-party implementation

When your vendors and suppliers process your data or connect to your systems, their identification and authentication controls become your risk. Require contractual commitments to unique user identification and MFA for any access to systems that store, process, or transmit your information.

In practice, this requirement means validating that your critical vendors enforce unique user IDs for their employees who interact with your data. Shared or generic accounts used by vendor staff to access your environments undermine your own IA-02 compliance posture.

Where this process breaks down is during evidence collection. Red flags include vendors who can’t produce an account inventory, rely on shared service accounts for client-facing work, or lack audit logs tied to individual user sessions. Include authentication control requirements in your security questionnaires and verify them through evidence collection during periodic reviews.

Evidence examples

Cross-framework mapping

Related controls

• AC-02 – Account Management: Governs the lifecycle of system accounts, from creation through disabling, and depends on IA-02’s unique identification to associate each account with an authorized user.
• AC-03 – Access Enforcement: Enforces authorization decisions after IA-02 has confirmed the user’s identity, controlling what authenticated users can access.
• AC-04 – Information Flow Enforcement: Controls the movement of data between systems and security domains, relying on authenticated user identities to apply flow rules.
• AC-14 – Permitted Actions Without Identification or Authentication: Defines the narrow set of actions explicitly exempted from IA-02’s unique identification requirements.
• AC-17 – Remote Access: Governs how users connect from outside the organization’s network boundary, where IA-02’s authentication requirements are especially critical.
• AC-18 – Wireless Access: Extends access control to wireless connections, which require the same unique identification and authentication as wired network access.
• AU-01 – Policy and Procedures: Establishes the audit and accountability policy framework that depends on IA-02’s unique user identification for meaningful audit trails.
• AU-06 – Audit Record Review, Analysis, and Reporting: Uses the identity-linked audit records produced by IA-02 compliance to detect anomalies and investigate incidents.
• IA-04 – Identifier Management: Manages the lifecycle of the unique identifiers that IA-02 requires for each organizational user.
• IA-05 – Authenticator Management: Governs the credentials and tokens used to verify identity, complementing IA-02’s requirement that authentication actually occur.

Frequently asked questions

What is NIST SP 800-53 IA-02?

IA-02 is the NIST SP 800-53 control that requires organizations to uniquely identify and authenticate every organizational user, including employees and contractors, before granting system access. The control’s assessment objectives mandate that unique identification extends to processes acting on behalf of authenticated users, not just interactive login sessions. This requirement ensures that every action within a system traces back to an individual, supporting accountability and audit integrity. Your identification and authentication policy must define which authenticator types satisfy this control for each access type.

What happens if IA-02 is not implemented?

Failing to implement IA-02 removes the ability to trace system actions to specific individuals, collapsing accountability across your environment. Shared credentials and missing MFA allow attackers to authenticate as legitimate users and move laterally without triggering identity-based detection. The Change Healthcare breach demonstrated this failure pattern directly, where a Citrix portal without MFA led to nine days of undetected lateral movement, a $22 million ransom payment, and up to 100 million affected individuals. Auditors reviewing your system audit records and account inventory will flag missing unique identification as a critical finding that cascades into non-compliance across related controls like AC-02 and AC-03.

How do you audit IA-02?

Auditing IA-02 starts with collecting your identification and authentication policy and verifying it defines approved authenticator types, MFA requirements, and unique identifier standards for all organizational user categories. Auditors then examine system configuration settings to confirm that technical enforcement matches documented policy, specifically checking that each access point requires unique credentials and that shared accounts are limited to explicitly authorized group authenticator use cases. The system security plan and design documentation should describe the authentication architecture, and audit records must demonstrate that authentication events tie back to unique user identifiers. Comparing your list of system accounts against HR records and contractor registries confirms that every active account maps to an identifiable, authorized individual.

What is the difference between IA-02 and IA-08?

IA-02 governs identification and authentication for organizational users, which includes employees, contractors, and individuals with equivalent organizational status who hold system accounts tied to unique identifiers. IA-08 addresses non-organizational users, such as external partners, members of the public accessing government services, or any user who doesn’t fall under the organization’s direct authority. The distinction matters for your procedures addressing user identification because organizational users follow internal credential provisioning and lifecycle management, while non-organizational users typically authenticate through federated identity providers or separate registration processes. Both controls share the goal of unique identification but apply different policy frameworks and authenticator requirements based on the trust relationship.