IA-10: Adaptive Authentication

IA-10 requires you to enforce adaptive authentication: users must perform a defined authentication action (for example, step-up MFA) when specific conditions are met (for example, elevated risk signals). To operationalize it quickly, define the triggers, map them to concrete authentication responses in your IAM stack, and retain evidence that the policy is enforced and reviewed. ¹

Key takeaways:

• Document what “adaptive” means in your environment: risk signals (conditions) and required auth responses. ¹
• Implement conditional access + step-up authentication for the in-scope systems and access paths, then test it like a production control. ²
• Keep assessor-ready evidence: policies, configurations, logs, and periodic reviews showing the triggers and responses work as designed. ²

The ia-10: adaptive authentication requirement is a design-and-operation control that sits between “basic MFA everywhere” and “trust every login equally.” It expects you to require additional or different authentication actions when defined conditions occur, such as a suspicious login context, higher privilege, or access to sensitive workflows. The control is intentionally parameterized: you choose the authentication actions and the conditions, but you must define them explicitly and enforce them consistently. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat IA-10 like a measurable access policy: (1) identify the user populations and system entry points in scope, (2) define risk signals you will act on, (3) map each signal to a step-up requirement, and (4) prove it works with configuration exports and authentication event logs. If you already run an SSO/IdP, conditional access is usually the control plane. If you don’t, IA-10 becomes a forcing function to standardize authentication rather than letting each application invent its own rules. ²

Regulatory text

Control requirement (verbatim excerpt): “Require individuals accessing the system to employ {{ insert: param, ia-10_odp.01 }} under specific {{ insert: param, ia-10_odp.02 }}.” ¹

Operator translation: You must (a) specify the adaptive authentication action(s) required (the first parameter) and (b) specify the conditions that trigger those actions (the second parameter), then enforce that behavior for system access. The assessor will look for clear definitions, consistent enforcement in your IAM tooling and applications, and evidence that the control operates over time. ²

Plain-English interpretation

Adaptive authentication means the login experience changes based on risk or context. Low-risk access can follow your baseline authentication, while higher-risk access must trigger stronger authentication or additional checks (commonly “step-up MFA” or re-authentication). IA-10 does not tell you which exact signals to use; it requires you to define “specific conditions” and enforce an additional requirement when those conditions occur. ¹

A simple way to frame it for implementation:

• Baseline: what everyone must do for normal access (often MFA).
• Adaptive layer: what they must do again or differently when risk increases (step-up, phishing-resistant factor, device compliance requirement, or session restrictions). ²

Who it applies to

Entities: Federal information systems and contractor systems handling federal data commonly adopt NIST SP 800-53 controls as a baseline for authorization and continuous monitoring. ²

Operational context (where IA-10 shows up in audits):

• Centralized identity (SSO/IdP) controlling access to multiple applications
• Privileged access to admin consoles and cloud control planes
• Remote access (VPN/ZTNA) and access from unmanaged devices
• High-impact business workflows (payments, user administration, key management)
• Access paths exposed to third parties (contractors, support providers) ²

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

Step 1: Define scope and control owner

1. Name an IA-10 control owner (usually IAM lead, Security Engineering, or GRC with IAM as operator).
2. Define in-scope systems: start with SSO-protected apps, remote access, privileged tooling, and systems processing sensitive federal data.
3. Enumerate access paths: web SSO, API tokens, service accounts, break-glass accounts, mobile apps, and direct local logons where applicable. ²

Deliverable: IA-10 control statement with scope boundaries and ownership.

Step 2: Specify the adaptive authentication actions (parameter 1)

Choose what “employ” means in your environment and write it down as testable requirements. Common options:

• Step-up MFA at time of access
• Require phishing-resistant MFA for elevated conditions
• Re-authenticate before sensitive actions (privilege changes, key export)
• Require device compliance / managed device attestation for certain access
• Shorter session lifetime or forced re-authentication after risk events ¹

