IA-11 Re-authentication: requirements and evidence

What IA-11 re-authentication asks for and why it is hard to scope

If you need to satisfy IA-11 for a system at the low, moderate or high baseline, the first thing to understand is that the control asks for re-authentication in circumstances you define, not a fixed list set by NIST. IA-11 requires users to prove their identity again when organization-defined circumstances or situations occur. The catalog's guidance gives examples such as changes to roles, authenticators or credentials, and the execution of privileged functions. This is separate from the re-authentication that follows a device lock, which many teams already configure and which does not satisfy IA-11 by itself. SP 800-53B selects IA-11 for the low, moderate and high baselines but not for the privacy baseline, and the control has no enhancements in Release 5.2.0, so the work sits almost entirely in the one parameter you set.

The risk behind the control is a session that stays open after the identity or privilege context has changed. A user is granted an administrator role, or a password or token is rotated, or a sensitive function is invoked, and the session keeps the trust it had before the change. The control is hard to scope for exactly this reason: the organization must decide which circumstances matter for each system. A reasonable starting point is an inventory of role assignments, credential events and privileged actions in your identity provider and application logs, then a written list of the triggers you will enforce. Confirm with your assessor how they expect that list to be documented, because SP 800-53A checks for a list of circumstances requiring re-authentication as its primary examine object.

Expect the decision to touch several teams. Identity engineers must confirm which triggers the identity provider can enforce, application owners must confirm that each privileged function can require a fresh sign-in, and audit owners must confirm that re-authentication events reach the audit trail. Where a product cannot enforce a trigger, the gap belongs in your plan of action and milestones rather than being left silent. Open-source identity providers such as authentik and FreeIPA can help with the sign-in side, but the decision about which circumstances count, and the evidence that they work, remain yours to define and test.

Which systems, teams and third parties IA-11 re-authentication covers

IA-11 applies at the low, moderate and high baselines in SP 800-53B but not to the privacy baseline, so the system's impact level is the first scoping decision. Within a covered system, the organization must still decide which functions, identity components and operators trigger re-authentication, and which of those sit with a third party.

Systems at low, moderate and high impact

The first scoping question is the system's impact level. SP 800-53B selects IA-11 for the low, moderate and high baselines, so any system categorized at one of those levels needs the control. Systems covered only by the privacy baseline do not select IA-11 on that basis alone. Confirm the categorization in the system security plan, and record which baseline was selected and any tailoring that removed or changed the control.

Applications with privileged functions

Applications that let users change payment data, approve transactions, export records or alter configuration are the most common place where IA-11 requirements apply. The organization must define which functions trigger re-authentication, such as a privileged action after a long idle session. Build an inventory of these functions per application so the defined circumstances in the control parameter can be tested and evidenced.

Identity providers and directories

Changes to roles, group memberships, authenticators or credentials are circumstances the control guidance names. Identity providers such as authentik and directories such as FreeIPA are where these changes happen. Confirm which events each component can enforce, such as forcing a fresh login after a group change, and where it cannot, document a compensating process or an application-side check.

Administrators and operations staff

Administrators and operations staff hold the access most often used to execute privileged functions. Teams that run infrastructure, directory services and application administration need the same re-authentication rules as the systems they manage, and their sessions are the ones an assessor is most likely to sample. Interview these teams to confirm they know which actions prompt re-authentication and how to report failures.

Third-party and managed identity services

Where a managed identity service or a SaaS application handles sign-in, the organization may not control its re-authentication behavior. Request the vendor's documented session and re-authentication settings, confirm whether they can be set to the organization's defined circumstances, and capture the evidence in the contract or assessment file. Treat any gap as a risk to record in the plan of action and milestones.

Audit records that prove re-authentication

The examine method for IA-11 relies on the list of circumstances requiring re-authentication and on system audit records. Identify which logs record re-authentication prompts, successful re-authentications and failures, and confirm they are retained and reviewable. Without these records, the organization cannot show the control operated as defined, even if the configuration is correct.

How to define re-authentication triggers before an assessor asks

IA-11 requires the organization to define the circumstances or situations that force a user to re-authenticate, and that definition is an organization-defined parameter (IA-11_ODP in SP 800-53A). NIST leaves the values to you, so an assessor will not accept a generic statement that re-authentication happens "when appropriate." Start by writing a list of the specific events your system treats as re-authentication triggers, and make sure every entry describes something the system can actually detect. The catalog's own examples point to the usual candidates: changes to roles, authenticators or credentials, and the execution of privileged functions. Treat that list as the starting point, then confirm it against your environment, including administrative consoles, API tokens and any integrated applications that hold their own sessions.

