IA-11: Re-authentication

IA-11: Re-authentication requirement means you must force a user to prove their identity again at defined trigger points (your organization-defined parameter) rather than letting a prior login remain valid indefinitely. Operationalize it by defining the re-authentication triggers, enforcing them in your identity/session architecture, and retaining evidence that the triggers are configured, tested, and monitored ¹.

Key takeaways:

• Define your re-authentication triggers explicitly (time, risk, privilege, context) and treat them as a security requirement, not a UX preference ¹.
• Implement the triggers consistently across SSO, VPN, privileged actions, and remote/admin access paths; exceptions need documented risk acceptance.
• Keep assessor-ready evidence: configuration, logs, test results, and an owner-run cadence that proves the control operates.

CCOs and GRC leads usually encounter IA-11 when an assessor asks a simple question: “When do you force the user to prove it’s still them?” IA-11 is narrow, but it touches many systems: identity provider (IdP), application sessions, remote access, privileged access, and sometimes physical or VDI environments. The control language is intentionally parameterized, which means you must decide what “when” means for your environment and then prove you enforce it consistently.

This page is written to help you make that decision quickly, implement it cleanly, and assemble the artifacts auditors want. The practical goal is twofold: reduce the risk of session hijacking or misuse of unattended sessions, and avoid assessment findings caused by inconsistent timeouts, “forever sessions,” or privileged actions that do not re-check authentication. Expect assessment focus on high-risk paths first: admin consoles, financial workflows, production access, and remote access.

Target keyword: ia-11: re-authentication requirement.

Regulatory text

Requirement (quoted): “Require users to re-authenticate when {{ insert: param, ia-11_odp }}.” ¹

What the operator must do

Because IA-11 is parameter-driven, you must:

1. Define the organization-defined parameter (ODP) for “when” re-authentication is required (the triggers).
2. Implement technical enforcement so users are actually forced to re-authenticate at those triggers, across in-scope systems.
3. Prove it with evidence that the triggers are configured, tested, and operating as intended ¹.

A common audit failure mode is having “session timeout” in a policy but no consistent enforcement in the IdP/app layer, or having enforcement in one system (SSO) but not in privileged workflows.

Plain-English interpretation (what IA-11 expects)

IA-11 expects you to prevent long-lived trust. A user who authenticated earlier should not keep access forever just because a browser tab stayed open or a VPN tunnel stayed connected. Re-authentication is required at defined moments where risk increases or assurance decays.

Typical trigger categories you can define as your ODP:

• Time-based: after a period of inactivity or after a maximum session age.
• Risk-based: when signals change (new device, new geo, impossible travel, new network).
• Privilege-based: before privileged actions (admin changes, payment release, production deploy).
• Context change: when switching from standard to elevated role, or from internal to external network paths.

Your job is to pick the triggers that match your risk and regulatory environment, encode them into IAM/session controls, and make sure they are consistent and measurable.

Who it applies to

Entity scope

• Federal information systems and contractor systems handling federal data implementing NIST SP 800-53 controls as part of their security baseline ².
• Any organization using NIST SP 800-53 as a control framework (common in regulated industries and large enterprises) where assessment readiness matters.

Operational scope (where assessors look first)

Focus on authentication and session-bearing entry points:

• SSO / IdP (SAML/OIDC sessions, MFA prompts, step-up policies)
• Remote access (VPN, ZTNA, VDI)
• Privileged access (PAM tools, sudo/elevation workflows, admin consoles)
• High-risk business apps (ERP, finance approvals, HR systems, customer data platforms)
• APIs and service consoles where a human session can persist

If you have third parties with interactive access (support, integrators, consultants), treat them as users for IA-11 purposes in the systems you control. If a third party’s system is in scope, flow the requirement contractually and verify it through due diligence testing.

What you actually need to do (step-by-step)

1) Set the “when” triggers (your ODP) and document them

Create a short “IA-11 Re-authentication Standard” with:

• In-scope systems (IdP, VPN/ZTNA, PAM, critical apps)
• Trigger definitions (time/risk/privilege/context)
• Exception process (who approves, compensating controls, expiry)

Write triggers in operational language, for example:

• “Users must re-authenticate before performing privileged administrative actions.”
• “Users must re-authenticate after a defined period of inactivity.”
• “Users must re-authenticate when risk signals exceed the defined threshold (new device, anomalous location).”

Keep it tight. Assessors want clarity more than volume.

2) Map triggers to technical enforcement points

Build a mapping table and assign owners:

Trigger you defined	Enforcement control point	Owner	Systems
Privileged action step-up	IdP conditional access / step-up auth	IAM	Admin portals, cloud consoles
Inactivity timeout	App session management + IdP session policy	App owners + IAM	Web apps, VDI
Context change	Re-auth on role elevation	IAM + Platform	PAM, sudo, JIT access

This table becomes your “how it works” artifact and prevents gaps between policy and configuration.

3) Implement consistent session and step-up policies

What “good” looks like in practice:

• IdP session settings enforce re-authentication (not just MFA enrollment).
• Applications honor IdP prompts and do not override with long-lived local sessions.
• Privileged workflows require a fresh authentication step (or step-up) at the moment of action, not only at initial login.
• Remote access requires re-authentication on reconnect, high-risk changes, or privilege elevation.

If you support “remember this device” or persistent sessions for UX, explicitly scope where it is allowed, and block it for privileged/admin contexts.

4) Test the control like an assessor

You need repeatable test cases:

• Log in, wait idle, then attempt access; confirm re-authentication is required at your defined trigger.
• Log in normally, attempt a privileged action; confirm step-up authentication is enforced.
• Change context (new browser/device/network) and confirm re-authentication behavior aligns with your trigger definition.