Deliverable: A table of adaptive actions that your IAM tools can enforce.

Step 3: Specify the conditions (parameter 2) as triggers

Define “specific conditions” using signals you can detect and log. Typical trigger categories:

• User risk: anomalous behavior, impossible travel, suspected compromised credentials
• Device risk: unmanaged device, failed posture checks, new device
• Network/location: new geo, anonymizer/TOR, unusual ASN, off-corporate network
• Resource sensitivity: privileged role access, production environment, sensitive dataset
• Transaction sensitivity: changing MFA settings, adding API keys, approving payments ¹

Deliverable: A trigger catalog with clear definitions (what event equals “new device,” what counts as “privileged,” what is “sensitive app”).

Step 4: Map triggers to actions (policy decision matrix)

Build a decision matrix that an auditor can read and an engineer can implement.

Example matrix (edit to match your environment):

• New device → step-up MFA + require device registration before access
• Privileged admin portal → phishing-resistant MFA each session
• High-risk sign-in → block or require step-up MFA + password reset
• Unmanaged device accessing sensitive app → deny or require managed device ²

Deliverable: “IA-10 Adaptive Authentication Policy” with the matrix and exceptions process.

Step 5: Implement in your IAM stack (and close app-level gaps)

Implementation patterns that usually satisfy IA-10:

• Configure conditional access policies in your IdP for SSO apps
• Enforce step-up via authentication context / assurance levels where supported
• For non-SSO apps, enforce via gateway, ZTNA, or application-native conditional auth
• Align privileged access with separate policy sets (admin portals, PAM) ²

Make exceptions explicit. If a legacy app cannot step-up, document compensating controls and a remediation plan, and isolate access via network controls or jump hosts.

Step 6: Validate the control with test cases

Write and run repeatable tests:

• Attempt login from a new device and confirm step-up occurs
• Attempt privileged action and confirm re-authentication occurs
• Attempt access from disallowed conditions and confirm deny/block behavior
• Confirm logs capture trigger evaluation and outcome (allow/deny/step-up) ²

Deliverable: Test scripts + results (screenshots, exported events, ticket references).

Step 7: Operationalize: monitoring, review cadence, and change control

• Monitor authentication events for bypasses, excessive failures, and policy “report-only” drift.
• Tie policy changes to change management: who can modify conditional access rules, approvals, and rollback.
• Perform periodic reviews of triggers, exceptions, and effectiveness based on incidents and system changes. ²

Required evidence and artifacts to retain

Keep evidence that shows design (what you intended) and operation (what happens in reality):

Design artifacts

• IA-10 control narrative (scope, owner, systems, and access paths) ²
• Adaptive auth policy decision matrix (triggers → required actions) ¹
• Exception register with justification, compensating controls, and end dates ²

Operational artifacts

• Conditional access / IdP policy exports (configuration snapshots)
• Screenshots of key rules (with names, assignments, and conditions visible)
• Authentication logs showing: trigger detected, step-up required, outcome recorded
• Test evidence for defined scenarios (date-stamped)
• Access review or governance records showing who can change policies and approvals ²

Program artifacts

• Mapping of IA-10 to control owner, implementation procedure, and recurring evidence artifacts (recommended best practice) ¹

Daydream note: teams often lose time chasing evidence at audit. Daydream can track IA-10 ownership, keep the decision matrix and exception register current, and schedule recurring evidence pulls so you can answer assessors fast.

Common exam/audit questions and hangups

Assessors tend to focus on these:

1. What are your “specific conditions”? If you can’t name them crisply, you will struggle to prove compliance. ¹
2. Is adaptive auth enforced everywhere in scope, or only for some apps? Partial coverage is acceptable only if scope and exceptions are explicit.
3. Can users bypass step-up by using legacy auth paths? Examples: direct app passwords, old VPN, service tokens.
4. Do logs prove the control works? Screenshots help, but event logs are harder to dispute.
5. Who can change conditional access rules, and how do you approve changes? Weak change control is a common failure pattern. ²