Choose triggers by asking what would make an existing session unsafe to keep trusting. A role grant or removal changes what the user can do, so an active session should not carry the old authority forward. A password change, a new security key enrollment or a removed authenticator changes the proof of identity, so the session that existed before the change deserves a fresh check. Privileged actions such as changing access policy, exporting audit logs or disabling logging are where a stale session causes the most harm. For each trigger, record the decision in a short register with four fields: the event, the system component that detects it, the re-authentication method required, and the rationale. Note any trigger you deliberately left out and why. The register is what the assessor will compare against your audit records, so keep it under document control with the rest of your IA policy and procedures.

The most common gap is a list that exists in a policy document while the application never enforces it. An assessor will test this by performing a trigger event, such as a role change for a test account, and checking whether the session is challenged and whether an audit record shows it. If the identity provider or application keeps a long-lived session after a role change, the control fails even though the document is correct. Confirm for each platform whether it supports step-up or re-authentication prompts for specific actions, and whether the identity provider can require a fresh authentication event for a given application. For example, authentik and FreeIPA handle sessions and authentication at different layers, so you must verify the behavior of the component that actually issues the session in your deployment, not assume it from the product name. Test each trigger in the register and keep the results as evidence.

How an assessor tests IA-11 re-authentication

This table compares the three assessment methods SP 800-53A applies to IA-11, one determination statement examined, interviewed and tested. Read each row as a question the assessor asks, the evidence the organization should have ready, and where findings usually arise.

Assessment method	What the assessor checks	Evidence to prepare	Common findings
Examine: list of circumstances and audit records	Whether the organization has defined the circumstances that require re-authentication, such as role changes, authenticator or credential changes and privileged function execution, and whether the list is documented and approved.	The written list of re-authentication triggers, the IA-11 organization-defined parameter values, and system audit records showing re-authentication events.	The list is missing a trigger that the platform supports, or the list names triggers that no audit record ever shows.
Interview: operations personnel and administrators	Whether system operations staff and system and network administrators can explain the defined triggers and how re-authentication is enforced in daily operations.	Named role descriptions, runbooks for identity provider and session settings, and records of how administrators handle re-authentication prompts.	Staff describe a trigger that differs from the documented list, or administrators cannot say which privileged actions prompt re-authentication.
Test: identification and authentication mechanisms	Whether the mechanisms that implement identification and authentication actually force re-authentication when a defined trigger occurs, in the configured environment.	Configuration exports from the identity provider and applications, and test results for each trigger, such as a role change or a privileged function call.	A configured rule does not fire for a listed trigger, or re-authentication applies to some applications but not to the ones that carry privileged functions.
Test: audit records for triggered events	Whether each triggered re-authentication produces a system audit record that identifies the user, the trigger and the outcome.	Sample audit log entries from the test window, with the log source and retention settings for those records.	Triggers occur without any audit record, or records omit the trigger type, which makes the evidence hard to match to the list.
Examine: alignment across methods	Whether the list, the interview answers, the configured behavior and the audit records all describe the same set of triggers.	A reconciliation table that maps each defined trigger to its configuration setting, test result and audit record.	The list, the configuration and the logs disagree, and the assessor records this as a gap against the single determination statement.

How to implement IA-11 re-authentication in five steps

This sequence turns the IA-11 requirement into a defined set of re-authentication triggers, configured challenges, tested evidence and a reviewed procedure that an assessor can follow from end to end.

