IA-11 is one sentence long: require users to re-authenticate when circumstances you define occur. The work is in defining them and showing that the system enforces them.
800-53 applies to US federal systems and to contractors bound by it. Others use it as a reference for session and step up design.
What it means in practice
The NIST guidance goes beyond device locks. It lists situations where you might require a fresh login: when roles, authenticators or credentials change, when a system's security category changes, when someone runs a privileged function, after a fixed time period, or periodically.
That maps cleanly onto everyday product behavior. Ask for a password or second factor again before changing an email address, adding an API key, approving a payment or opening the admin console. Expire long lived sessions on a set schedule.
Evidence to collect
- A table of re-authentication triggers with the time limits you chose.
- Configuration of session lifetime and step up rules in your identity provider and applications.
- A test record showing a privileged action prompts again.
- Change tickets when the rules were adjusted.
Common gaps
Session lifetimes of weeks with no step up for sensitive actions. Service tokens with no expiry. Rules that exist in the admin console but not in the customer facing app.
How to implement it
Start with a short list: privileged functions, credential changes and a maximum session age. Implement them in one place if you can, such as the identity provider, so evidence is a single export.
Quick check
Name two events NIST gives as reasons to re-authenticate.
Any two of: a change of roles, authenticators or credentials; a change in the system's security category; running a privileged function; a fixed time period; or periodically.
