NIST SP 800-53 IA Identification and Authentication: Key Controls, Enhancements and How to Evidence Them

The Identification and Authentication (IA) family is where most SP 800-53 assessments find their first real gaps, because the control text is short and the organisation-defined parameters behind it are often never written down. This guide works through the IA family control by control: what each key control and enhancement requires, which baselines select it, how the parameters should be set, and what evidence an assessor will ask for under SP 800-53A. It covers human users, devices, services and the identity providers that issue tokens to all of them. It is written for control owners, system security plan authors, IAM engineers and assessors. For the catalogue as a whole, see the NIST SP 800-53 Guide; this page goes one level deeper on IA only.

Key takeaways

• Thirteen base controls, and the newest matters most. IA-1 to IA-13 are current in Release 5.2.0. IA-13 (Identity Providers and Authorization Servers) and its three enhancements on token keys, token verification and token lifecycle were added in Release 5.1.1 and are not yet in any baseline, but they describe the controls that token theft attacks target.
• MFA is a Low baseline requirement. IA-2(1) and IA-2(2) require multi-factor authentication for privileged and non-privileged accounts at every baseline, and IA-2(8) adds replay resistance. There is no baseline in which password-only access to an organisational account is acceptable.
• IA-5(1) now reads like SP 800-63B. A blocklist of common and compromised passwords, salted key derivation for storage, long passphrases and forced change after recovery. Composition rules are a parameter you set, and SP 800-63B-4 says verifiers shall not impose them.
• Services and devices are in scope. IA-3 (devices), IA-9 (services) and IA-5(7) (no embedded unencrypted static authenticators) are the controls that cover service accounts, API keys and workload credentials. IA-9 and IA-5(7) are outside the baselines, so you must add them by tailoring.
• Evidence is configuration plus population. Assessors examine policy and settings, interview administrators and test the mechanism. The strongest evidence is an export that shows the setting applied to the full account population, with exceptions listed.

The IA family at a glance

The table lists every current IA base control with its baseline allocation, taken from NIST's OSCAL Release 5.2.0 baseline profiles (L = Low, M = Moderate, H = High). Withdrawn enhancements are omitted.

Baselines come from SP 800-53B. If you are choosing between them or tailoring, see the NIST SP 800-53B Control Baselines and Tailoring Guide.

IA-2: users, MFA and replay resistance

IA-2 requires the system to uniquely identify and authenticate organisational users and to associate that identity with processes acting on their behalf. The enhancements carry the weight:

• IA-2(1) and IA-2(2): implement multi-factor authentication for access to privileged and non-privileged accounts. Both apply at the Low baseline, so the scope question is never "whether" but "which access paths". List every path: web SSO, VPN, VDI, SSH, cloud consoles, local console logon, break-glass accounts and API access by people.
• IA-2(8): replay-resistant mechanisms for the accounts you define in the parameter. Time-based one-time passwords, challenge-response and FIDO2 or WebAuthn authenticators meet this; static passwords and SMS codes that can be relayed are weak evidence. SP 800-63B-4 requires verifiers to offer at least one phishing-resistant option at AAL2 and requires phishing resistance at AAL3. See the Phishing-Resistant MFA Guide.
• IA-2(5): at High, people who use group authenticators must first authenticate individually. In practice this means shared accounts are checked out from a vault after individual sign-in.
• IA-2(12): accept and verify PIV credentials. This is a federal requirement; non-federal organisations usually tailor it out with a recorded rationale.

The Change Healthcare breach shows why scope matters more than policy: a Citrix remote access portal without MFA let a stolen password in, as described in the Change Healthcare Breach 2024 analysis.

IA-4 and IA-5: identifiers and authenticators

IA-4 requires authorisation before an identifier is assigned to an individual, group, role, service or device, and prevents reuse of identifiers for a period you define. IA-4(4) (Moderate and High) adds identifying user status, such as contractor or foreign national, in the identifier or directory attribute.