Confirm the baseline and privileged functions
Start by confirming which SP 800-53B baseline your system is categorized under, since IA-11 applies to the low, moderate and high baselines but not the privacy baseline. Then inventory the system's privileged functions, role assignments and credential types, such as administrative consoles, role elevation and authenticator changes. The organization owns this inventory, and the output is a reviewed list of functions and the baseline it supports. The step is done when a named owner signs off on both.
Define re-authentication circumstances and parameter values
Decide which circumstances require the user to re-authenticate. IA-11 has one organization-defined parameter, so the organization must set the values it implements, such as role changes, authenticator or credential changes and execution of privileged functions. Record each circumstance with its rationale and the system components it covers. Security leadership approves the list, and the output is a written circumstances list that matches the parameter values an assessor will examine.
Configure the identity provider to challenge at each trigger
Configure the identity provider or application so that each defined circumstance forces a fresh authentication challenge. Where applications delegate sign-in to a provider such as authentik, confirm which provider or application settings support re-prompting and which triggers must be enforced in the application itself. Where directory-based single sign-on is used, as with FreeIPA, confirm how re-authentication interacts with existing sessions. Engineers make the change under change control, and the output is a configuration record for each trigger.
Test each trigger and capture audit records
Test every defined circumstance in a non-production environment, then repeat the key tests in production where the system allows it. For each trigger, confirm that the user is challenged, that an unsuccessful challenge blocks the action, and that the event produces an audit record with the user, time, function and outcome. Keep the test scripts, screenshots or logs and the matching audit entries together. Results are reviewed by the control owner, and the output is a test record that maps each trigger to its evidence.
Document the procedure, owner and review cycle
Write the re-authentication procedure so that administrators and assessors can follow it without the implementer present. Include the approved circumstances, the configuration steps, the test method, the named owner and the review frequency that the organization sets in its own policy. Link the procedure to the system security plan and to the IA-1 policy and procedures. The step is complete when the owner approves the document and the review date is recorded.

Which evidence passes an IA-11 re-authentication review

An assessor testing IA-11 wants to see that the organization decided which circumstances trigger re-authentication, configured those triggers, and proved they fire in practice. The cards below connect the decision record, the configuration, the test results, the audit trail, the procedure and the change history, so each claim can be traced to a artifact.

Approved list of circumstances and parameter values

IA-11 leaves the triggering circumstances to the organization, so the defined list is the foundation of the review. It should name each circumstance (for example, a change to a role, an authenticator or a credential, or execution of a privileged function), state the parameter values chosen for the IA-11 organization-defined parameter, and identify the system or platform each one applies to. Check that the list matches what the system actually enforces, not only what the policy describes.

Configuration exports showing triggers enabled

Exports from the identity provider or access layer show whether each defined trigger is actually switched on. For a self-hosted identity provider such as authentik, capture the relevant policy, stage or flow settings for each application and privileged action, with the export date and version. Assessors compare these exports against the approved list and look for gaps, such as a privileged function that bypasses the re-authentication stage.

Test records for each trigger

Each circumstance on the approved list needs a repeatable test that shows the system asks for re-authentication when that circumstance occurs. Record the test steps, the account and role used, the expected result, the actual result and the timestamp. Keep failed tests and the fixes that followed, because a clean history with no failures often prompts a closer look at how the tests were designed.

System audit records of re-authentication events

Audit records show re-authentication happening in production, not just in a test lab. Look for entries that tie a re-authentication prompt to the trigger that caused it, with the user identity, time stamp and outcome. Confirm that the logs are protected from modification and retained for the period the organization has defined. Where a platform does not log the trigger reason, record that gap in the POA&M.

Procedure and periodic review record

The procedure explains who defines the circumstances, who configures them, who tests them and how exceptions are approved. The review record shows that someone with responsibility for the identity system checked the list and configuration on the schedule the organization set, and recorded findings and owners. Assessors interview these people, so the procedure should match how the team actually works.

Change records when triggers are modified

Every addition, removal or change to a trigger should pass through the organization's change control process, with a reason, an approver, the affected roles or applications and a link to the updated test results. Changes made directly in the console without a ticket are a common finding. Ask the team to show a sample of recent changes and trace each one to its approval and retest.

What it costs to meet IA-11 re-authentication

This table compares the cost components of meeting IA-11, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written scope and to see which costs fall on your team, a partner or an independent assessor. NIST does not estimate compliance costs, so price each row from your own scope.

Cost component	Who is paid or who bears it	One-time or recurring, and what drives it
Identity platform licenses or self-hosted hosting	Your organization, to a software vendor or to your own infrastructure team	Recurring if licensed per user or per application; for self-hosted open-source identity providers such as authentik or FreeIPA, the recurring cost is hosting, operations and patching. Driven by user count, number of applications and high-availability design.
Engineering time to define triggers and configure re-authentication	Your identity engineers, or an implementation partner under a fixed-scope agreement	One-time for the initial setup, then recurring for changes. Driven by the number of defined triggers (role changes, credential changes, privileged functions), the number of applications that must enforce them, and how many use the identity provider for sign-in.
Testing and evidence capture	Your security or QA staff, or a partner preparing test scripts and records	One-time per trigger and application, repeated after material changes. Driven by how many triggers and privileged functions must be tested and whether audit records are captured automatically or by hand.
Ongoing evidence upkeep	Your compliance owner and system administrators	Recurring. Keeping the list of defined circumstances current, retaining audit records and re-running tests after changes. Driven by change frequency and how much of the evidence is generated by the platform.
External review or penetration testing	A specialist testing firm, if you choose to commission one	Optional and periodic. Driven by the scope of applications under test and whether re-authentication is included in a wider authentication test. Confirm the scope in writing before testing starts.
Auditor sampling and assessment	Your independent assessor or authorizing body, not DeployOpen	Recurring at each assessment cycle. Driven by the number of triggers, the number of systems in scope and how cleanly your evidence maps to the assessment procedure. Ask the assessor for their sampling approach before fieldwork.