Document the test steps and capture screenshots or logs. Treat this as control operation evidence, not a one-time implementation task.

5) Monitor and handle exceptions

Operationalize with:

• Exception register for systems that cannot support re-authentication triggers (legacy apps).
• Compensating controls (shorter network session, VDI lock, PAM proxy, additional monitoring).
• Periodic review to close exceptions or renew approvals.

A re-auth requirement that exists only in policy will fail in audit. A re-auth requirement with exceptions that are tracked, approved, and time-bounded often passes.

Required evidence and artifacts to retain

Keep evidence that proves (a) you defined “when,” (b) you implemented it, and (c) it operates.

Minimum artifact set:

• IA-11 standard / control narrative defining re-authentication triggers ¹.
• System scope list showing which systems and access paths are covered.
• Configuration evidence (IdP conditional access/step-up policies, session lifetime settings, PAM policy settings, VPN/ZTNA re-auth settings).
• Test evidence (dated test cases, screenshots, exported logs).
• Operational logs showing re-auth prompts/events for a sample period (redact as needed).
• Exception register with approvals, compensating controls, and review dates.
• Ownership and cadence: named control owner, review checklist, and evidence collection schedule (aligns with “map IA-11 to control owner, implementation procedure, and recurring evidence artifacts”) ¹.

If you use Daydream to manage your control library, store IA-11’s owner, procedures, and recurring evidence tasks in one place so assessors can trace requirement → implementation → proof without email archaeology.

Common exam/audit questions and hangups

Expect these questions:

• “Define ‘when’ for IA-11 in your environment. Where is it documented?” ¹
• “Show me the configuration in your IdP/VPN/PAM that enforces re-authentication.”
• “How do you ensure privileged actions require re-authentication, not just login?”
• “Which applications have exceptions, and who approved them?”
• “Show a test or log evidence that re-authentication happened under your trigger conditions.”

Hangups that create findings:

• Re-authentication is implemented for workforce SSO, but not for admin consoles.
• Session timeouts exist, but applications keep local sessions alive.
• Trigger definitions are vague (“periodically” / “as needed”) and cannot be tested.

Frequent implementation mistakes (and how to avoid them)

1. Confusing MFA with re-authentication

• Mistake: “We have MFA, so IA-11 is covered.”
• Fix: IA-11 is about when to prompt again, not whether MFA exists. Document triggers and enforce step-up.

2. Relying on browser/OS lock only

• Mistake: Endpoint lock is treated as re-authentication.
• Fix: Endpoint lock can be a compensating control, but you still need session-level re-auth in your access systems for defined triggers.

3. Inconsistent session handling across apps

• Mistake: IdP policies are strong, but apps issue long-lived refresh tokens or ignore IdP re-auth prompts.
• Fix: Validate app session/token configuration and require conformance as part of onboarding and change management.

4. No exception discipline

• Mistake: Legacy systems “can’t do it,” so they’re ignored.
• Fix: Track exceptions, apply compensating controls, and plan remediation with owners and dates.

Risk implications (why assessors care)

IA-11 gaps create real exposure:

• A hijacked session can bypass your login controls.
• Unattended sessions can enable unauthorized actions.
• Privileged actions without re-auth are hard to defend after an incident.

From an assessment standpoint, IA-11 is easy to test. That makes it a common “show me” control where weak documentation or inconsistent configuration turns into a finding.

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Assign an IA-11 control owner and name system owners for IdP, VPN/ZTNA, PAM, and top business apps ¹.
• Define your re-authentication triggers (ODP) and publish the IA-11 standard.
• Inventory interactive access paths, including third-party interactive access.

By 60 days (Near-term)

• Implement IdP-based step-up re-auth for privileged actions and high-risk apps.
• Align remote access re-auth behavior with the IA-11 triggers.
• Build and run repeatable tests; store test evidence and configuration exports.

By 90 days (Operationalize)

• Expand coverage to remaining in-scope apps and administrative interfaces.
• Stand up monitoring and an exception register workflow with approvals and periodic review.
• Put evidence collection on a recurring schedule in your GRC system (Daydream or equivalent) so audits do not become last-minute rebuilds.

Frequently Asked Questions

What does “when {{ insert: param, ia-11_odp }}” mean in practice?

It means you must define the conditions that trigger re-authentication for your organization, then enforce them technically. Auditors will treat your defined triggers as the testable requirement ¹.

Does IA-11 require MFA every time a user re-authenticates?

IA-11 requires re-authentication at defined triggers; it does not, by itself, prescribe the authenticator type in the excerpt provided. Many teams implement step-up MFA for high-risk triggers, but you should align that choice to your broader IA control set and risk model ¹.

How do we handle legacy applications that cannot force re-authentication?

Put them in an exception register, document compensating controls (for example, PAM fronting, shorter remote access sessions, stricter network segmentation), and assign a remediation owner. Auditors typically accept exceptions only when they are explicit, approved, and reviewed.

Is “session timeout” enough to satisfy the ia-11: re-authentication requirement?

Sometimes, but only if your defined triggers are time-based and the timeout is enforced consistently across the IdP and the application session. You still need evidence that the timeout causes a real re-auth prompt and is not bypassed by cached tokens.

What evidence is fastest to produce for an auditor?

A one-page IA-11 control narrative with triggers, plus screenshots/exports of IdP conditional access policies and a short test script with dated results. Add a scoped system list so the assessor can see coverage boundaries.

How do third parties fit into IA-11?

If third parties have named user access into your systems (support portals, admin roles, VPN/ZTNA), your re-auth triggers should apply to them as well. If they operate systems on your behalf, flow requirements contractually and verify through due diligence and periodic testing.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5