IA-5 is the authenticator lifecycle. Its nine statement items cover identity verification at issue, initial content, strength, procedures for lost or compromised authenticators, changing defaults before first use, change or refresh on a defined frequency or event, protection of content, user protections, and changing group account authenticators when membership changes. Two parameters cause most findings: the refresh frequency in IA-5(f) and the events that force a change.

The settings column is our recommendation, not NIST text. The password rules align with the Password Policy Guide (NIST-aligned). For hashing choices behind IA-5(1)(d), see the Password Hashing and Key Derivation Guide.

Devices, services and identity providers: IA-3, IA-9 and IA-13

These three controls are where the IA family reaches non-human identities, and they are the controls most often left at "inherited" or "not applicable" without a reason.

• IA-3 Device Identification and Authentication: uniquely identify and authenticate the devices you define before a local, remote or network connection. Device certificates for 802.1X, mutual TLS between components and managed device compliance checks in conditional access are typical implementations. IA-3(1) adds cryptographic bidirectional authentication and IA-3(4) device attestation; neither is in a baseline.
• IA-9 Service Identification and Authentication: uniquely identify and authenticate the services or applications you define before they communicate with devices, users or other services. This is the home control for workload identity, service accounts and API clients. It is not in any baseline, so a system that relies heavily on service-to-service calls should add it during tailoring. See the NHI Authentication Guide.
• IA-13 Identity Providers and Authorization Servers: employ identity providers and authorisation servers to manage user, device and non-person entity identities, attributes and access rights. IA-13(1) requires the keys that protect access tokens to be generated, managed and protected from disclosure and misuse. IA-13(2) requires verifying the source and integrity of assertions and tokens before granting access. IA-13(3) requires tokens to be generated, issued, refreshed, revoked, time-restricted and audience-restricted.

NIST IR 8587 (final, September 2026), on protecting tokens and assertions from forgery, theft and misuse, gives implementation recommendations for agencies and cloud service providers that build on the Release 5.1.1 updates. It is the practical companion to IA-13. See also the Identity Provider and SSO Security Guide and the OAuth Token Introspection and Revocation Guide.

The rest of the family: IA-6, IA-7, IA-8, IA-10, IA-11, IA-12

• IA-6 Authentication Feedback: obscure feedback during authentication, such as masking passwords. Usually inherited from the platform; evidence is a screenshot or configuration.
• IA-7 Cryptographic Module Authentication: authentication to cryptographic modules must meet applicable laws, policies and standards. For federal systems this is where FIPS 140 validation evidence sits.
• IA-8 Non-organizational Users: customers, partners and citizens. IA-8(2) requires accepting only NIST-compliant external authenticators and keeping a list of those accepted, and IA-8(4) requires conformance to defined identity management profiles. See the NIST SP 800-63C-4 Federation Assurance Guide for federated access.
• IA-10 Adaptive Authentication: require additional authentication under defined circumstances. Risk-based conditional access is the usual implementation, though it is not in a baseline.
• IA-11 Re-authentication: require users to re-authenticate in circumstances you define, such as role change, privilege elevation, session timeout or sensitive transactions. The parameter list is the evidence; an empty one is a finding.
• IA-12 Identity Proofing: proof users to the identity assurance level your standards require, resolve them to a unique individual and validate evidence. Moderate adds identity evidence, validation and verification and address confirmation; High adds in-person validation. See the NIST SP 800-63A-4 Identity Proofing Guide.

How to evidence IA controls

The OSCAL catalogue carries the SP 800-53A assessment methods for each control: examine (policy, procedures, the system security plan, configuration settings, audit records, the list of system accounts), interview (system administrators, account managers, security staff, developers) and test (the mechanisms that implement the control). The table turns that into evidence that answers an assessor in one pass.

Evidence that shows coverage of the whole population beats a single screenshot. For assessment depth and coverage, see the NIST SP 800-53A Guide.

Implementing the IA family: a phased approach

This sequence is NHI Mgmt Group's recommendation for a Moderate system starting from an incomplete IA implementation.

