Identification and Authentication (Organizational Users) | Access to Accounts — Separate Device

IA-2(6) requires multi-factor authentication (MFA) for access to defined accounts and services, with at least one factor delivered by a separate device from the system being accessed. Operationally, you must decide which accounts/services are in scope, enforce phishing-resistant or device-separated MFA where possible, and retain proof that MFA is technically enforced (not just documented). (NIST Special Publication 800-53 Revision 5)

Key takeaways:

• Scope “organization-defined accounts and services” explicitly, then map each to an MFA method where one factor is on a separate device. (NIST Special Publication 800-53 Revision 5)
• Enforcement must be technical (IdP, PAM, OS policy, conditional access), and you need evidence of real settings and coverage. (NIST Special Publication 800-53 Revision 5)
• Common failure modes are MFA exclusions, shared/admin accounts without proper MFA, and “same-device” OTP patterns that do not meet the enhancement intent. (NIST Special Publication 800-53 Revision 5)

This requirement is narrowly targeted and easy to misunderstand: it is not a generic “turn on MFA” checkbox. IA-2(6) asks for MFA where one factor is provided by a device separate from the system gaining access. That design goal is straightforward: reduce the chance that a single compromised endpoint (laptop, VDI session, admin workstation) can satisfy all authentication factors and grant access.

For a Compliance Officer, CCO, or GRC lead, the fastest path to execution is to treat IA-2(6) as a scoping and enforcement exercise. First, define the accounts and services that matter: privileged access, remote access paths, management planes, and high-impact business apps. Second, standardize MFA methods that clearly meet “separate device” (for example, push approval on a phone, FIDO2 security key, or a hardware token that is not the accessing system). Third, build evidence around enforced configuration, user coverage, and exception handling.

If you run a FedRAMP-aligned program, this control tends to show up in assessment friction because teams document MFA in policy but cannot prove it is enforced everywhere it should be, or they rely on methods that collapse into “same-device MFA.” (NIST Special Publication 800-53 Revision 5)

Regulatory text

Requirement (verbatim): “Implement multi-factor authentication for access to organization-defined accounts and services where one of the factors is provided by a device separate from the system gaining access.” (NIST Special Publication 800-53 Revision 5)

Operator translation: you must (1) define which accounts and services are in scope, and (2) enforce MFA for those access events such that at least one factor is delivered by a separate device than the system being accessed. This is a technical enforcement requirement, backed by system configuration evidence, not a policy-only statement. (NIST Special Publication 800-53 Revision 5)

Plain-English interpretation (what “separate device” means in practice)

“Separate device” means the user proves identity with something that is not the same endpoint initiating the login. The cleanest interpretations you can defend during an assessment:

• Meets intent: laptop login + approve push on phone; laptop login + tap external FIDO2 key; SSH to server + hardware token code from a token not running on the same laptop.
• High-risk / often challenged: laptop login + OTP generated by an authenticator app running on the same laptop; remote desktop to admin workstation + OTP displayed inside that same remote session.
• Why assessors care: malware or session hijacking on the accessing system can capture passwords and also satisfy “soft” second factors when both factors live on the same compromised endpoint.

If you cannot avoid some same-device patterns for certain edge cases, you need a documented exception path with compensating controls and a plan to migrate.

Who this applies to (entity + operational context)

Entity types in scope: cloud service providers and federal agencies operating systems aligned to NIST SP 800-53. (NIST Special Publication 800-53 Revision 5)

Operational scope (what assessors typically expect you to include):

• Privileged accounts: system admins, cloud admins, domain admins, break-glass accounts, service-management accounts.
• Remote access: VPN, ZTNA, VDI, bastions/jump hosts, remote admin tools.
• Management planes and consoles: cloud provider consoles, CI/CD admin, infrastructure orchestration, security tooling admin panels.
• High-impact business applications: systems that process sensitive data or enable material changes (payments, HR, customer data exports).

The control text is explicit that the organization defines the scope. Your job is to define it in writing and show enforcement for what you defined. (NIST Special Publication 800-53 Revision 5)

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

1) Define “organization-defined accounts and services” (make it auditable)

Create a scoped list with clear inclusion rules. A practical way is a table with:

• Account type (privileged, standard workforce, third-party admin, emergency)
• System/service (IdP, cloud console, VPN, PAM, ticketing admin)
• Access paths (web, API, SSH, SSO, local console)
• Required MFA method (push to mobile, FIDO2 key, hardware OTP token)
• Allowed exceptions (if any) and approval authority

This scoping statement becomes the anchor for your System Security Plan narrative and your operational evidence.

2) Choose MFA methods that satisfy “separate device”

Common acceptable patterns for “separate device” include:

• Out-of-band push to a registered mobile device.
• Hardware security keys (FIDO2) connected to the endpoint but physically separate from it.
• Hardware OTP tokens that are not hosted on the endpoint being used to authenticate.

Write a short standard that names your approved methods and explicitly bans or restricts ambiguous “same-device” approaches for in-scope access.

3) Enforce MFA at the control points (not per-app best effort)

Pick enforcement points you can prove:

• Identity Provider (IdP)/SSO: require MFA for assigned apps, admin portals, and high-risk sign-ins.
• Conditional access: require MFA from unmanaged devices, risky geolocation, or for privileged roles.
• PAM: require MFA to check out credentials, start privileged sessions, or approve elevation.
• OS and endpoint controls: enforce MFA for local privileged actions where applicable.

Avoid relying on app-by-app toggles if you can centralize at the IdP. App-level MFA is hard to evidence consistently.

4) Cover privileged and emergency access explicitly

Auditors look here first because the risk is concentrated.

• Privileged roles: enforce separate-device MFA for admin roles and admin portals.
• Break-glass accounts: either protect with strong separate-device MFA plus strict monitoring, or document an exception with compensating controls and tight access governance.

You need a written rule for emergency access that still respects the requirement intent and can be defended.

5) Address third-party access and non-human access

IA-2(6) is about organizational users, but third parties often authenticate as workforce-like users.

• Third-party administrators: put them behind your IdP/PAM and enforce the same separate-device MFA.
• Service accounts/API tokens: keep them out of “user MFA” scope, but ensure you can show they are not used for interactive access. If a service account is used interactively, treat it as in scope and remediate.

6) Implement exception handling that does not become the real policy

Create an exception workflow:

• Business justification
• Risk acceptance owner
• Compensating controls (for example, PAM session recording, IP allowlisting, shorter session lifetimes)
• Expiration and migration plan
• Evidence of periodic review

Exceptions should be rare, time-bound, and easy to enumerate.

Required evidence and artifacts to retain

Keep artifacts that prove both definition and technical enforcement:

Governance artifacts

• MFA standard defining “separate device” and approved methods. (NIST Special Publication 800-53 Revision 5)
• Scope statement: “organization-defined accounts and services” list with owners and access paths. (NIST Special Publication 800-53 Revision 5)
• Exception register with approvals and expiration.

Technical evidence

• IdP/conditional access screenshots or exports showing MFA requirements for in-scope apps and admin roles.
• PAM configuration showing MFA gates for privileged session initiation and/or credential checkout.
• System samples: a small set of in-scope services with evidence of enforced MFA (config pages, policy exports, command output).
• Authentication logs showing MFA events and the factor types in use (where your systems record them).

Operational evidence

• Joiner/mover/leaver procedure showing MFA enrollment at onboarding.
• Access review outputs for privileged groups tied to MFA enforcement rules.
• Proof of periodic validation (test scripts, internal audit check results) that MFA cannot be bypassed.

Common exam/audit questions and hangups

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

1. “Which accounts and services are ‘organization-defined’?”
   Have your scope table ready and show who approved it. (NIST Special Publication 800-53 Revision 5)

2. “Show me that one factor is on a separate device.”
   Be ready to demonstrate a login flow and show your MFA method standard. (NIST Special Publication 800-53 Revision 5)

3. “Are there exclusions in conditional access?”
   Auditors often find MFA bypass groups, trusted IP ranges, and legacy protocols that skip MFA.

4. “How do admins authenticate to the cloud management plane?”
   Show admin role assignment plus the exact policy that requires MFA for those roles.

