IA-10 Adaptive authentication: requirements and evidence

What IA-10 adaptive authentication asks for and why it sits outside every baseline

When an assessor or customer asks how your organization responds to suspicious logins, IA-10 is the control that answers the question. IA-10 requires individuals accessing the system to complete defined supplemental authentication techniques or mechanisms under defined circumstances, and the circumstances are aimed at compromised credentials, such as unusual access patterns. The organization decides both what the triggers are and what the extra step looks like. The control exists because an adversary who holds a valid password or session can log in as a legitimate user, and a single authenticator alone may not stop that. Your job is to define the situations that warrant a second check and show that the check runs when those situations occur.

Two facts shape how you scope this. First, SP 800-53B does not select IA-10 for the low, moderate or high baselines or for the privacy baseline, so it applies only if your organization tailors it into a baseline or an overlay requires it. Confirm this against the baseline profiles in the NIST OSCAL repository before you describe IA-10 as in scope. Second, IA-10 has two organization-defined parameters, which SP 800-53A labels IA-10_ODP[01] and IA-10_ODP[02]. Those values are yours to set and record in your system security plan, and an assessor will test whether the values you chose match what the system actually does.

The hard part is rarely the technology. Defining triggers is difficult because each one must be specific enough to test, such as a login from an unfamiliar network, an impossible-travel pattern, or a credential appearing in a breach feed, and broad enough to catch the abuse you care about without blocking staff every day. Choosing the method is the second decision: the supplemental step has to be one your identity stack can enforce for the affected systems. Before you commit, ask your identity team which triggers the platform can evaluate, which second factors it can enforce for each application, and what audit records the trigger produces, because the assessor will request those records under the examine method.

Which systems, users and decisions IA-10 applies to once you adopt it

IA-10 is not selected by any SP 800-53B baseline, so its scope begins with the tailoring decision or overlay that adds it. The cards below cover the decisions that define where supplemental authentication applies, and they connect to the boundaries already set by IA-2 and IA-8.

Applications and identity providers in the trigger logic

Decide which applications, single sign-on realms and upstream identity providers the adaptive rules cover. A central identity provider such as Keycloak or authentik can enforce the check for many applications at once, but applications that authenticate locally or accept direct logins sit outside that path unless you route them through it. Inventory every login path before writing rules, and confirm that each one passes through the component that evaluates the trigger.

Workforce users with standard access

Decide whether ordinary employee sign-ins fall under the defined circumstances or only the unusual ones. Adaptive rules applied to every workforce login generate friction, while rules applied only to anomalous sessions depend on the quality of the signals behind them. Document the population, the rule for each group, and how a user's normal pattern is recorded so the assessor can see why an access was or was not challenged.

Privileged accounts and administrative functions

Privileged users usually warrant the strictest defined circumstances, such as administrative sessions from new locations or changes to security settings. IA-2 already requires strong authentication for these accounts, so the question for IA-10 is which additional conditions trigger a step-up. Record which privileged actions require supplemental authentication and confirm that the authenticator validation for those actions is enforced rather than only logged.

Outside users and non-organizational accounts

Members of the public, partners and other external users are governed by IA-8, which shapes how they are identified and what authenticators they may use. Decide whether adaptive challenges apply to them, which may depend on the sensitivity of the service they reach. Confirm which second factors are available to external populations, because a rule that demands a method an external user cannot enroll in will block legitimate access.

Signals that define unusual access

Define the signals that move a session into a defined circumstance: for example, a login from an unrecognized device, an impossible travel pattern, a burst of failed attempts or a request for a sensitive resource. Each signal should be named, given an owner for its data source, and tested. The assessor will check that the organization-defined parameters for these circumstances are documented and that the mechanism acts on them.

Ownership of defined circumstances and parameters

Assign an accountable owner for the defined circumstances and the two organization-defined parameters for IA-10 (IA-10_ODP[01] and IA-10_ODP[02] in SP 800-53A). The owner approves changes to the rules, reviews exceptions and keeps the record that the assessor will examine. Confirm that the same person or committee also owns the related IA-2 and IA-8 decisions, so that changes to the boundary are reviewed together.