1. Write the parameters. Fill every organisation-defined parameter in IA-2(8), IA-3, IA-4, IA-5(f), IA-5(1)(h) and IA-11 in the system security plan. Most findings start here.
2. Inventory access paths and identities. Every human, device and service identity, and every path by which each authenticates. Reconcile against the IA-4 identifier records.
3. Close MFA gaps in report-only mode first. Run conditional access or equivalent policies in report-only or audit mode for two weeks, review who would be blocked, then enforce by pilot ring. Roll back by returning the policy to report-only, never by disabling it.
4. Fix authenticator storage. Move service credentials into a vault (IA-5(6)), run secret scanning (IA-5(7)) and set rotation triggers.
5. Tailor in IA-9 and IA-13. Document service authentication and token lifetimes, audience restriction and revocation for each identity provider.
6. Collect evidence continuously. Schedule exports so evidence is current at assessment time. See the Audit Evidence and Continuous Controls Monitoring Guide.

Decision guidance

• Low versus Moderate: a Low system still needs MFA for all accounts and replay resistance. Moderate adds device authentication, public key controls, authenticator protection and identity proofing. Small organisations with a single identity provider can usually meet both by inheritance from that provider, provided the inheritance is documented.
• Inherit or implement: IA-6 and IA-7 are often inherited from platforms. IA-2, IA-5 and IA-11 are hybrid: the provider supplies the mechanism and you set the policy. Record which part is yours.
• Passwords versus passwordless: passkeys and FIDO2 meet IA-2(1), IA-2(2) and IA-2(8) together and reduce IA-5(1) scope. Keep IA-5(1) for residual passwords and recovery.

Detection and measurement

• Share of accounts, by population (workforce, privileged, service), with MFA enforced on every access path. Target 100% with a dated exception list.
• Number of authentication methods allowed that are not replay resistant, and for whom.
• Secrets found by scanning per month and median time to revoke them.
• Service identities authenticated by a managed identity or certificate rather than a static secret.
• Maximum access and refresh token lifetimes per identity provider against your IA-13(3) parameter.

Log sign-ins, MFA challenges, failed authentication and token issuance and send them to monitoring under AU-2 and SI-4.

Framework mapping

Mappings are "intersects with", not equivalence. Check them against NIST's published informative references before using them in an audit. For method, see the Control Mapping Guide.

Common failure patterns

• Parameters left blank: the plan says "IA-5 is implemented" but never states the refresh frequency or the events that trigger a change.
• MFA on the front door only: SSO enforces MFA while VPN, legacy protocols or a remote access portal accept passwords. Colonial Pipeline's unused VPN account had no second factor; see the Colonial Pipeline Ransomware Attack 2021.
• Service identities treated as out of scope: IA-9 and IA-5(7) not tailored in, so service account keys and API tokens have no owner, rotation or scanning.
• Periodic password expiry kept "for compliance": IA-5(1) does not require it and SP 800-63B-4 says verifiers shall not require periodic change.
• Token controls assumed from the identity provider: nobody records the token lifetimes, audiences or revocation test that IA-13(3) describes.

Practitioner checklist

• Fill every IA organisation-defined parameter in the system security plan.
• List every authentication path and prove MFA on each with a test account.
• Restrict in-scope accounts to replay-resistant methods and offer a phishing-resistant option.
• Configure a password blocklist and remove composition and expiry rules.
• Vault privileged and service credentials and run secret scanning on code and artefacts.
• Tailor in IA-9 and IA-13 for systems with service-to-service or token-based access.
• Record token lifetimes, audience restriction and a tested revocation procedure.
• Schedule evidence exports that show coverage of the whole population.

Standards and references

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: OSCAL content, SP 800-53 Release 5.2.0 catalogue and baseline profiles
• NIST: SP 800-63B-4, Authentication and Authenticator Management
• NIST: IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse
• NIST: SP 800-171 Rev. 3
• NIST: Cybersecurity Framework 2.0
• CIS: Controls Assessment Specification, Control 5 Account Management

Related NHI Mgmt Group resources: NIST SP 800-53 Guide · Least Privilege Techniques Guide · NIST SP 800-63B-4 Authentication Guide · MFA Guide