NIST SP 800-53 Rev 5, published by the National Institute of Standards and Technology in September 2020, is the foundational control catalog for federal information systems operating under FISMA and for cloud services seeking FedRAMP authorization. The Identification and Authentication (IA) control family comprises 12 base controls — IA-1 through IA-12 — with numerous control enhancements that add specificity based on system impact level. For federal contractors operating FISMA-covered systems or deploying software that serves agency customers under FedRAMP scope, the IA family defines the baseline requirements for every identity and authentication decision in the system.
This guide walks through each IA control with the specificity needed for a contractor ISSO, FSO, or security engineer to understand what implementation and documentation are required. It is organized around the operational sequence: policy and procedure (IA-1), then user identity management, then non-organizational identity management, then device authentication, then the authenticator lifecycle, and finally the advanced controls for service identity and identity federation.
IA-1: Policy and Procedures — The Foundation
IA-1 requires the organization to develop, document, and disseminate an identification and authentication policy and associated procedures. This is the procedural framework that gives all other IA controls their operational context. The policy must address purpose, scope, roles, responsibilities, management commitment, coordination, and compliance. Procedures must address implementation of the policy and associated controls.
In practice, many contractors satisfy IA-1 with an Identification and Authentication Policy document that cross-references their System Security Plan (SSP). What assessors look for beyond the document's existence: evidence that the policy is reviewed and updated at the organization-defined frequency (typically annually) and that it has been disseminated to the personnel responsible for implementation. A policy dated three years prior with no revision history is an IA-1 finding.
IA-2 Through IA-4: User Identification and Authentication
IA-2 (Identification and Authentication — Organizational Users) is the most frequently assessed control in the IA family. The base control requires uniquely identifying and authenticating organizational users. The enhancements escalate the requirements significantly:
- IA-2(1): Requires multi-factor authentication for privileged accounts. At FedRAMP Moderate, this enhancement is required. Phishing-resistant MFA (FIDO2/WebAuthn hardware tokens, PIV/CAC cards) is increasingly expected for privileged access.
- IA-2(2): Extends MFA to all non-privileged network access. Also required at FedRAMP Moderate baseline.
- IA-2(6): MFA for local and network access to privileged accounts using separate factors. Relevant for systems where local console access exists alongside network access paths.
- IA-2(12): Requires acceptance of PIV credentials under HSPD-12. Federal contractors supporting agency programs where PIV-bearing federal employees need access must accept PIV as a valid authenticator type.
IA-3 (Device Identification and Authentication) requires that the system uniquely identify and authenticate devices before establishing connections. For cloud-hosted contractor systems, this frequently involves certificate-based device authentication or network access control (NAC) mechanisms. The control applies to both internal network devices and remote endpoints connecting to covered systems.
IA-4 (Identifier Management) governs the full lifecycle of identifiers — user IDs, device IDs, and service account identifiers. The control requires that identifiers be managed by receiving authorization, selecting identifiers, assigning identifiers to the intended parties, preventing reuse for a defined period, and disabling identifiers after a defined period of inactivity. The prohibition on identifier reuse is particularly important for contractor personnel systems: reusing a former employee's system identifier for a new hire is an IA-4 violation with forensic implications — audit logs attributed to the old identifier no longer reliably identify a unique individual.
IA-5: Authenticator Management — The Most Evidence-Intensive Control
IA-5 governs the full lifecycle of authenticators: initial distribution, storage, use, and revocation. It is one of the most evidence-intensive controls in the IA family because it spans both policy documentation and technical configuration evidence. The base control requires managing authenticators by verifying identity before distribution, establishing initial authenticator content, requiring administrative procedures for lost/compromised authenticators, changing default authenticators before deployment, setting minimum and maximum lifetime restrictions, and preventing reuse within a defined generation count.
The enhancements add substantial technical requirements:
- IA-5(1): Password-based authentication requirements — minimum password length (at least 8 characters; NIST SP 800-63B recommends minimum 8 with support for up to 64), prohibition on commonly used passwords (using deny-listed password databases), and storage using approved cryptographic hashing algorithms. NIST SP 800-63B Rev 2 guidance updates removed mandatory complexity rules (character composition requirements), instead focusing on length and breach corpus checking.
- IA-5(2): PKI-based authentication — requires validation of PKI certificates including path validation, OCSP/CRL checking, and verification of certificate binding to the user identity. For systems accepting PIV or PIV-I credentials, this enhancement is fully applicable.
- IA-5(6): Protection of authenticators — requires protecting authenticators proportional to the information they secure. For privileged account tokens, this implies hardware-based storage (HSM or secure element) rather than software-only credential stores.
Consider a scenario that illustrates the IA-5(1) compliance gap in practice: a 300-person defense engineering contractor operating a CUI-handling system had implemented password complexity rules (uppercase, number, special character requirements) as their IA-5(1) implementation. During a FISMA assessment, reviewers noted that the system allowed passwords like "Password1!" — technically meeting complexity requirements but present in every common breach corpus. The finding: IA-5(1) was "Partially Compliant" because no deny-list mechanism was implemented, contrary to updated NIST SP 800-63B guidance. The remediation required integrating a Have I Been Pwned API check or equivalent at password set and change events — a non-trivial engineering task that took two POA&M cycles to remediate.
IA-6 Through IA-9: Feedback, Cryptographic Modules, Service and Device Authentication
IA-6 (Authentication Feedback) requires that the system obscure feedback of authentication information during the authentication process. This is the control that mandates password masking in login forms — a basic requirement that is nonetheless worth explicitly documenting in the SSP because assessors verify it during system demonstration.
IA-7 (Cryptographic Module Authentication) requires that authentication mechanisms use cryptographic modules meeting requirements in FIPS 140-2 (or its successor, FIPS 140-3). For any system handling federal information, all cryptographic operations — including authentication token generation, password hashing, and session token signing — must use FIPS-validated modules. This applies to the operating system's cryptographic libraries, the application framework's security components, and any third-party authentication libraries. Vendors and contractors should maintain a FIPS module registry that maps each cryptographic function to its validated module and certificate number.
IA-8 (Identification and Authentication — Non-Organizational Users) governs external user authentication. For federal contractor identity platforms, this is typically the most operationally complex control because contractor personnel accessing the system are non-organizational users. IA-8(1) requires acceptance of PIV credentials from other federal agencies; IA-8(2) requires acceptance of third-party credentials that meet FICAM-approved frameworks; IA-8(4) requires using FICAM-approved identity federation technologies.
IA-9 (Service Identification and Authentication) addresses authentication between system services — microservices, APIs, and automated processes that communicate within or across boundaries. Service-to-service authentication requires mutual authentication using certificates or service accounts with cryptographically-bound credentials. This control has grown in importance as contractor systems have moved toward microservice and cloud-native architectures where inter-service trust must be explicitly managed.
IA-10 Through IA-12: Advanced Adaptive and Re-Authentication Controls
IA-10 (Adaptive Authentication) and IA-11 (Re-Authentication) address context-aware authentication. IA-11 requires re-authentication when system-defined circumstances occur — session timeouts being the most common implementation, but also role escalation, access to particularly sensitive functions, or detection of anomalous session characteristics. The organization-defined circumstances must be documented in the SSP and enforced by the system.
IA-12 (Identity Proofing) was added in NIST SP 800-53 Rev 5 and directly addresses the identity verification function that underpins all other IA controls. It requires that the identity-proofing process satisfy requirements under applicable laws, executive orders, directives, regulations, and standards — specifically referencing NIST SP 800-63A (Digital Identity Guidelines: Enrollment and Identity Proofing). For contractor personnel accessing federal information systems, identity assurance level (IAL) 2 proofing is typically required: evidence of identity using acceptable forms of government-issued documentation, with either remote or in-person proofing.
IA-12 is the control that connects the organizational HR and onboarding process to the technical identity and access management system. It requires that identity records be created based on proofed identities, not merely self-asserted identities. This is the control that assessors examine when they ask for your identity proofing procedures and supporting documentation. For a detailed discussion of how identity proofing integrates with cleared contractor onboarding specifically, see our guide on cleared personnel onboarding verification. For how the IA control family maps to CMMC 2.0 Level 2 practices, see our CMMC 2.0 identity requirements article.
We are not suggesting that organizations need to implement every IA control enhancement at the most rigorous level regardless of system classification. The baseline-appropriate control selection process — matching enhancements to impact level, processing environment, and threat model — is documented in the organization's security categorization and risk assessment. The point is that when assessors examine IA controls, they look for documented rationale for any deviations from the applicable baseline, not just whether controls are present. Undocumented tailoring is a finding even when the technical implementation is sound. Security officers managing NIST SP 800-53 compliance programs should treat the IA control family documentation as a living artifact updated with every system change that touches identity, authentication, or account management.