How an assessor tests IA-10 under SP 800-53A

This table breaks down the single determination statement for IA-10 and the examine, interview and test methods that SP 800-53A Rev. 5 pairs with it. Read each row as what the assessor looks at, what they ask you to show, and where findings usually arise. The assessor, not DeployOpen, reaches the conclusion on whether the control is satisfied.

Assessment method	What the assessor looks at	Evidence requested	Common findings
Determination statement (1)	Whether the organization defined the circumstances that trigger supplemental authentication and the techniques or mechanisms used, then implemented them	Written definition of the trigger conditions, the selected supplemental techniques, and the values chosen for the two organization-defined parameters	Circumstances left undefined, or triggers described only in general terms such as suspicious activity
Examine	Supplemental identification and authentication techniques or mechanisms, and their configuration against the defined triggers	Configuration exports from the identity provider, authenticator policy or flow definitions, and records of the defined circumstances	Policy says step-up applies to risky logins, but no rule in the platform matches that definition
Examine (audit records)	System audit records showing when supplemental authentication was required, presented, passed or failed	Sample log entries covering trigger events, challenge outcomes and fallback paths for a defined period	Logs do not capture which trigger fired, so the assessor cannot confirm the control operated
Interview	Organizational personnel with system operations responsibilities explaining how triggers are reviewed and tuned	Named roles, responsibilities, and a walkthrough of how a trigger is changed and approved	Operators describe triggers from memory that differ from the documented configuration
Interview (administrators)	System and network administrators describing how the mechanisms are deployed, maintained and bypassed in emergencies	Break-glass procedure, admin change records, and how exceptions to the supplemental check are approved	Emergency bypass exists informally with no record of who used it or when
Test	Mechanisms supporting and implementing identification and authentication, exercised against the defined circumstances	Test scripts and results showing a simulated unusual access pattern triggers the supplemental challenge, plus a failed-challenge case	Tests cover only the happy path, so the trigger and denial behavior were never exercised
Test (scope of triggers)	Whether each defined circumstance has been tested, not only the most common one	Test matrix mapping each trigger to a test case and its result date	Newly added triggers were configured after the last test and never retested

How to implement IA-10 in sequence, with the output of each step

This sequence moves IA-10 from a tailoring decision to a documented, tested supplemental authentication rule, with a named output at every step so an assessor can trace the control from intent to evidence.

Confirm the tailoring decision or overlay
IA-10 is not selected in any SP 800-53B baseline, so the first step is a documented decision by the system owner and authorizing official to add it. That decision may come from a tailored baseline or from an overlay that applies to the system. Record the rationale in the system security and privacy plan, tying it to the risk that adversaries may use compromised authenticators. The output is a tailoring record that names IA-10 as an added control and cites the reason for adding it. Confirm with your own governance team whether an overlay already covers this control for your system type.
Define the organization-defined parameters
IA-10 has two organization-defined parameters: the circumstances or situations that trigger supplemental authentication, and the supplemental authentication techniques or mechanisms used when a trigger fires. The security team writes these values in a parameter record, with each circumstance stated specifically enough to test, such as access from an unrecognized device, an impossible-travel pattern, or a privileged action from an unusual network. The record names the approved supplemental mechanisms and who may change them. It is done when the control owner signs the record and the parameter values match the wording in the system security plan.
Map each circumstance to a detection signal
For each circumstance in the parameter record, identify the signal your identity provider or access logs can actually observe, such as device fingerprint, geolocation, client network, login velocity, or risk score from an upstream tool. Where a signal is not available, mark the circumstance as unsupported and either change the parameter or document a compensating control. The output is a trigger matrix that lists circumstance, signal, data source, and owner. Confirm each signal in your own environment, because product capabilities differ by version and deployment.
Configure the supplemental authentication factor
Configure the identity platform so that the defined supplemental technique runs only when a trigger condition is met. In authentik, for example, the authenticator validation stage checks enrolled second factors during login, including TOTP apps, WebAuthn and FIDO2 passkeys, email codes and static recovery codes, and it can be bound to policies that decide when it runs. Keycloak and Zitadel can apply conditional flows through their own policy or brokering configuration. Export the flow or configuration as code or a file so the change is versioned and reviewable. The output is a configuration export tied to the trigger matrix.
Test triggers and failure paths
Run a scripted test plan that exercises each trigger in the matrix, plus the negative case where a normal login should not prompt for the supplemental factor. Include failure paths: a user who cannot complete the supplemental check, an enrolled device that is lost, and a recovery code that has been used. Record the expected result, the observed result, the log entry produced, and the tester. The output is a test log that shows each circumstance produced the defined response. Keep the logs for assessors, since the assessment procedure for IA-10 examines audit records and tests the mechanisms.
Document, approve and review the procedure
Turn the parameter record, trigger matrix, configuration export and test log into an approved procedure that operations staff can follow, including who responds to a failed supplemental check and how exceptions are recorded. Assign an owner and a review trigger, such as a change to the identity platform, a new application, or a finding from incident review. The output is an approved procedure with version history. Confirm the review frequency required by your own program or authorizing official, since the control statement does not set it for you.

