IA-10: Adaptive Authentication

Quick-reference card

What this control requires

IA-10 requires your organization to enforce supplemental authentication when user behavior or access conditions deviate from established norms. This requirement goes beyond standard login procedures. When pre-defined triggers fire, such as access from an unusual location, an abnormal volume of record requests, or activity outside a user’s typical role, the system must demand additional proof of identity before granting access.

In practice, this requirement means you can’t rely on a single authentication event at session start and assume that identity holds for the duration. Adaptive authentication treats identity confidence as dynamic, not static. Your identity and access management policies must define the specific circumstances that trigger supplemental checks and the specific techniques those checks employ.

Specifically, the control makes clear that adaptive authentication doesn’t replace multi-factor authentication (MFA). It augments MFA by adding context-aware layers that respond to risk signals in real time. The organization defines both the triggers and the supplemental mechanisms, which means your implementation must document what those are and why they were chosen.

Why it matters

Most organizations treat authentication as a gate at the front door and ignore what happens after a user is inside. Adversaries know this. Compromised credentials that pass an initial MFA check grant persistent access until the session expires, and that window is often hours long. IA-10 exists because static authentication, no matter how strong the initial factors, can’t account for compromised sessions or insider threats that emerge mid-session.

The result is direct audit exposure. Failure to maintain adaptive authentication controls introduces risk and may result in certification withdrawal or regulatory findings. If your organization undergoes a NIST SP 800-53 assessment and can’t demonstrate that supplemental authentication triggers are defined, documented, and operational, auditors will flag the gap. For organizations subject to FedRAMP or similar frameworks built on 800-53, that gap can stall or revoke authorization.

The risk compounds when you consider your vendor ecosystem. Third parties accessing your systems with static credentials represent a lateral movement path that your own security controls may never detect. Without adaptive triggers, a compromised vendor credential looks identical to a legitimate session.

What attackers exploit when adaptive authentication is absent:

• Credential stuffing and session hijacking where stolen credentials pass the initial MFA gate and grant unrestricted access for the session duration
• Privilege escalation through normal-looking access patterns where compromised accounts gradually access resources outside their typical scope without triggering any re-authentication
• Insider threats that evolve mid-session where a legitimate user accesses bulk records or sensitive systems that fall outside their established behavioral baseline
• Lateral movement from third-party entry points where vendor accounts with static authentication provide persistent footholds into zero trust environments that were designed to prevent exactly that

How to implement

Adaptive authentication fails most often not because organizations lack the technology, but because they never define the triggers and supplemental mechanisms that IA-10 requires. Without those organization-defined parameters, you have a policy that says “do adaptive auth” and an implementation that does nothing.

For your organization

Start by identifying your organization-defined parameters. IA-10 requires you to specify both the circumstances that trigger supplemental authentication and the techniques those triggers invoke. Document these parameters in your system security plan and make them auditable.

In practice, this step means mapping your trigger conditions to observable risk signals. Common triggers include access from a new device or geographic location, requests for data volumes that exceed the user’s historical baseline, access attempts outside normal working hours, and role-inconsistent resource requests. Your identity provider or access management platform should be capable of evaluating these signals in real time.

Beyond triggers, specify your supplemental authentication mechanisms. These might include step-up MFA challenges, out-of-band verification through a separate channel, knowledge-based authentication, or biometric re-verification. The mechanism should be proportional to the risk signal. A login from a new city might warrant a push notification, while a bulk data export from a privileged account might require manager approval combined with biometric confirmation.

In practice, this integration requires connecting your identity provider with your security information and event management (SIEM) system or user and entity behavior analytics (UEBA) tooling. The adaptive layer needs behavioral baselines to detect deviations, and those baselines require historical access data. Build the baseline collection period into your implementation timeline.

Where this breaks down is in calibration. Common mistakes include setting triggers so broadly that users face constant friction, which leads to workarounds, and setting them so narrowly that they never fire. Test your trigger thresholds against real access logs before deploying. Also, don’t confuse adaptive authentication with conditional access policies that only evaluate risk at login. IA-10 requires supplemental checks that can activate during an active session, not just at the front gate.

For your vendors

When assessing vendors against IA-10, your questionnaire should go beyond asking whether they support adaptive authentication. Ask for specifics.

Key questions to include in your vendor assessment:

• What specific circumstances or behavioral triggers does your platform evaluate to invoke supplemental authentication?
• What supplemental authentication techniques are available, and which are enabled by default?
• Can your organization provide documentation showing the defined triggers and mechanisms referenced in your system security plan?
• How are adaptive authentication events logged, and can those logs be shared during assessments?
• Does your adaptive authentication operate during active sessions or only at the point of initial login?

In practice, the evidence to request includes the vendor’s system security plan sections covering IA-10 parameters, configuration screenshots showing enabled triggers and supplemental mechanisms, and audit logs demonstrating that adaptive authentication events have actually fired in production.