Which self-hosted open-source identity tools can support IA-11 evidence

IA-11 is tested by looking at the circumstances the organization defined and whether the systems enforce re-authentication when those circumstances occur. The two tools below sit at different layers of that chain, so the assessor's questions differ for each.

authentik as the identity provider

authentik is an MIT-licensed identity provider. Applications delegate sign-in to it through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers. For IA-11, the key question is which re-authentication triggers each provider type can enforce, such as forcing a fresh login before a role change takes effect or before a privileged action runs. Some triggers may sit in the application instead of the provider, so confirm each trigger per provider type in your own test environment before writing it into the system security plan.

FreeIPA for Linux and UNIX sign-in

FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. It fits organizations whose privileged access runs through host logins, sudo rules and Kerberos tickets. Evidence for IA-11 would come from ticket lifetimes, re-authentication prompts and access rules tied to the defined circumstances. Its GPL-3.0-or-later license is a caveat: have counsel review how the license applies to your distribution and deployment model before you build the service into a regulated product.

Provider configuration as evidence

Assessors will want the exported configuration that shows which re-authentication triggers are set, not a verbal description. For either tool, capture the provider or policy settings, the version in use and the change history that shows when a trigger was added or altered. Store these exports with the list of circumstances the organization defined, since the examine method for IA-11 depends on that list matching what the system actually enforces.

Audit records of re-authentication events

The examine method for IA-11 includes system audit records. Confirm that your identity platform writes an event each time a re-authentication challenge is issued, passed or failed, and that the event carries the user, the application, the trigger and a timestamp. Without those fields, you cannot show that a defined circumstance produced a challenge. Check the log destination, retention and access controls with the same care you apply to any AU evidence source.

Test coverage for each defined circumstance

The interview and test methods require personnel to explain the system operations and show the mechanisms in action. Build a short test matrix with one row per defined circumstance, such as a role change, a credential change or a privileged function. For each row, record the test user, the expected challenge, the observed result and the log entry. Rows with no observed challenge are findings, and they should appear in the plan of action and milestones.

Interaction with IA-2 and AC-3

IA-11 is related to IA-2, IA-3, IA-4, IA-8, AC-3 and AC-11 in the catalog. Re-authentication only helps if the identity that is challenged is the one that was authenticated, and if access enforcement honors the new role or credential. Map which control each tool's settings support, so the evidence for IA-11 is not reused for controls it does not actually test. Ask your assessor early which related controls they will examine alongside IA-11.

Who does what for IA-11: your team, a partner and the auditor

Your organization owns IA-11. NIST makes the re-authentication circumstances an organization-defined parameter, so the decision about which events force a user to prove identity again belongs to you, not to a vendor or an assessor. Your security and identity owners decide what counts as a trigger, accept the residual risk of any circumstance you leave out, and keep the list current as roles, systems and threats change.

Circumstances list: Define the events that require re-authentication, such as role changes, authenticator or credential changes and execution of privileged functions, and record the value in the control documentation.
Risk decision: Decide which triggers are mandatory, which are optional and what happens when a user cannot complete re-authentication, and record the approver.
Periodic review: Set a review cycle for the list and re-review it after major identity platform, role model or incident changes.
Operating ownership: Assign a named owner who answers assessor questions about the list and its enforcement.
Procedure approval: Approve the written procedure that a partner drafts, so the organization can stand behind what the system does.

Check that the circumstances list is approved by someone with authority over identity risk and that the review date is on a calendar someone actually watches.

IA-11 re-authentication questions buyers ask before hiring help

How much effort does IA-11 re-authentication take to implement?

