IA-2(6): Access to Accounts —separate Device

IA-2(6): Access to Accounts —separate Device requires you to enforce multi-factor authentication (MFA) where one authentication factor is provided by a separate device for the defined access types and account populations in scope. Operationalize it by standardizing approved “separate-device” authenticators, enforcing them through your identity provider, and retaining evidence that proves coverage and enforcement. ¹

Key takeaways:

• Define “in-scope access” and “in-scope accounts” first; MFA architecture follows scope.
• “Separate device” means your MFA factor cannot live solely on the same endpoint being used to log in.
• Auditors look for enforcement proof (conditional access, auth method policy, logs), not policy statements.

The ia-2(6): access to accounts —separate device requirement is a specific MFA enhancement under NIST SP 800-53 Rev. 5 that pushes you beyond “MFA exists” toward “MFA resists endpoint compromise.” The operational intent is straightforward: if an attacker controls the user’s workstation (or the system used to authenticate), they should not automatically gain the second factor. That drives you to authenticator choices where the MFA factor is delivered or approved on a separate device (for example, a dedicated hardware token or a phone acting as an out-of-band approval device), and to technical enforcement that prevents weaker factors for the covered access paths.

For a CCO or GRC lead, the fastest route to implementation is to treat IA-2(6) as an access-policy engineering task with clear scoping, a short list of approved authenticators, and measurable enforcement. Your outcome should be provable: you can show which accounts and access types are covered, which authenticator methods satisfy the “separate device” constraint, and system settings/logs that demonstrate MFA is required and cannot be bypassed.

Regulatory text

Requirement excerpt: “Implement multi-factor authentication for {{ insert: param, ia-02.06_odp.01 }} access to {{ insert: param, ia-02.06_odp.02 }} such that:” ²

Operator interpretation of the excerpt: NIST provides the enhancement statement and expects you to fill in two organization-defined parameters:

1. the access types/contexts that must use MFA, and
2. the account set that must use MFA.
   IA-2(6) then adds the constraint that the MFA solution must use a separate device for at least one factor. ¹

What the operator must do:

• Decide what “access” is in scope (interactive logons, remote access, privileged access, SaaS access, administrative consoles, etc.).
• Decide which accounts are in scope (all users, privileged roles, service accounts where feasible, third-party users, break-glass accounts with compensating controls, etc.).
• Enforce MFA in a way that requires a factor coming from a separate device, and document how your chosen authenticators meet that requirement. ¹

Plain-English interpretation (what IA-2(6) really means)

You must require MFA, and the second factor cannot be “co-resident” on the same device used to authenticate in a way that collapses into single-factor when the endpoint is compromised. Practically, this means you should treat some forms of software-only MFA on the same endpoint as risky and be prepared to justify why your approach still meets the “separate device” intent.

A clean implementation pattern is: primary authentication on the endpoint + approval/cryptographic proof on a second device (hardware token or mobile device). Your policy should say which methods count as “separate device” in your environment, and your identity system should enforce that only those methods satisfy MFA for the in-scope access. ³

Who it applies to (entity and operational context)

This control is commonly applied to:

• Federal information systems implementing NIST SP 800-53 baselines. ³
• Contractor systems handling federal data where 800-53 controls are flowed down contractually or used for assessment. ³

Operationally, it matters most where compromise impact is high:

• Privileged admin access to infrastructure, identity systems, production workloads, and security tooling
• Remote access paths (VPN, VDI, SSO to SaaS)
• Third-party access into your environment (support portals, federated access, administrative jump hosts)

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

1) Define the two organization-defined parameters (ODPs)

Create a short scoping statement you can reuse in your SSP, IAM standard, and audit responses:

• ODP #1 (Access in scope): enumerate access types and protocols (for example: interactive user access to enterprise applications via SSO; administrative access to cloud consoles; remote access to internal network).
• ODP #2 (Accounts in scope): enumerate account populations (workforce users, admins, contractors, third-party support, shared accounts if any, emergency accounts).