Frequent implementation mistakes and how to avoid them

Mistake 1: Treating “MFA everywhere” as IA-10.
Fix: keep baseline MFA, but add explicit triggers and step-up requirements tied to conditions. IA-10 requires conditional behavior. ¹

Mistake 2: “Risk-based” with no documented thresholds.
Fix: define what signals trigger step-up or denial. If you use IdP risk scoring, document which risk levels map to which actions.

Mistake 3: Policies exist, but are in report-only mode.
Fix: keep evidence that enforcement is active, and track any temporary report-only windows as time-bound changes.

Mistake 4: Excluding admins to reduce friction.
Fix: admins should have stricter triggers (privileged contexts are a primary reason IA-10 exists). Use PAM and phishing-resistant factors for privileged access. ²

Mistake 5: No story for third-party access.
Fix: define separate conditions for third party identities (contractors, support) and require stronger step-up, device controls, or restricted access paths.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for IA-10, so this page does not cite specific actions or penalties.

Practically, IA-10 failures show up as incident root causes: account takeover succeeds because the environment treats a high-risk login the same as a routine one, or because privileged actions do not require re-authentication. Your risk statement for leadership is straightforward: weak adaptive authentication increases the likelihood and blast radius of unauthorized access, especially for privileged and remote access paths. ²

A practical 30/60/90-day execution plan

First 30 days (Immediate foundation)

• Assign IA-10 owner and write the first control narrative (scope + systems + entry points). ²
• Inventory authentication paths and identify bypasses (legacy protocols, direct logins, local accounts).
• Draft the trigger catalog and decision matrix (conditions → actions). ¹
• Stand up an exception register and require approvals for exceptions.

Days 31–60 (Implement and prove)

• Implement conditional access policies in the IdP for highest-risk apps first: privileged portals, remote access, and systems handling sensitive data.
• Add step-up requirements for defined triggers, and validate with test cases plus log capture. ²
• Close common bypasses: disable legacy auth where feasible, restrict service accounts, and ensure admin access uses hardened paths.

Days 61–90 (Harden and operationalize)

• Expand coverage to remaining in-scope apps and non-SSO access paths using gateways/ZTNA or app-native controls.
• Put monitoring and change control around policy modifications; require peer review for rule changes.
• Package evidence: configuration exports, log samples, test results, and review records into an assessor-ready folder (Daydream can keep this organized across control cycles). ²

Frequently Asked Questions

Does IA-10 require MFA?

IA-10 requires you to define an adaptive authentication action and enforce it under specific conditions. MFA is a common action, but the control is written to allow different actions as long as they are defined and enforced. ¹

What are “specific conditions” in practice?

Conditions are risk or context signals you can detect, such as new device, unusual location, privileged role access, or high-risk sign-in outcomes from your IdP. Document the conditions precisely enough that an engineer can implement and an assessor can test. ¹

Can we satisfy IA-10 with our IdP conditional access policies alone?

Often yes, if the IdP is the enforcement point for the in-scope systems and you can show the trigger-to-action mapping plus logs proving enforcement. If some apps bypass SSO, you need compensating enforcement or documented exceptions. ²

How should we handle legacy applications that cannot do step-up authentication?

Put them behind a control point that can enforce the condition (SSO gateway, ZTNA, jump host), or document an exception with compensating controls and a remediation plan. Avoid silent gaps; auditors look for clear scoping and governance. ²

What evidence is most persuasive to an assessor?

A configuration export of the conditional access rules, paired with authentication event logs showing a real step-up event triggered by a defined condition. Add test cases and change approvals to show ongoing operation. ²

How do we keep IA-10 from becoming an administrative burden?

Standardize on a small set of triggers and responses, manage exceptions tightly, and automate recurring evidence collection. Daydream helps by mapping IA-10 to owners, procedures, and recurring artifacts so evidence stays current. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5