Where this assessment reveals gaps, red flags include vendors who claim “we use MFA” as their IA-10 response without distinguishing between static MFA and adaptive supplemental checks. Another warning sign is a vendor who can’t articulate their defined triggers, which suggests the control exists on paper but not in practice. Vendors who can’t produce audit logs showing adaptive events have fired are also a concern, as it may indicate the capability is configured but has never activated.

Specifically, verification beyond self-attestation should include requesting a live demonstration of an adaptive trigger firing, reviewing audit logs for actual adaptive authentication events over the past quarter, and confirming that the vendor’s documented triggers align with what’s configured in their production environment.

How UpGuard helps

UpGuard provides capabilities that support the monitoring, assessment, and verification activities IA-10 requires across both your organization and your vendor ecosystem:

• Vendor Risk: Assess whether third-party vendors have defined and implemented adaptive authentication controls through automated questionnaire workflows, continuous monitoring, and evidence collection that validates IA-10 compliance beyond self-attestation.
• User Risk: Detect compromised credentials and anomalous user behavior that should trigger supplemental authentication challenges, providing the behavioral baseline and risk signal visibility that IA-10’s adaptive layer depends on.
• Breach Risk: Monitor your external attack surface for credential exposures and suspicious access patterns that indicate authentication mechanisms may have been compromised, surfacing the risk conditions that warrant IA-10 adaptive triggers.

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently configured for IA-10. As mappings are confirmed, they will be added to this section.

Related controls

• IA-02 — Identification and Authentication (Organizational Users): Establishes the baseline authentication requirements for organizational users that IA-10 supplements with adaptive, context-aware checks when risk conditions change during a session.
• IA-08 — Identification and Authentication (Non-organizational Users): Covers authentication for external users and third parties, whose access patterns often present the highest-risk triggers for the supplemental authentication mechanisms defined under IA-10.
• IA-05 — Authenticator Management: Governs how authentication credentials are issued, maintained, and revoked, directly affecting the strength and availability of the supplemental authenticators that IA-10 triggers invoke.
• IA-11 — Re-authentication: Requires periodic or event-driven re-authentication, complementing IA-10’s risk-based supplemental checks with time-based session validation.
• AC-17 — Remote Access: Controls remote access methods and monitoring, providing a key risk signal source for adaptive authentication triggers such as unusual geographic locations or untrusted network connections.
• SI-04 — System Monitoring: Supports the behavioral baseline and anomaly detection capabilities that IA-10 relies on to identify suspicious access patterns warranting supplemental authentication.
• AU-02 — Event Logging: Defines which events are logged, including the adaptive authentication trigger activations and supplemental challenge outcomes that auditors examine when assessing IA-10 compliance.

Frequently asked questions

What is NIST SP 800-53 IA-10?

IA-10 is the NIST SP 800-53 control that requires organizations to enforce supplemental authentication techniques when specific, pre-defined risk conditions are detected during a user session. Unlike static authentication that evaluates identity only at login, IA-10 mandates that organizations define both the circumstances that trigger additional checks, such as unusual access patterns or suspicious network locations, and the supplemental mechanisms those checks employ. The control applies to the Identification and Authentication family and augments existing MFA rather than replacing it.

What happens if IA-10 is not implemented?

Without IA-10 implementation, your organization lacks the ability to challenge suspicious behavior after initial authentication succeeds, leaving compromised sessions undetected until the access window closes. Auditors evaluating your system against NIST SP 800-53 will flag the absence of defined supplemental authentication triggers and mechanisms as a control deficiency. For organizations operating under frameworks built on 800-53, such as FedRAMP, this gap can result in authorization delays, conditions for continued operation, or revocation of existing authorization status.

How do you audit IA-10?

Auditing IA-10 requires verifying that the organization has documented specific circumstances triggering supplemental authentication and the specific techniques those triggers invoke, then confirming those definitions are implemented in production. Review the system security plan for the organization-defined parameters, examine system configuration settings to confirm triggers are active, and pull audit records showing that supplemental authentication events have actually fired. The audit should also validate that the defined triggers align with the organization’s risk profile, meaning the thresholds aren’t set so high that the adaptive layer never activates.

What is the difference between adaptive authentication and multi-factor authentication?

Multi-factor authentication requires users to present multiple forms of identity verification, typically at login, using a fixed combination of factors regardless of context. Adaptive authentication adds a dynamic, risk-based layer on top of MFA that evaluates contextual signals, such as device posture, access patterns, and behavioral baselines, to determine whether supplemental checks are needed during an active session. NIST SP 800-53 makes this distinction explicit in IA-10’s supplementary guidance, stating that adaptive authentication “does not replace and is not used to avoid the use of multi-factor authentication mechanisms but can augment implementations of multi-factor authentication.”