Deliverable: a one-page “IA-2(6) Scope & Definitions” addendum owned by IAM/security with GRC review. ³

2) Define what “separate device” means in your environment

Write an internal definition that maps to authenticator categories you actually support. Example decision points:

• Separate-device compliant: hardware security keys; OTP hardware tokens; push approval on a phone that is not the endpoint being used to log in.
• Likely not compliant without strong justification: factors delivered to the same endpoint session with no out-of-band step, or methods that can be satisfied entirely by malware on the workstation.

Deliverable: “Approved MFA Methods Matrix” with a column that states “Meets IA-2(6) separate-device: Yes/No/Conditional” and the rationale.

3) Engineer enforcement in the identity layer (not per-app exceptions)

Implement enforcement where it is hardest to bypass:

• Centralize authentication through your IdP/SSO where possible.
• Configure conditional access / authentication policies that require MFA for the defined access and account scope.
• Restrict satisfaction of MFA to the approved “separate device” methods by disabling weaker methods or blocking them for in-scope groups.

Deliverable: screenshots/exports of IdP policies and authentication method configurations showing that MFA is required and constrained to approved methods.

4) Handle edge cases explicitly (auditors will ask)

Common carve-outs are acceptable only when documented with compensating controls:

• Service accounts: prefer non-interactive auth (keys/certs) and block interactive login; document why MFA is not technically applicable and what prevents misuse.
• Break-glass / emergency access: keep the account tightly controlled, monitored, and stored; document the rationale and controls around use.
• Legacy apps: front them with a gateway, SSO wrapper, or VDI/jump host that enforces separate-device MFA.

Deliverable: an “Exceptions Register” entry per carve-out, with risk acceptance owner and technical compensations.

5) Prove operation continuously (not “set and forget”)

Create recurring checks:

• Coverage report: in-scope accounts vs. MFA enrollment in approved methods
• Policy compliance: conditional access policy enabled, applied to correct groups, no “exclude all” patterns
• Authentication logs: sampling showing MFA challenges and success from separate-device method types

Deliverable: a monthly or quarterly control evidence packet.

6) Assign ownership and bake into joiner/mover/leaver (JML)

IA-2(6) fails operationally when users are created outside normal onboarding.

• IAM owns technical control.
• HRIT/IT owns enrollment workflow.
• GRC owns testing cadence and evidence quality.

Deliverable: RACI + procedure references for onboarding, role changes, and privileged access grants.

Required evidence and artifacts to retain

Maintain evidence that proves scope, enforcement, and operation:

1. Scope & definitions