Which evidence passes an IA-10 test and how to keep it current

An assessor testing IA-10 will look for a chain of records: the organization's chosen parameter values, the configuration that enforces them, logs that show the behavior, test results that prove the trigger and failure paths, and a change history. No single artifact carries the test on its own, so each card below names what it proves, how often it should be refreshed between formal assessments, and who should own it.

Documented parameter values

IA-10 has two organization-defined parameters: the circumstances that trigger supplemental authentication and the techniques or mechanisms used. The documented values should be written down in the system security plan or the authentication standard, with the rationale for each trigger, such as unusual access patterns or access from a new device. Check that the document names the same values the identity provider enforces. Refresh at least at each annual review and whenever the threat picture changes. The control owner, usually the identity or security governance lead, signs off.

Identity provider configuration export

The configuration shows the trigger conditions and the supplemental factor that an assessor can compare with the documented values. For example, a risk-based login policy in the identity provider can route flagged sign-ins to a second-factor step, and an authenticator validation stage can list the factors it accepts, such as TOTP, WebAuthn or recovery codes. Export the configuration as a dated file, store it under version control, and confirm the exported settings match the running system. Refresh after every change and at least quarterly. The platform engineering team owns the export.

Sample audit records for triggered and untriggered logins

Audit records should show that the supplemental step fired when a defined circumstance occurred and did not fire for ordinary sign-ins. Pull a sample of both types, including the risk signals that caused the trigger, the factor used and the outcome. Confirm that the records are protected and retained for the period the organization's audit policy sets. Ask the team to confirm whether the identity provider logs the trigger reason; if it does not, the evidence is weaker. Pull samples at least monthly. The security operations team owns the extraction and review.

Trigger and failure test results

Testing shows the control works under both expected and adverse conditions. Test cases should cover a sign-in that meets a defined trigger and must be challenged, a sign-in that does not meet it and must not be challenged, a failed or missing second factor that must block access, and a recovery path that cannot bypass the step. Record the test inputs, expected and actual results, and the tester. Repeat tests after configuration changes and at a regular interval. Testing is typically performed by the security testing or QA team, and an independent tester strengthens the record.

Change records for revised circumstances

When the organization changes a trigger, adds a factor or removes one, the change record should link the decision, the approver, the reason and the date to the updated configuration and parameter values. This shows that the control is maintained rather than set once. Records should also show when a new risk pattern led to a new trigger. Review change records at each assessment cycle and whenever a significant change occurs. The change advisory or configuration owner maintains them, and the security lead approves changes that alter the trigger logic.

What meeting IA-10 costs in money and effort

