IA-11 Re-authentication

Guidance: draftPolicy clause: draftWhat these mean

Baselines	Implementation level	Enhancements
Low, Moderate, High	Organization	None

Related controls: AC-3, AC-11, IA-2, IA-3, IA-4, IA-8

Control statement

Require users to re-authenticate when [Assignment: organization-defined circumstances or situations].

NIST discussion

In addition to the re-authentication requirements associated with device locks, organizations may require re-authentication of individuals in certain situations, including when roles, authenticators or credentials change, when security categories of systems change, when the execution of privileged functions occurs, after a fixed time period, or periodically.

Assessment objectives (SP 800-53A)

Objectives and methods for IA-11

Determine if users are required to re-authenticate when [Assignment: organization-defined circumstances or situations].

Examine: Identification and authentication policy; procedures addressing user and device re-authentication; system security plan; system design documentation; system configuration settings and associated documentation; list of circumstances or situations requiring re-authentication; system audit records; other relevant documents or records.

Interview: Organizational personnel with system operations responsibilities; organizational personnel with information security responsibilities; system/network administrators; system developers; organizational personnel with identification and authentication responsibilities.

Test: Mechanisms supporting and/or implementing identification and authentication capabilities.

Policy statement

• The System owner shall ensure the system requires users to re-authenticate when Fill in: circumstances or situations requiring re-authentication Typical: a session timeout, a change of role or privilege, a privileged action, or a change of authenticators. (IA-11)

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

How to apply it

IA-11 asks you to decide when an existing session is no longer enough and the user must prove who they are again. Two kinds of trigger are common: time, and actions risky enough to need fresh proof. AC-11 device lock and AC-12 session termination work alongside it.

Common implementations. Session timeouts set at the identity provider and in each application. NIST SP 800-63B-4 (July 2025, Sec. 2.2.3 and 2.3.3) gives values by authentication assurance level. At AAL2, the overall timeout should be no more than 24 hours and the inactivity timeout no more than 1 hour. At AAL3, the overall timeout shall be no more than 12 hours, and the inactivity timeout should be no more than 15 minutes. Step-up authentication before privileged actions, often through a privileged access tool, and before changes to authenticators or recovery settings. With federated sign-in, the application must ask the identity provider for a fresh sign-in, for example with OpenID Connect’s max_age or prompt=login, or SAML’s ForceAuthn. Otherwise the provider may reuse its own session (Sec. 5.2). The Identification and Authentication policy states the circumstances.

Organization-defined parameters. Typical value, taken from the IA policy, which your organization may set differently:

Parameter	Typical value
Circumstances requiring re-authentication	A session timeout, a change of role or privilege, a privileged action, or a change of authenticators

Evidence assessors ask for.

• Session and timeout settings from the identity provider and each application that keeps its own sessions
• Step-up or re-authentication rules for privileged roles and privileged actions
• A demonstration that changing a password or adding a multi-factor method asks the user to authenticate again
• How each federated application requests a fresh sign-in when its own session expires

Inheritance. The identity provider’s session policy is usually a common control. The system owns its application session lengths, the step-up rules for its privileged functions, and how it asks for re-authentication.

Common findings.

• “Remember me” options or refresh tokens that keep users signed in for weeks.
• Administrative consoles that perform privileged actions on an hours-old session.
• Applications that accept the identity provider’s existing session without ever forcing a fresh sign-in.
• Authenticators or recovery details changed without re-authentication, which turns a stolen session into a taken-over account.

Enhancements in the Moderate baseline. IA-11 has no enhancements.

Artifacts

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