• IA-2(6) scope statement (ODP #1 and ODP #2)
• “Separate device” definition and approved MFA methods matrix

2. Technical configuration

• IdP conditional access/authentication policy exports or screenshots
• MFA method enablement/disablement settings
• Group membership rules for in-scope populations (admins, remote users, third parties)

3. Operational proof

• MFA enrollment reports for in-scope users
• Authentication logs demonstrating MFA events for in-scope access
• Exception register entries with compensating controls
• Access review artifacts for privileged groups tied to the scope statement

4. Governance

• Control owner assignment
• Test procedure and last test results

Daydream tip (practical, not theoretical): store these artifacts as a recurring evidence collection with a named owner and a fixed cadence so you can answer assessors without scrambling. Daydream is a natural place to map IA-2(6) to the control owner, implementation procedure, and recurring evidence artifacts so the evidence packet stays consistent across audit cycles. ⁴

Common exam/audit questions and hangups

Expect these questions, and prepare short, evidence-backed answers:

• “Which access is covered?” Provide ODP #1 scope plus the policy object list (apps, admin portals, VPN).
• “Which accounts are covered?” Provide ODP #2 plus group lists and membership rules.
• “How do you know the second factor is a separate device?” Provide the approved methods matrix and show policy constraints that prevent non-compliant methods.
• “Show me it works.” Provide log samples and a live walkthrough of an in-scope login prompt that requires the separate-device factor.
• “What about exceptions?” Provide exception register entries and compensating controls.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails IA-2(6)	Fix
Treating “MFA enabled” as “MFA enforced”	Users can bypass via legacy protocols, exclusions, or per-app logins	Enforce in IdP and block legacy paths; test with a real account
No written definition of “separate device”	Assessors can’t validate your interpretation	Publish the methods matrix with rationale
Overbroad exclusions (“exclude all service accounts” or “exclude executives”)	Creates silent gaps in the highest-risk population	Use narrow, time-bound exceptions with compensations
Incomplete evidence	You can’t prove operation, only intent	Keep policy exports, enrollment reports, and log samples on a cadence
Relying on app-level MFA inconsistently	Coverage becomes unmeasurable	Centralize through SSO/IdP and standard policies

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat the main risk as assessment failure and elevated account takeover exposure rather than a specific cited enforcement pattern. The operational risk is concrete: if endpoints are compromised, same-device factors can be easier for an attacker to satisfy than out-of-band or hardware-backed factors. Align your implementation choices to your threat model and document that alignment for assessors. ³

Practical execution plan (30/60/90)

Use phases rather than date promises. Pick the smallest scope that meets your system’s baseline first, then expand.

First 30 days (Immediate)

• Write the IA-2(6) scope statement (ODP #1 and #2) and get sign-off from IAM, Security, and GRC.
• Publish the “separate device” definition and approved methods matrix.
• Inventory current MFA methods and identify any that do not meet your definition for in-scope access.
• Draft exception criteria and an exception register template.

Days 31–60 (Near-term)

• Configure IdP policies to require MFA for the scoped access and accounts.
• Restrict satisfaction of MFA to the approved separate-device methods for in-scope groups.
• Pilot with admins and a small workforce segment; document issues (lost devices, enrollment friction, token procurement).

Days 61–90 (Operationalize)

• Roll out to remaining in-scope populations and third-party users.
• Establish recurring evidence collection: policy exports, enrollment reports, and log sampling.
• Run an internal control test: attempt logins with non-approved methods and confirm denial; validate exceptions behave as designed.
• Map IA-2(6) in Daydream (or your GRC system) to an owner, procedure, and evidence list so evidence stays audit-ready. ⁴

Frequently Asked Questions

Does “separate device” require hardware tokens?

Not strictly. The requirement is about one factor being provided by a separate device; that can be a hardware token or a mobile device used out-of-band, as long as your implementation and evidence support the interpretation. ³

Can I meet IA-2(6) with authenticator apps on the same phone used for access?

If the phone is the device used to access the account, you should treat same-device MFA as a red flag and document how you still meet “separate device.” Many teams scope IA-2(6) to access paths where the approving factor is on a different device than the one initiating login. ³

What accounts should be in scope first?

Start with privileged and administrative accounts and the access paths that grant broad control (identity admin, cloud admin, remote access). Document ODP #2 clearly so your rollout sequence matches your stated scope. ³

How do auditors verify this control quickly?

They usually ask for IdP policy settings, the list of allowed authentication methods, and logs showing MFA prompts for in-scope users. Keep a ready evidence packet that ties scope to technical enforcement. ⁴

What about service accounts that cannot do MFA?

Document them as exceptions, block interactive login where possible, and use compensating controls such as restricted use, credential vaulting, and monitoring. The key is proving you didn’t silently exclude them without controls. ³

How do I operationalize evidence collection without burning the IAM team?

Define a fixed evidence list (policy export, enrollment report, log sample, exceptions register) and collect it on a recurring cadence through your GRC workflow. Daydream helps by mapping IA-2(6) to an owner, procedure, and recurring evidence artifacts so the packet is consistent each cycle. ⁴

Footnotes

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

2. NIST SP 800-53 Rev. 5 OSCAL JSON; NIST SP 800-53 Rev. 5

3. NIST SP 800-53 Rev. 5

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