5. “What about emergency access?”
   Provide your break-glass design, monitoring, and approvals.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Calling “MFA enabled” good enough without proving separate-device.
  Fix: define allowed methods and show factor type in logs or policy configuration. (NIST Special Publication 800-53 Revision 5)

• Mistake: Leaving legacy auth paths open (IMAP/POP, basic auth, older VPN modes).
  Fix: inventory auth protocols; block or gate them behind modern auth with enforced MFA.

• Mistake: Relying on user choice of second factor.
  Fix: restrict to approved factor types for in-scope systems (especially privileged access).

• Mistake: Break-glass accounts with weak controls and no monitoring.
  Fix: treat them as a special case with strict governance, alerts, and documented access procedure.

• Mistake: Exceptions that never expire.
  Fix: require an expiration and a migration plan for every exception.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat enforcement risk as assessment and authorization risk rather than case-law-driven risk. In FedRAMP and NIST 800-53-aligned programs, weak MFA implementations typically surface as:

• assessor findings due to unclear scope,
• inability to prove separate-device factor,
• policy/config mismatches between what is documented and what is enforced. (NIST Special Publication 800-53 Revision 5)

Risk-wise, the control targets credential theft, session hijacking, and endpoint compromise. Separate-device factors reduce the chance that compromise of one system grants immediate access.

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Confirm the in-scope list of accounts and services with system owners; write it down in a single scope register. (NIST Special Publication 800-53 Revision 5)
• Publish an MFA method standard that explicitly defines “separate device” and the approved factor types. (NIST Special Publication 800-53 Revision 5)
• Identify current MFA bypasses (exclusion groups, trusted networks, legacy protocols) and open remediation tickets.

Day 31–60 (Near-term)

• Enforce MFA at the IdP for in-scope apps and privileged roles; document the exact policy settings and export evidence.
• Implement PAM/privileged workflows that require separate-device MFA for admin sessions where feasible.
• Stand up an exception workflow with an owner, an approval path, and an exception register.

Day 61–90 (Stabilize and prove)

• Run access tests for representative services to prove MFA enforcement and separate-device factor behavior; store test results as evidence.
• Validate coverage: privileged groups, third-party admin accounts, remote access, and management planes.
• Add continuous monitoring: alerts for MFA policy changes, new exclusions, and privileged group membership changes.

Where Daydream fits: if you manage many third parties and internal systems, Daydream can centralize evidence collection requests (policy exports, screenshots, logs), track exceptions, and keep your scope register and control narratives aligned across teams without chasing updates in spreadsheets.

Frequently Asked Questions

Does a hardware security key count as a “separate device”?

Yes, a FIDO2 hardware key is a separate physical device from the workstation initiating access, and it cleanly supports the intent of IA-2(6). Document it as an approved factor type and show where it is required for in-scope access. (NIST Special Publication 800-53 Revision 5)

Do SMS codes meet this requirement?

SMS is delivered to a separate device in many deployments, but it carries known security tradeoffs. If you allow it, restrict it to lower-risk use cases and prefer stronger separate-device factors for privileged access. (NIST Special Publication 800-53 Revision 5)

What about an authenticator app installed on the same laptop being used to sign in?

That often fails the “separate device” intent because both factors live on the same endpoint. Treat it as noncompliant for in-scope access unless you have a documented exception and compensating controls. (NIST Special Publication 800-53 Revision 5)

Are service accounts in scope for IA-2(6)?

IA-2(6) targets organizational users, so non-interactive service accounts are typically handled under different controls. Your job is to prove service accounts are not used for interactive access and that interactive admin access uses separate-device MFA. (NIST Special Publication 800-53 Revision 5)

How do we handle break-glass accounts if MFA could block emergency access?

Define a controlled emergency access procedure, keep break-glass accounts tightly governed, and document compensating controls such as heightened monitoring and restricted use. If you must deviate from separate-device MFA, record an approved exception with an expiration. (NIST Special Publication 800-53 Revision 5)

What evidence is most persuasive to auditors?

Policy exports or screenshots that show MFA is required for specific apps and privileged roles, plus logs showing MFA events for real sign-ins. Pair that with your written scope definition so the auditor can trace “defined” to “enforced.” (NIST Special Publication 800-53 Revision 5)