This table breaks the cost of meeting IA-10 into its components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to structure a written quote request, since no price or duration is published for this control and every figure depends on your scope.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Identity platform or second-factor licenses	Vendor or reseller for commercial products; none for self-hosted open source, which still needs infrastructure	Recurring for commercial subscriptions; open-source licenses carry no fee but hosting is ongoing	Number of applications, identity providers and user populations; confirm per-user or per-tenant pricing with each vendor
Engineering time to define parameters and triggers	Internal security or identity team, or an implementation partner under a written scope	One-time, with revisions when risk appetite or threats change	Number of IA-10 organization-defined parameters to set (two in SP 800-53A) and how many circumstances must be modeled
Configuration of signals and step-up flows	Internal platform engineers or an implementation partner	One-time per application and identity provider, plus change work	Count of applications and identity providers; whether signals come from one source or several logs
Test effort	Internal testers, or a security testing provider for independent testing	One-time for initial testing, recurring after each change to triggers or factors	Number of trigger scenarios, user journeys and fallback paths that must be exercised
Evidence upkeep	Internal compliance or operations staff	Recurring, as configuration, audit records and test results must stay current	Log retention settings, number of systems producing records and how often triggers are reviewed
External testing or review	Independent testing provider or consultant, billed under a separate scope	Usually one-time per assessment cycle, with retainers available for continuous testing	Depth of testing requested, number of in-scope systems and whether AI or agent-driven access is included
Auditor sampling time	Independent assessor or certification body, paid by the organization	Recurring at each assessment cycle	Number of samples the assessor selects, how many trigger events exist in audit records and how well evidence is organized

Which self-hosted open-source platforms can produce IA-10 evidence

IA-10 is satisfied by the identity platform that actually challenges users for supplemental authentication, so the choice of platform determines what evidence can be produced. The four tools below differ in whether they hold the second factor themselves, sit in front of applications as a single sign-on layer, or broker logins to providers the organization already runs.

authentik authenticator validation

authentik (MIT) runs an authenticator validation stage during login that checks enrolled second factors, including TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes. For IA-10, the evidence is the flow configuration showing which stage runs under which conditions, plus login event logs showing when the supplemental check fired. Confirm in your own environment which factors you permit for high-risk circumstances, and whether SMS or email codes are acceptable under your defined conditions.

FreeIPA OTP tokens

FreeIPA (GPL-3.0-or-later) supports two-factor authentication with HOTP and TOTP tokens, including software tokens enrolled by QR code and hardware tokens such as YubiKeys. It can also proxy OTP checks to an existing RADIUS server during migration, which matters when older access paths still depend on that server. Its OTP capability is a second factor for enrolled users, so IA-10 evidence depends on your own rules for when that factor is required. Confirm whether every trigger you define can be enforced through FreeIPA policy or needs a separate component.

Keycloak single sign-on

Keycloak (Apache-2.0) provides single sign-on, so users authenticate once with Keycloak rather than separately with each application, and it supports OpenID Connect, OAuth 2.0 and SAML 2.0. It can also broker logins to existing OpenID Connect or SAML 2.0 identity providers. Because the central point sees every application login, it is the natural place to define conditional step-up rules and to log them. Confirm that the applications you protect actually route through Keycloak, since an application that keeps local passwords falls outside any rule set there.

Zitadel identity brokering with AGPL duties

Zitadel (AGPL-3.0-only) acts as a central identity broker, so users can sign in through external providers such as Google, Microsoft Entra ID or Okta over OpenID Connect, SAML 2.0 or LDAP. The AGPL-3.0-only license requires that if you modify Zitadel and make it available to users over a network, you must offer those users the corresponding source of your modified version. Take legal advice before deploying a modified build in a customer-facing service. For IA-10, confirm whether the supplemental check happens in Zitadel or at the upstream provider, because the evidence must come from whichever system enforces it.

Who owns IA-10 work: your team, an implementation partner and the auditor

Your organization owns IA-10. The control is only meaningful once someone has decided which supplemental authentication techniques apply and in which circumstances they trigger, and that decision belongs to the people accountable for the system's risk. Your security and identity leaders set the organization-defined parameters (the two IA-10 values the organization assigns or selects when it implements the control), accept residual risk and sign off on the design.

