Re-Authentication

The re-authentication requirement means you must force a user to prove their identity again whenever your defined trigger conditions occur (for example, privilege elevation, high-risk actions, session changes, or suspicious signals). Under NIST SP 800-53 Rev. 5 IA-11, FedRAMP Moderate expects you to define those circumstances, implement technical enforcement, and retain evidence that it works in production. (NIST Special Publication 800-53 Revision 5)

Key takeaways:

• Define explicit re-authentication triggers (events, risk signals, and boundaries) and map each to an enforcement mechanism.
• Implement re-authentication at the right layer (IdP, application, PAM, and session management), not just “shorter timeouts.”
• Retain audit-ready artifacts: trigger matrix, configs, logs proving prompts occurred, and test results tied to your SSP/control narrative.

“Re-authentication” sounds simple until an assessor asks: “Exactly when do you force it, and how do you prove it happened?” IA-11 requires you to require users to re-authenticate when organization-defined circumstances arise. (NIST Special Publication 800-53 Revision 5) That pushes a concrete operational obligation onto you: pick the trigger conditions, document them, implement them consistently across user journeys, and generate evidence an auditor can validate without guesswork.

For FedRAMP Moderate environments, re-authentication is rarely a single configuration knob. It typically spans your identity provider (IdP), your cloud and SaaS control planes, your privileged access paths, your applications, and your session/token architecture. It also touches third parties: managed service providers, support tools, and any outsourced admin function where a user can change system state. If you define triggers but fail to enforce them uniformly, you create gaps that show up quickly during testing (and in real incidents).

This page gives you requirement-level implementation guidance you can put into tickets today: a trigger decision matrix, step-by-step implementation tasks, evidence to retain, and the exam questions that commonly stall FedRAMP packages.

Regulatory text

Requirement (IA-11): “Require users to re-authenticate when organization-defined circumstances or situations requiring re-authentication arise.” (NIST Special Publication 800-53 Revision 5)

What the operator must do

You must:

1. Define the “circumstances or situations” that will force a user to authenticate again (your trigger set).
2. Implement technical controls that reliably enforce re-authentication at each trigger (not optional prompts).
3. Prove enforcement through configuration evidence, system logs, and repeatable tests.

IA-11 is intentionally flexible. The burden is on you to define triggers that make sense for your risk and system architecture, then show they are consistently applied.

Plain-English interpretation

Re-authentication means the user must re-prove identity (for example, re-enter password, complete MFA, use phishing-resistant method, or re-establish a session via the IdP) after specific events that increase risk or change the trust context. IA-11 is triggered by context changes, not only by time passing.

A good mental model: If the environment, privilege, or action changes the risk posture, require step-up authentication before proceeding.

Who it applies to (entity and operational context)

Entity types

• Cloud Service Providers (CSPs) operating FedRAMP Moderate authorized services.
• Federal Agencies using or operating systems aligned to FedRAMP Moderate baselines. (NIST Special Publication 800-53 Revision 5)

Operational contexts where IA-11 shows up

• Privileged access: admin consoles, cloud control planes, break-glass, and emergency access.
• High-impact actions: changes to IAM policies, key management, logging, network controls, data export, or tenant configuration.
• Session boundary changes: device changes, IP/location anomalies, token refresh boundary events, or switching between security realms/tenants.
• Third-party administered operations: MSP portals, support tooling, and external operators accessing production.

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

Step 1: Build a re-authentication trigger matrix (your “organization-defined circumstances”)

Create a table that defines triggers, scope, enforcement point, and evidence. Example starter set (you must tailor it):

Trigger category	Example trigger	Applies to	Enforcement point	Re-auth method (example)	Evidence source
Privilege change	User attempts admin role activation	Workforce/admin users	IdP + PAM	MFA re-prompt; PAM check-out approval	IdP sign-in logs; PAM audit logs
High-risk transaction	Export sensitive dataset	App users	Application	Step-up MFA before export job starts	App audit log + IdP log correlation
Security settings change	Disable logging / alter IAM policy	Admins	Cloud control plane	Re-auth required for policy change	Cloud audit trail events
Session context shift	New device or impossible travel signal	All users	IdP conditional access	Re-auth + MFA	IdP risk event logs
Long-lived session	Session exceeds your max age	All users	App session manager / IdP	Full re-auth (not silent refresh)	Session logs, token lifetime configs