Most of the effort comes from deciding what the organization wants to re-authenticate for, not from the mechanism itself. IA-11 leaves the circumstances to the organization, so the work starts with a written list of triggers such as role changes, credential changes and privileged function execution. The effort then depends on how many applications sit behind the identity provider, how many of them already support step-up or re-prompt behavior, and how many privileged actions need to be identified in each system. Organizations with a small number of applications on one identity provider usually have less to change than those with many local logins. Ask any partner to break the effort into defining triggers, configuring each system, testing, and producing the evidence an assessor will request.

What sets the timeline for IA-11 work?

The timeline is set by the number of systems in scope, the state of the identity stack, and how quickly the organization can agree on its re-authentication triggers. Approval of those triggers often takes longer than configuration. Systems that already delegate sign-in to a central identity provider can usually be changed faster than systems with local accounts. Testing and evidence collection also add time, because each trigger needs a documented test showing that re-authentication happens and is logged. A written, fixed scope with agreed deliverables and milestones is the best basis for a timeline, and it should name the systems, the triggers and the evidence for each.

What does the client team need to provide for this work?

The client team owns the control, so it must supply decisions and access. Expect to provide:

Named owners who can approve the list of re-authentication circumstances and the timing for each
Administrative access to the identity provider, the applications in scope and their audit logging
Current documentation of roles, privileged functions and credential lifecycle processes
A test window in non-production and production environments, and someone who can confirm the results

Without these inputs, the implementation partner cannot finalize configuration or produce evidence that matches the organization's actual practice. Confirm the exact list of inputs in the written scope before work starts.

Can a small team implement IA-11 without outside help?

A small team can implement IA-11 alone if it has someone who understands the identity provider, the applications involved and the organization's own assessment expectations. The harder parts are usually the ones that need an outside view: writing defensible triggers, testing each application's re-authentication behavior and assembling evidence in the form an assessor expects. Small teams often find that the design work and test records take more time than the configuration. A partner can cover some of that work under a fixed scope, while the organization keeps decision rights. Whatever the split, the organization remains responsible for the control and for choosing which evidence to present.

Does IA-11 require changing our identity provider?

No. IA-11 does not name a product, and an organization can meet it with its existing identity provider if that system can enforce re-authentication for the defined circumstances and log the events. Open-source options such as authentik, which acts as an identity provider for applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, and FreeIPA, which provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, are examples of platforms that can serve this role. A change is worth considering only when the current system cannot enforce the chosen triggers or cannot produce usable audit records. Confirm each candidate's re-authentication support with the vendor or project before deciding.

How do I choose between an implementation partner and an auditor for IA-11?

An implementation partner and an auditor do different jobs, and they should not be the same party. The partner prepares systems, configuration and evidence, and the organization owns the control. An independent auditor or assessor tests the control and issues any report or conclusion. DeployOpen prepares systems and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. When comparing options, ask each candidate for a written scope listing systems, triggers, deliverables and the evidence they will produce, and confirm that any assessment is performed by a separate, independent party. Be wary of anyone who offers to guarantee an assessment outcome.

How DeployOpen scopes and prepares IA-11 evidence

DeployOpen plans, implements, integrates and documents self-hosted open-source identity platforms inside the client's own infrastructure. For IA-11, we work with the organization to define its re-authentication circumstances, configure the systems that enforce them, and prepare the evidence an independent assessor will examine.

How we scope

Agree in writing which systems, applications and privileged functions fall within IA-11 Re-authentication scope.
Record the organization-defined circumstances, such as role changes, credential changes and privileged function execution, as scoped inputs.
Confirm with the organization which parts of the control it owns and where an implementation partner prepares systems and evidence.

How we build

Configure re-authentication prompts in the identity provider, such as authentik, for the defined circumstances across integrated applications.
Integrate directory and Kerberos services, such as FreeIPA where used, so that privileged functions trigger the agreed re-authentication steps.
Test each configured circumstance and retain audit records that show when re-authentication was required and completed.

How we hand over

Deliver a written record of the organization-defined circumstances, the configuration settings that enforce them and the test results.
Map the evidence to the SP 800-53A examine, interview and test methods so the organization and its assessor can trace each item.
Document operating procedures for administrators so the organization can run and review re-authentication settings after handover.

How we support

Support is available as a retainer for upgrades, configuration changes and periodic re-testing of re-authentication behavior.
Revisit the defined circumstances when roles, applications or identity providers change, and update the evidence to match.
Work with the organization's assessor on questions about how the prepared evidence maps to IA-11, while the assessor issues any findings or reports.