Parameter decisions: Choose the defined techniques, such as a second factor, and the defined circumstances, such as a new device, an unusual location or a high-risk action.
Risk acceptance: Document which access patterns you accept without step-up and who approves that exception.
Operating procedures: Assign owners for alert triage, user help desk handling and periodic review of the rules.
Sign-off: Approve the system security plan language and the final parameter values before testing begins.
Ongoing ownership: Review trigger logic after changes to identity providers, applications or user populations.

Before engaging anyone, confirm in writing which of these decisions you will keep internal and which you will ask a partner to draft for review.

Where IA-10 programs usually fall short and how to close each gap

IA-10 programs tend to fail in the places between policy and production: parameters that never reach configuration, signals nobody records, and bypass paths nobody tested. The cards below cover the gaps assessors most often find and the fix for each, so the organization can show that its supplemental authentication works as written.

Parameters defined but not configured

IA-10 has two organization-defined parameters, which the organization must set to say which users, circumstances and supplemental techniques apply. Policies often name these values, but the identity platform still runs a generic login flow. Compare each defined value against the live flow definition and policy bindings, and record the mapping so an assessor can trace a parameter to the setting that enforces it.

Triggers built on unlogged signals

A step-up rule that depends on login location, device posture or failed-attempt counts is only as good as the data behind it. Many teams discover that the identity provider does not retain the signal, or that the signal is in a log nobody reviews. Before relying on a trigger, confirm the signal is captured, retained for a defined period and reachable by the rule engine, and test that a simulated unusual access pattern actually raises the challenge.

Legacy protocols that skip the second factor

Supplemental factors are frequently enforced on the web sign-in page while older paths still accept a password alone, such as direct LDAP binds, legacy mail clients or API tokens issued without a challenge. An adversary who holds a compromised password will choose the weakest path. Inventory every authentication entry point for each application, route them through the identity broker where possible, and document any exception with a named owner and a compensating control.

No test evidence for the failure path

Assessors test IA-10 by examining the mechanisms and by testing them, so the team must show that the supplemental step actually happens. Teams often demonstrate the happy path only. Build test cases for a valid password from an unusual context, a missing or failed second factor, a lockout after repeated challenges and a fallback when the factor service is unavailable. Keep the test scripts, dates and results together so the assessment report can point to them.

Audit records without the reason for step-up

An audit record that shows a user passed a second factor does not explain why the challenge was required. When an incident responder or assessor asks why a session was challenged, the answer should be in the record. Configure the identity platform to log the triggering condition, the policy or stage that fired, the factor used and the outcome, and confirm that these fields reach the central log store with the same retention as other authentication events.

No owner for reviewing circumstances

The circumstances that trigger IA-10 reflect current threats, user populations and business travel patterns, and they drift over time. A rule written at deployment can quietly stop matching how people work or miss a new attack pattern. Assign a named owner for the list of circumstances, set a review cadence in the organization's policy, and keep a change record for each adjustment so the review itself becomes evidence.

What buyers ask before bringing in help for IA-10

Is IA-10 more work than IA-2?

Usually it is less work to document but more work to design, because IA-2 is a baseline control that most systems already address through multi-factor authentication, while IA-10 requires you to decide when extra authentication is triggered. The effort depends on how many circumstances you define, how many systems and entry points you must cover, and whether your identity provider can evaluate signals such as unusual locations, new devices, impossible travel or risky sign-ins. Each defined circumstance needs a rule, a tested response, an owner and an audit trail. Ask any provider to break its estimate down by circumstance, by system and by identity provider integration, because those three counts drive most of the effort.

Does a baseline require IA-10?

No. SP 800-53B Release 5.2.0 does not select IA-10 for the low, moderate or high baselines or for the privacy baseline. It becomes required only when your organization or authorizing body adds it by tailoring a baseline or by applying an overlay that includes it. Before scoping work, confirm with your authorizing official, contract owner or compliance lead whether IA-10 appears in your system security plan or in any overlay you must follow. If it is not there, adding it is a risk decision rather than a compliance obligation, and the justification should be recorded.