Write triggers in testable language: “When X happens, system must require Y before Z proceeds.”

Step 2: Decide where enforcement lives (IdP vs application vs PAM)

Map each trigger to the control point that can actually block the action.

• IdP: best for conditional access, risk-based prompts, device posture, step-up requirements.
• Application layer: best for transaction-specific step-up (exports, approvals, destructive actions).
• PAM / privileged workflows: best for just-in-time access, credential checkout, session recording, command control.
• Cloud admin consoles: rely on native “reauth for sensitive actions” features where available, backed by IdP policy.

Common pitfall: relying only on session timeouts. A timeout helps, but IA-11 expects re-authentication when defined circumstances arise, including mid-session step-up for sensitive actions. (NIST Special Publication 800-53 Revision 5)

Step 3: Implement consistent step-up patterns

Implement one or more of these patterns, then standardize them:

1. Step-up MFA for sensitive actions
   • Require recent authentication (“freshness”) for actions like key rotation, policy updates, data export, or user management.
2. Re-auth on privilege elevation
   • Enforce re-auth when a user switches from standard to admin context (including “sudo-like” flows, role assumption, or JIT admin).
3. Re-auth on suspicious signals
   • If your IdP flags risk (unfamiliar device, atypical location), require interactive re-authentication before issuing tokens.
4. Re-auth on session/token boundary
   • Avoid silent token refresh for high-risk scopes; require interactive authentication at defined boundaries.

Document the exact mechanism (policy name, rule logic, app control, or PAM workflow) so an assessor can trace requirement to implementation.

Step 4: Test the triggers like an assessor would

For each trigger, run a test script that answers:

• What user did what action?
• What prompt occurred?
• What log entry proves re-authentication was required?
• What happens if the user cancels or fails re-auth?

Keep test results as evidence (see artifacts section). Re-run after major IdP/app changes.

Step 5: Operationalize with change management and monitoring

• Put re-auth triggers and policies under change control (tickets, approvals, peer review).
• Monitor for drift:
  • new apps without step-up,
  • exceptions that never expire,
  • admin paths bypassing the IdP.

If you use Daydream to manage third-party risk and operational compliance workflows, track each trigger/policy as a control object with mapped evidence requests to the IdP/app owners. That keeps IA-11 from becoming a once-a-year spreadsheet exercise.

Required evidence and artifacts to retain

Maintain an “IA-11 evidence packet” that includes:

1. Re-authentication trigger matrix (approved, versioned).
2. Policy documentation showing:
   • IdP conditional access rules (screenshots or exports),
   • app configuration for step-up requirements,
   • PAM/JIT configurations for privileged elevation.
3. System logs demonstrating enforcement:
   • IdP sign-in events that show MFA re-prompt / step-up,
   • application audit logs showing step-up required before action completion,
   • privileged session logs where applicable.
4. Test cases and results:
   • test scripts for each trigger,
   • screenshots/log extracts showing expected behavior,
   • negative tests (deny when re-auth fails).
5. Exception register:
   • who approved exception, rationale, compensating controls, expiration date, periodic review outcome.
6. Change records for policy updates and rollbacks.

Assessors frequently accept exports and structured log evidence over screenshots, but keep at least one human-readable proof path per trigger.

Common exam/audit questions and hangups

Expect questions like:

• “List your organization-defined circumstances for re-authentication and show where they are documented.” (NIST Special Publication 800-53 Revision 5)
• “Demonstrate re-authentication on privilege elevation. Show the prompt and the log event.”
• “Which sensitive actions require step-up in the application, not just at login?”
• “How do you prevent long-lived sessions from silently refreshing for high-risk scopes?”
• “Show all exceptions to re-authentication requirements and their expiry.”

Hangups that slow audits:

• Triggers are described vaguely (“high risk actions”) with no list.
• Controls exist in the IdP, but apps perform sensitive actions using cached sessions without step-up.
• Evidence shows MFA at login, but not re-auth at the defined trigger.

Frequent implementation mistakes and how to avoid them

1. Mistake: equating re-authentication with idle timeout

   • Fix: keep timeouts, but also enforce step-up on defined events (exports, admin changes, role assumption).

2. Mistake: defining triggers that you cannot technically enforce

   • Fix: pick enforcement points first. If your app cannot do transaction step-up, route sensitive actions through a gateway/workflow that can.

3. Mistake: inconsistent admin paths

   • Fix: inventory all admin surfaces (cloud consoles, CI/CD, infrastructure-as-code pipelines, support tools) and apply the same re-auth logic.

4. Mistake: exceptions that never expire

   • Fix: require expiration and documented compensating controls, plus periodic review tied to access recertification or risk review.

5. Mistake: no correlation between IdP logs and business actions

   • Fix: add request IDs or user/session identifiers so you can show “step-up occurred immediately before export/policy change.”

Risk implications (why auditors care)

Re-authentication reduces the blast radius of:

• stolen session cookies/tokens,
• unattended admin sessions,
• compromised endpoints that inherit an already-authenticated browser session,
• abuse of privileged roles once a user is “in.”

IA-11 focuses on moments where trust should be re-established. If you cannot show that, a compromise can turn into full administrative control without another identity check.

Practical execution plan (30/60/90)

Use phases rather than day-count promises. The goal is a shippable control with audit evidence.

First 30 days (Immediate)

• Inventory authentication paths: workforce, privileged, application users, third-party operators.
• Draft the re-auth trigger matrix and get CISO/CCO sign-off.
• Implement or tighten IdP policies for the easiest wins:
  • privilege elevation prompts,
  • risky sign-in prompts,
  • re-auth for admin portals where supported.
• Define evidence collection: which logs, where stored, retention owner.

By 60 days (Near-term)

• Implement transaction-level step-up in priority apps (data export, admin changes, key management actions).
• Integrate PAM/JIT for privileged elevation if not already standardized.
• Create test scripts per trigger and run an initial control test; remediate gaps.
• Stand up an exception workflow with approvals, expiration, and compensating controls.

By 90 days (Operationalize)

• Expand coverage to remaining apps and third-party access paths.
• Automate evidence pulls (IdP exports, cloud audit logs, app audit logs) into your GRC evidence repository.
• Add monitoring for drift (policy changes, new apps without step-up).
• Run a tabletop or control validation session using the same artifacts an assessor will request.

Frequently Asked Questions

What counts as “re-authentication” for IA-11?

Any mechanism that requires the user to actively prove identity again under defined circumstances, typically via an interactive IdP prompt and MFA. A silent token refresh generally does not satisfy the intent if it does not re-verify the user.

Do we have to re-authenticate on a timer (every X minutes)?

IA-11 is trigger-based: you define circumstances that require re-authentication and enforce them. You can include time-based maximum session age as one trigger, but you also need event-based triggers tied to risk and sensitive actions. (NIST Special Publication 800-53 Revision 5)

Where should we enforce re-authentication: IdP or application?

Use the IdP for conditional access and risk-based prompts, and use the application for step-up tied to specific transactions (exports, approvals, destructive changes). Privileged elevation often belongs in PAM plus the IdP.

How do we handle service accounts and automation?

IA-11 is written for “users,” and automation should avoid interactive sessions. Treat non-human identities through separate controls (scoped credentials, rotation, workload identity, approvals) and document why interactive re-auth is not applicable to that account type.

What evidence is most persuasive to assessors?

A trigger matrix plus system logs showing a re-auth event immediately before a sensitive action completes. Pair that with config exports (IdP/app/PAM) and repeatable test results tied to each trigger.

What about third-party administrators (MSPs, support vendors)?

Apply the same trigger matrix to third-party access paths: privilege elevation, sensitive actions, and suspicious signals should all require re-authentication. Contractually require the access method you can enforce (your IdP/PAM) and retain their access logs as part of your evidence set.