How long does adaptive authentication take to implement?

The timeline depends on scope, and no reliable duration can be given without a written statement of work. The main variables are the number of identity integrations, whether an identity provider already supports risk-based policies, how many circumstances the organization defines and how long test windows and change approvals take. A fixed-scope engagement sets out deliverables and timelines in writing before work starts, so ask for a milestone plan that lists each integration, each defined circumstance, the testing window and the evidence package. Ask also what the plan assumes about client review cycles, because those often extend schedules more than technical work does.

What access and people does the work need from us?

The work needs administrative access to the identity provider, such as Keycloak, authentik, FreeIPA or Zitadel, sufficient to create authentication flows, policies and log exports. It also needs a named owner for each defined circumstance who can confirm what counts as unusual for their business, a security owner who approves the response for each circumstance, and test windows in which deliberate sign-in tests can run without triggering production lockouts. Confirm who holds break-glass accounts, how changes are approved and where logs are retained, because the assessor will examine these records. Missing owners are the most common cause of delay.

Can our own team implement IA-10 without a partner?

Yes, if your team has identity engineering skills and time to maintain the configuration. The SP 800-53A assessment procedure for IA-10 is a practical checklist: it covers one determination statement and examine, interview and test methods. Your team can use it to confirm that the defined supplemental techniques exist, that audit records capture when they trigger, that administrators can explain the circumstances and that the mechanisms work in testing. Many teams find the harder part is keeping definitions current as business patterns change. An outside partner is useful when the identity estate is complex, when deadlines are tight, or when you want an independent technical review before an assessment.

Can a partner certify that we meet IA-10?

No. An implementation partner can configure systems, prepare evidence and document how each step works, but only an independent assessor concludes whether a control is satisfied. For federal and contractor systems, that assessor is the one the authorizing body accepts, and the result appears in the assessment report and plan of action and milestones. DeployOpen plans, implements, hardens and documents self-hosted platforms in your environment and prepares evidence for assessment, but it does not issue audit reports, attestations or certifications. Ask any provider to state in writing which deliverables are preparation and which are assessor conclusions.

What are the ongoing costs after the first implementation?

Adaptive authentication is not a one-time build. Recurring costs include reviewing circumstances as user behavior and business operations change, tuning rules to reduce false positives, retesting after identity provider upgrades, keeping audit logs retained and reviewable, and updating the documentation that the assessor will examine. Each of these can be handled by your team or covered by a support retainer. When requesting a quote, ask which items are included in the initial scope, which are recurring, what triggers a re-test and who is responsible for monitoring the log evidence between assessments.

How DeployOpen scopes, implements and prepares IA-10 evidence

DeployOpen plans, implements and documents the supplemental authentication behavior that IA-10 Adaptive authentication asks for, inside the client's own infrastructure. The organization still owns the defined circumstances, the supplemental techniques and the risk decisions behind them, and an independent assessor tests the result.

How we scope

Agree in writing which systems, identity flows and defined circumstances fall within the IA-10 scope before work starts.
Record the organization-defined parameters IA-10_ODP[01] and IA-10_ODP[02] as client decisions, with DeployOpen recording the values that drive configuration.
Confirm which identity platform, such as authentik, Keycloak, Zitadel or FreeIPA, already fronts the in-scope applications.

How we build

Configure the chosen platform to challenge users with a second factor when defined unusual access conditions are met.
Enroll supported second factors such as TOTP apps, WebAuthn and FIDO2 passkeys, and verify each one during login.
Test the triggers and step-up prompts against the defined circumstances, including failure and bypass paths, in a non-production environment first.

How we hand over

Document the configured triggers, supplemental mechanisms, audit records and administrator procedures in a form the assessor can examine.
Provide test results showing each defined circumstance produced the expected supplemental authentication step.
Walk the organization's operations staff and system administrators through the procedures they will be interviewed about.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing of the adaptive authentication logic are available as a retainer.
Assessment decisions and the issuance of any report or certificate remain with the independent auditor or assessor, not DeployOpen.